La forma habitual de almacenar la contraseña es usar una función hash en la contraseña, pero salt de antemano. Es importante "salar" la contraseña, para defenderse de rainbow table ataques.
Así que tu mesa debería verse así
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |[email protected]|13%!#tQ!#3t...|
| |... |... |
Al verificar si una contraseña dada coincide con un usuario, debe concatenar la sal a la contraseña dada y calcular la función hash de la cadena de resultado. Si la salida de la función hash coincide con el hash columna - es la contraseña correcta.
Sin embargo, es importante comprender que la idea del salt-hash tiene una razón específica:evitar que cualquier persona con acceso a la base de datos conozca la contraseña de alguien (se considera un problema difícil revertir la salida de una función hash). Entonces, por ejemplo, el DBA del banco no podría iniciar sesión en su cuenta bancaria, incluso si tiene acceso a todas las columnas.
También debe considerar usarlo si cree que sus usuarios usarán una contraseña confidencial (por ejemplo, la contraseña de su cuenta de Gmail) como contraseña para su sitio web.
En mi humilde opinión, no siempre es una característica de seguridad que se necesita. Así que deberías pensar si lo quieres o no.
Consulte este artículo para un buen resumen de este mecanismo.
Actualización: Vale la pena mencionar que para mayor seguridad contra ataques dirigidos para invertir el hash de la contraseña individual, debe usar bcrypt , que puede ser arbitrariamente difícil de calcular. (Pero a menos que realmente tenga miedo de que el misterioso hombre de negro se dirija a su base de datos específica, creo que sha1 es lo suficientemente bueno. No introduciría otra dependencia para mi proyecto por esta seguridad adicional. Dicho esto, no hay razón para no usar sha1 100 veces, lo que daría un efecto similar).
