¿Cuál es la forma recomendada de cifrar contraseñas de usuario en una base de datos?

Question

En una aplicación web escrita en Perl y utilizando PostgreSQL, los usuarios tienen nombre de usuario y contraseña. ¿Cuál sería la forma recomendada de almacenar las contraseñas?

Cifrado utilizando la función crypt() de Perl y una sal al azar? Eso limitaría la longitud útil de las contraseñas a 8 caracteres y requerirá recuperar la contraseña almacenada para compararla con la dada por el usuario al autenticarse (para obtener la sal que estaba adjuntada).

¿Hay una forma incorporada en PostgreSQL para hacer esto?

¿Debo utilizar Digest::MD5?

Answer 1

Use el hash SHA1 o SHA256 con salazón. Ése es el camino a seguir para almacenar contraseñas.

Answer 2

Sugeriría almacenarlo como un hash md5 salado.

INSERT INTO user (password) VALUES (md5('some_salt'||'the_password')); 

Se podría calcular el hash MD5 en Perl si lo desea, no hay mucha diferencia a menos que esté micro-optimización.

También podría usar sha1 como alternativa, pero no estoy seguro si Postgres tiene una implementación nativa de esto.

Normalmente desaconsejo el uso de una sal aleatoria dinámica, ya que es otro campo que debe almacenarse en la base de datos. Además, si tus mesas se vieron comprometidas, la sal se vuelve inútil.

Siempre voy con una sal generada al azar por única vez y la almacena en el origen de la aplicación o en un archivo de configuración.

Otra ventaja de utilizar un hash md5 o sha1 para la contraseña es que puede definir la columna de contraseña como un ancho fijo CHAR (32) o CHAR (40) para md5 y sha1, respectivamente.

Answer 3

Si no usa un mecanismo de recuperación de contraseña (No restablecimiento de contraseña), creo que usar un mecanismo de hashing es mejor que tratar de encriptar la contraseña. Puede verificar los hashes sin ningún riesgo de seguridad. Incluso usted no conoce la contraseña del usuario.

Answer 4

El módulo pgcrypto en PostgreSQL ha suppotr orden interna de hash de la clave, que es bastante inteligente sobre el almacenamiento, generación, multi-algoritmo etc. Ver http://www.postgresql.org/docs/current/static/pgcrypto.html, la sección sobre contraseña Funciones Hashing. También puede ver la sección pgcrypto de http://www.hagander.net/talks/hidden%20gems%20of%20postgresql.pdf.

Answer 5

MD5 se usa comúnmente, pero SHA1/SHA256 es mejor. Todavía no es el mejor, pero mejor.

El problema con todos estos algoritmos de hash de uso general es que están optimizados para ser rápidos. Sin embargo, cuando usa sus contraseñas para el almacenamiento, lo rápido que desea no es querer, si puede usar la contraseña en un microsegundo, significa que un atacante puede probar un millón de contraseñas cada segundo si obtienen su contraseña. manos en su base de datos de contraseñas.

Pero quiere reducir la velocidad de un atacante tanto como sea posible, ¿no? ¿No sería mejor usar un algoritmo que demora una décima de segundo para cifrar la contraseña? Una décima de segundo es lo suficientemente rápida como para que los usuarios no lo noten, pero un atacante que tenga una copia de su base de datos solo podrá hacer 10 intentos por segundo; les llevará 100.000 veces más encontrar un conjunto de trabajo. de credenciales de inicio de sesión.Cada hora que les tomaría en un microsegundo por intento se convierte en 11 años a una décima de segundo por intento.

Entonces, ¿cómo lograr esto? Algunas personas lo simulan ejecutando varias rondas de digestión MD5/SHA, pero el algoritmo bcrypt está diseñado específicamente para abordar este problema. No entiendo completamente las matemáticas detrás de esto, pero me dicen que se basa en la creación de marcos Blowfish, que es intrínsecamente lento (a diferencia de las operaciones MD5 que pueden ser altamente optimizadas en hardware configurado correctamente), y tiene una parámetro de "costo" ajustable para que, a medida que avanza la Ley de Moore, todo lo que necesita hacer es ajustar ese "costo" para mantener el hash de la contraseña tan lento en diez años como lo es hoy.

Answer 6

No use SHA1 o SHA256, como la mayoría de las personas están sugiriendo. Definitivamente no use MD5.

SHA1/256 y MD5 están diseñados para crear sumas de comprobación de archivos y cadenas (y otros tipos de datos, si es necesario). Debido a esto, están diseñados para ser lo más rápido posible, de modo que la suma de comprobación se genere rápidamente.

Esta velocidad rápida hace que sea mucho más fácil contraseñas de fuerza bruta, ya que un programa bien escrito puede generar miles de hash por segundo.

En su lugar, utilice un algoritmo lento que está diseñado específicamente para contraseñas. Están diseñados para demorar un poco más en generar, con la ventaja de que los ataques de fuerza bruta se vuelven mucho más difíciles. Debido a esto, las contraseñas serán mucho más seguras.

No experimentará ninguna desventaja de rendimiento significativo si solo está buscando cifrar contraseñas individuales de una en una, que es la implementación normal de almacenamiento y comprobación de contraseñas. Es solo a granel donde está la diferencia real.

Personalmente me gusta bcrypt. Debería haber una versión de Perl disponible, ya que una búsqueda rápida en Google arrojó varias coincidencias posibles.

Answer 7

Me gusta bcrypt el mejor, con SHA2 (256) en segundo lugar. Nunca he visto MD5 usado para contraseñas, pero tal vez algunas aplicaciones/bibliotecas lo usan. Tenga en cuenta que siempre debe usar una sal también. La sal en sí debe ser completamente única para cada usuario y, en mi opinión, el mayor tiempo posible. Nunca, nunca usaría solo un hash contra una cuerda sin agregarle sal. Principalmente porque soy un poco paranoico y también para que sea un poco más a prueba de futuro.

Tener una demora antes de que un usuario pueda volver a intentarlo y bloqueos automáticos (con notificaciones de administración automática) es una buena idea también.