¿Cómo proporcionar seguridad para las contraseñas almacenadas en la base de datos? [duplicar]

Puedes comenzar usando un mecanismo de hashing más fuerte como SHA-2 en lugar de MD5. También puede hacer que la base de datos de contraseñas con hash sea más segura mediante el uso de hashing de contraseñas con sal. Una vez hice una presentación en mi clase sobre el hash de contraseñas y encontré este enlace y éste también es muy informativo (aparte de la Wikipedia). Espero que esto te ayude también.

1. Usa un mejor hash. Tenemos muchas preguntas relacionadas con esto, pero se reduce a bcrypt, PBKDF2 o scrypt con iteraciones suficientes (al menos 10'000 para PBKDF2, valores equivalentes para los demás) y una sal aleatoria. La iteración única SHA-2 no es aceptable, incluso con una sal.

2. Cifre el hash con una clave que esté almacenada en algún tipo de archivo de configuración. La elección exacta depende de su plataforma, podría ser web.config encriptado de .net, o algún tipo de almacén de claves, o incluso simplemente una configuración de archivo de texto normal.

   Esto ayuda contra los atacantes que pueden ver la base de datos, pero no ese archivo de configuración. Pero, obviamente, no ayuda contra un compromiso total.

¿Tiene la opción de agregar un salt a sus contraseñas?

enlace

Creo que esto haría que esas bases de datos sean menos efectivas para descifrar tus hashes.

Primero "cifrar" y "hashing" son cosas diferentes. La operación unidireccional que describe es el hash.

El ataque que describe suena como un ataque de mesa de arco iris. En general, debe agregar un salt a su hash de contraseña para evitarlo, pero si usa una función de hashing débil (como MD5), su esquema seguirá siendo vulnerable.

Debes tener cuidado con la función que utilizas para hacer esto. Es fácil elegir la función incorrecta y no ganar mucha seguridad. Echa un vistazo a esta pregunta . La idea general es utilizar una función hash adaptativa, como bcrypt, para cuidar de todos estos detalles de seguridad.

Dependiendo de su plataforma de base de datos (y posiblemente de licencias adicionales), existen mecanismos para evitar que otros usuarios (incluso DBA) vean columnas particulares. En Oracle, por ejemplo, se llama Base de datos privada virtual

enlace

Se recomienda el uso de sales, una función de derivación de claves y una política de contraseña aplicada por el sistema.

• Las sales de una longitud suficiente prevendrán efectivamente el uso de tablas de arco iris y ataques de diccionario
• El uso de una función de derivación de claves como scrypt, bcrypt o PBKDF2 ( vea también ) ralentizará un posible ataque de fuerza bruta aunque la sal pueda ser conocida. Esto funciona porque esas funciones de derivación de claves están diseñadas con el objetivo de ejecutarse intencionalmente de forma lenta en las CPU, en la memoria o en ambas (scrypt). Tenga en cuenta que el tiempo de cálculo para cada contraseña se puede personalizar mediante el uso de parámetros. Este enfoque es altamente preferido sobre el uso de una función hash estándar como MD5. Por cierto, MD5 es propenso a los ataques de colisión encontrados por Boer, Bosselaers y Dobbertin y su uso no es recomendado.
• Dado que las contraseñas son una de las entradas de dicha función de derivación de claves, las contraseñas débiles pueden romper la seguridad de su sistema. Para encontrar esto, deje que su sistema verifique las nuevas contraseñas antes de almacenarlas en la base de datos. Las contraseñas seguras deben tener una longitud mínima, deben contener caracteres en mayúsculas y minúsculas (especiales) y números. Incluso si la política de seguridad de su base de datos no puede excluir a sus administradores de la lectura de claves derivadas y sus valores de sal correspondientes, no podrían hacer uso de este

@CodeInChaos: 1. Olvidaste las tablas de arco iris basadas en diccionarios. 2. El OP le dice que usa MD5 para el hashing de contraseñas y le aconsejé que no lo hiciera. OP no quiere que los administradores que tienen acceso a la base de datos con valores hash puedan derivar ningún conocimiento de contraseña a partir de eso. Lo que quise decir con propensos a ataques de colisión se conoce más precisamente como resistencia a la preimagen y, por lo tanto, recomendar una alternativa más segura en general es absolutamente válido. Tal vez mi enlace sea fuera de tema, sin embargo. 3. Creo que el OP está buscando buenas respuestas en general. También dijo que esos administradores necesitan crear copias de seguridad de la base de datos completa. Lo cual no es posible sin permisos de lectura. Sin embargo, cuando las sales y las entradas de contraseña (3) son lo suficientemente largas, incluso el conocimiento de ambas no revela ninguna contraseña. Es por eso que recomendé usar una buena política de contraseña.

@ makerofthings7, Tom Post: ¡Gracias por su ayuda! Sí, accidentalmente publiqué desde una cuenta temporal.