Pre-hash contraseña antes de aplicar bcrypt para evitar restringir la longitud de la contraseña

Question

Pre-hash contraseña antes de aplicar bcrypt para evitar restringir la longitud de la contraseña

#1 de Thomas Pornin (37 votos)
#2 de Steven Alexander (14 votos)

62

Una buena práctica es no restringir innecesariamente la longitud de la contraseña, de modo que se puedan usar frases de contraseña de un tamaño adecuado (quizás 35-45 caracteres para 6/7 palabras clave). (Consulte, por ejemplo, ¿Debo tener una longitud máxima de contraseña? donde se sugiere un máximo de 1 K para protegerse contra el DoS sin restringir la capacidad de los usuarios para establecer contraseñas largas.

bcrypt también se suele recomendar (ver, por ejemplo, Do ¿Algún experto en seguridad recomienda bcrypt para el almacenamiento de contraseñas? , enlace )

También se recomienda usar un salt (aleatorio, y almacenado con el hash de la contraseña). Creo que a menudo se recomiendan 32 bits (4 caracteres). (Entiendo que la lógica del tamaño de la sal es "suficiente para que el número de combinaciones sea mucho mayor que el número de registros del usuario Y es suficiente para hacer tablas del arco iris infactiblemente grandes": 16 bits son suficientes para la segunda parte, pero no pueden ser suficiente para el primero.)

Pero AIUI bcrypt solo hash 55 bytes, con 4 caracteres para la sal que deja 51 para la contraseña.

Supongo que no deberíamos simplemente bcrypt (izquierda (contraseña, 51)) e ignorar los últimos caracteres.

¿Deberíamos limitarnos a los usuarios a 50 caracteres en su contraseña (suficiente para casi todos, pero no definitivamente es suficiente)?

¿Deberíamos usar algo como bcrypt (sha256 (salt + contraseña)) en su lugar, y permitir hasta 1K caracteres? ¿O la adición del paso sha256 (o sha512?) Reduce la seguridad general de alguna manera?

¿Scrypt o PBKDF2 tienen restricciones de longitud similares?

(La última pregunta es solo por interés, realmente: me doy cuenta de que la dureza del espacio / FPGA-resistencia, y la relativa novedad de Scrypt, y la GPGPU-resistencia de bcrypt en comparación con PBKDF2 son consideraciones mucho más importantes a la hora de decidir cual hash para usar.)

passwords hash cryptography passphrase

pregunta Misha 26.08.2011 - 00:35

fuente

2 respuestas

14

Bcrypt usa una sal de 128 bits Y una contraseña de 55 caracteres (máx.). No es necesario agregar ningún otro valor de sal; bcrypt maneja eso.

Los diseñadores de bcrypt sintieron que el límite de 55 caracteres en la contraseña no era un problema ya que el hash tiene una salida de 128 bits. Si su contraseña tiene más de 55 caracteres, los diseñadores asumieron que ya está proporcionando más de 128 bits de entropía, por lo que esto no es un problema. Por el contrario, las pautas del NIST contabilizarían esto como solo 77 bits de entropía. Las pautas del NIST se basan en el hecho de que las frases de paso tienen menos entropía por carácter que las contraseñas aleatorias y en el supuesto de que los usuarios usarán frases de paso para las contraseñas más largas. Para asegurarte de que obtienes un total de 128 bits de entropía, puedes permitir contraseñas más largas y usarlas con SHA-256 o SHA-384 para comprimirlas a una longitud aceptable. También puede simplificar las cosas utilizando scrypt o PBKDF2 que no tienen limitaciones de longitud. Scrypt está diseñado para ser "duro para la memoria" además de ser computacionalmente lento; esa sería mi elección de algoritmos.

respondido por el Steven Alexander 28.06.2012 - 08:17

fuente

Lea otras preguntas en las etiquetas passwords hash cryptography passphrase

¿La vulnerabilidad del corazón del corazón afecta a los clientes tan seriamente? ¿Qué importancia tiene la hora local para la seguridad?

score 37 · Accepted Answer

El uso de una función hash segura para preprocesar la contraseña es seguro; se puede demostrar que si bcrypt (SHA-256 (contraseña)) se rompe, entonces la contraseña fue adivinada o si alguna característica de seguridad de SHA-256 ha sido probada como falsa. No hay necesidad de jugar con la sal a ese nivel; solo hash la contraseña, luego usa bcrypt en el resultado (con la sal, como mandatos de bcrypt). SHA-256 se considera una función hash segura.

El punto de un salt es ser único, lo más único posible, de modo que no haya dos contraseñas con hash que utilicen el mismo valor de salt. 32 bits son un poco bajos para eso; Deberías usar una sal más larga. Si tiene n bits de sal, entonces encontrará colisiones (dos contraseñas con hash que usan la misma sal) tan pronto como tenga más que sobre 2 ^{n / 2} contraseñas con hash, eso es aproximadamente 65000 con n = 32 , un valor no demasiado alto. Es mejor que uses 64 bits o más de sal (usa 128 bits y puedes dejar de preocuparte por eso).