Como dice la llama, no tiene mucho sentido pre-hashing la contraseña en el lado del cliente: SSL lo protege. Por supuesto, esto supone que usa SSL para todas las comunicaciones; si no lo hace, entonces ya tiene problemas mucho mayores que debe abordar primero.
Si un atacante ve "SHA-512 (password + long_string)", entonces el atacante puede ejecutar ataques de diccionario sin conexión a esa contraseña, es decir, probar valores de contraseña potenciales hasta que se encuentre una coincidencia. Por supuesto, esto supone que el atacante conoce "long_string" pero como tanto el cliente como el servidor lo saben, y no ha sido ingresado por el usuario humano, entonces se debe asumir que el servidor proporciona el "long_string" antes del usuario autenticación, o está codificado en el código del cliente. De cualquier manera, no es razonable suponer que el atacante no lo tiene. El ataque del diccionario se ejecutará a un ritmo de varios millones de intentos por segundo, porque, seamos sinceros, una PC básica es realmente buena para calcular SHA-512.
Hasta cierto punto, si "long_string" es realmente largo (estamos hablando de megabytes aquí), entonces el costo del hashing puede llegar a ser insignificante y, por lo tanto, ralentizar al atacante. Dicha lentitud es la mitad (pero solo la mitad) de lo que hace una buena función de hash de contraseña. Tenga en cuenta que los algoritmos criptográficos son sutiles: "SHA-512 (long_string + password)" sería mucho más débil, en ese sentido, que "SHA-512 (password + long_string)" (si no ve por qué, entonces no toque ese teclado otra vez). La segunda mitad del buen hashing de contraseñas consiste en disuadir ataques paralelos, lo que, en este caso, significaría que cada usuario tiene su propio valor de "cadena larga", distinto de los de los demás usuarios. La "cadena larga" actúa como un salt .
Su alternativa, con "SHA-512 (nombre de usuario + contraseña)", falla en las partes de lentitud y garantiza de manera imperfecta la parte no paralela (porque los nombres de usuario no son únicos en el mundo y también se reutilizan cuando el usuario cambia su contraseña). Dependiendo de cómo se elija "long_string" en el sistema original, su propuesta puede debilitar o fortalecer la seguridad.
La respuesta a la pregunta exacta es que si el atacante ve los valores de ambos , entonces puede elegir a cuál atacará, y esto solo puede ayudarlo. Sin embargo, una respuesta más completa es que:
- Debería enviar las contraseñas solo a través de un túnel debidamente protegido (SSL), en cuyo momento no hay ninguna razón válida para enviar la contraseña en el lado del cliente; Gracias a SSL, el cliente sabe que está enviando la contraseña al servidor correcto, y solo a ese servidor. Simplemente envíe la contraseña "tal cual".
- Si planea utilizar el hash como mecanismo de almacenamiento en el servidor (es decir, el servidor realiza el hashing, no el cliente, y el resultado se almacena en la base de datos del servidor), entonces su nuevo sistema Puede ser un poco mejor que el anterior, o un poco peor, pero ambos son débiles de todos modos. Vaya a leer esa respuesta ; sería muy imprudente diseñar sistemas criptográficos con contraseña hasta que lo entiendas a fondo (no es necesario que esté de acuerdo : la ciencia sin debate ya no es ciencia, pero al menos debe comprender los conceptos) .