¿Es mejor el hash de la contraseña (con bcrypt) cuando concatena el nombre de usuario con la contraseña?
Por ejemplo:
$this->hash($username . $password);
y
$this->hash($password);
La última vez que usé sha1 ($ username. $ password), pero ahora, al crear un nuevo proyecto, quiero saber si realmente importa. ¿Aumenta su fuerza de cifrado?
Los nombres de usuario no son muy buenos en sales porque no son únicos a nivel mundial , y tampoco son de manera puntual .
El objetivo de Salt es evitar que un atacante optimice su investigación atacando varios hashes de contraseñas "en paralelo" y compartiendo el costo computacional. "Paralelismo" es un término bastante amplio; no significa necesariamente "simultáneamente". Por ejemplo, una tabla precomputada (por ejemplo, rainbow table ) de valores de contraseña-a-hash es una clase de paralelismo (I am simplemente razonando en el espacio-tiempo sin distinguir la dimensión de tiempo de las tres dimensiones de espacio aquí).
En la práctica, si su software usa el nombre de usuario como salt, como sugiere, entonces vale la pena calcular previamente una tabla para atacar la contraseña de admin porque es probable que haya tantos (¿la mayoría? ) Los servidores que usen su software tendrán un usuario llamado admin . Eso es una violación de la "singularidad mundial": los nombres de usuario son únicos en un servidor dado pero no en todos los servidores existentes que usan este software o un software similar , que permite ataques optimizaciones.
En cuanto a la singularidad "de tiempo", me refiero a un usuario que cambia su contraseña. Si el nombre de usuario es el salt, entonces la contraseña antigua y la nueva usarán el mismo salt y, por lo tanto, podrían atacarse en paralelo por menos del doble del costo de atacar una contraseña. Las contraseñas antiguas son valiosas para los atacantes, porque:
Cuando los usuarios cambian su contraseña, tienden a usar "series adivinables" (es decir, si la contraseña antigua de un usuario es "Password201207", es probable que la nueva contraseña, si se elige en Navidad, sea "Password201212 ").
Algunos usuarios reciclan contraseñas: cuando cambian su contraseña, a menudo debido a una política de cambio de contraseña impuesta por el administrador del sistema, recorren una breve lista de contraseñas y ciclos; una contraseña antigua podría ser la contraseña que usarán la próxima vez que la cambien.
Los usuarios son usuarios, reutilizan las contraseñas entre sitios (por lo tanto, la contraseña antigua en un servidor podría ser la contraseña actual para el mismo usuario en otro sitio).
Por estas razones, los nombres de usuario no son buenas sales.
Nota obligatoria: la salazón es solo una parte del problema; también necesita que el hashing de la contraseña sea lento . Una sola invocación de SHA-1 es demasiado rápida; un atacante con un par de GPU calculará un billón de esos por segundo . Las sales evitan que el atacante reutilice el esfuerzo de descifrar una contraseña sobre otra, pero también necesita el esfuerzo de descifrar una sola contraseña para que no sea despreciable. Las buenas funciones de hashing de contraseñas son una cosa difícil. Use bcrypt y evite diseñar sus propios esquemas.
Lo que estás describiendo es un Salt . El propósito principal de tener una sal es proteger contra los ataques de rainbow.a>. Sin embargo, lo ideal es que la sal se genere al azar y no se derive del nombre de usuario.
Lea otras preguntas en las etiquetas passwords hash cryptography