database - salting - salt password generator
La mejor manera de almacenar la contraseña en la base de datos (8)
Como un hash salado endurecido con llave, utilizando un algoritmo seguro como sha-512.
Estoy trabajando en un proyecto que debe tener autenticación (nombre de usuario y contraseña)
También se conecta a una base de datos, así que pensé que almacenaría el nombre de usuario y la contraseña allí. Sin embargo, no parece tan buena idea tener contraseñas como solo un campo de texto en una tabla que se encuentra en la base de datos.
Estoy usando C # y conectándome a un servidor Express 2008. ¿Puede alguien sugerir (con tantos ejemplos como sea posible) cuál sería la mejor manera de almacenar este tipo de datos?
PD: Estoy abierto a la idea de que esta información no se almacene en la base de datos si se puede proporcionar una buena razón.
En su escenario, puede echar un vistazo a la membresía de asp.net, es una buena práctica almacenar la contraseña del usuario como una cadena de hash en la base de datos. puede autenticar al usuario comparando la contraseña entrante con hash con la almacenada en la base de datos.
Todo ha sido construido para este propósito, revisa la membresía de asp.net
Es correcto que almacenar la contraseña en un campo de texto sin formato es una idea horrible . Sin embargo, en lo que respecta a la ubicación , para la mayoría de los casos que se van a encontrar (y honestamente no puedo pensar en ningún contra-ejemplo) almacenar la representación de una contraseña en la base de datos es lo correcto. Por representación me refiero a que desea hacer un hash de la contraseña usando un salt (que debería ser diferente para cada usuario) y un algoritmo seguro de 1 vía y almacenarlo, eliminando la contraseña original. Luego, cuando desee verificar una contraseña, haga un hash del valor (utilizando el mismo algoritmo de hash y sal) y lo compara con el valor de hash en la base de datos.
Entonces, si bien es una buena cosa que estés pensando en esto y es una buena pregunta, esto es en realidad un duplicado de estas preguntas (al menos):
- Cómo almacenar mejor la información del usuario y el inicio de sesión y la contraseña del usuario
- Mejores prácticas para almacenar contraseñas de bases de datos
- Salado tu contraseña: ¿Mejores prácticas?
- ¿Es aceptable almacenar la contraseña en texto plano en una variable php o constante php?
Para aclarar un poco más sobre el bit de salado, el peligro de simplemente copiar y guardar una contraseña es que si un intruso obtiene una retención de su base de datos, puede usar lo que se conoce como tablas arco iris para poder "descifrar" el Contraseña (al menos las que aparecen en la tabla del arco iris). Para solucionar esto, los desarrolladores agregan una salt a las contraseñas que, cuando se hacen correctamente, hacen que los ataques de arco iris simplemente no sean factibles. Tenga en cuenta que un error común es simplemente agregar la misma cadena única y larga a todas las contraseñas; Si bien esto no es horrible , lo mejor es agregar sales únicas a cada contraseña. Lee esto para más.
La mejor práctica de seguridad es no almacenar la contraseña en absoluto (ni siquiera encriptada), sino almacenar el hash salado (con un único salt por contraseña) de la contraseña encriptada.
De esa manera es (prácticamente) imposible recuperar una contraseña de texto simple.
Me gustaría MD5 / SHA1 la contraseña si no necesita poder revertir el hash. Cuando los usuarios inician sesión, simplemente puede cifrar la contraseña dada y compararla con el hash. Las colisiones de hash son casi imposibles en este caso, a menos que alguien obtenga acceso a la base de datos y vea un hash para el que ya tienen una colisión.
Puede que sea un poco fuera de tema, ya que mencionó la necesidad de un nombre de usuario y una contraseña, y mi comprensión del problema no es lo mejor, pero ¿vale la pena considerar OpenID?
Si usa OpenID, no terminará almacenando ninguna credencial si entiendo la tecnología correctamente y los usuarios pueden usar las credenciales que ya tienen, evitando la necesidad de crear una nueva identidad que sea específica para su aplicación.
Puede que no sea adecuado si la aplicación en cuestión es puramente para uso interno, aunque
RPX proporciona una forma fácil y sencilla de integrar OpenID en una aplicación.
Recomiendo leer los artículos Suficiente con The Rainbow Tables: lo que necesita saber acerca de los esquemas de contraseña segura [enlace muerto, copia en el archivo de Internet ] y cómo almacenar una contraseña de manera segura .
Muchos programadores, yo incluido, creo que entienden la seguridad y el hash. Lamentablemente la mayoría de nosotros simplemente no lo hacemos.
Fondo Nunca ... realmente ... necesitas saber la contraseña del usuario. Solo desea verificar que un usuario entrante conozca la contraseña de una cuenta.
Hash It: almacene las contraseñas de usuario hash (cifrado unidireccional) mediante una función hash fuerte. Una búsqueda de "c # cifrar contraseñas" da una carga de ejemplos.
Consulte el creador de hash SHA1 en línea para obtener una idea de lo que produce una función hash (pero no use SHA1 como una función hash, use algo más fuerte como SHA256).
Ahora, las contraseñas con hash significan que usted (y los ladrones de la base de datos) no deberían poder revertir ese hash a la contraseña original.
Cómo usarlo: Pero, dices, ¿cómo uso esta contraseña de puré almacenada en la base de datos?
Cuando el usuario inicie sesión, le entregará el nombre de usuario y la contraseña (en su texto original). Usará el mismo código hash para codificar esa contraseña ingresada para obtener la versión almacenada.
Por lo tanto, compare las dos contraseñas con hash (hash de la base de datos para el nombre de usuario y la contraseña escrita y con hash). Puede saber si "lo que escribieron" coincidió "con lo que el usuario original ingresó para su contraseña" comparando sus hashes.
Crédito adicional:
Pregunta: Si tuviera su base de datos, ¿no podría simplemente tomar un cracker como John the Ripper y comenzar a hacer hashes hasta que encuentre coincidencias con sus contraseñas de hash almacenadas? (ya que los usuarios escogen las palabras cortas, del diccionario de todos modos ... debería ser fácil)
Respuesta: sí ... sí pueden.
Por lo tanto, debe "saltear" sus contraseñas. Vea el salt