Necesita referencias acerca de por qué el acceso público a un hash de contraseña y sal es una mala práctica

Lo malo de revelar la contraseña hash-and-salt es que permite ataques de diccionario sin conexión : desde la contraseña el hash y la sal son suficientes para verificar una contraseña potencial, luego, por definición, permiten que un atacante intente las contraseñas en sus propias máquinas, limitado solo por el número de PC (u otro hardware) que pueda reunir. Esto contrasta con los ataques del diccionario en línea , donde cada intento debe ir a través de su servidor, y su servidor no aceptará probar miles de millones de contraseñas por segundo.

El hashing de contraseñas es una segunda línea de defensa . No desea que los atacantes obtengan suficiente información para ejecutar ataques de diccionario sin conexión; pero cuando lo hacen, al menos lo prefiere si tienen que pagar el precio total del ataque, es decir, les muestra solo hashes de contraseña , no las contraseñas en sí mismas. Además, desea una función hash lenta (con millones de iteraciones) y la sal para evitar ataques paralelos y otras optimizaciones similares (como tablas precomputadas).

Todo esto tiene que ver con la protección de contraseñas , como en "datos secretos que los usuarios humanos recuerdan". Los cerebros humanos son lo que son, las contraseñas tienden a ser vulnerables a los ataques de diccionario. Sin embargo, si puede convencer a sus usuarios humanos para que recuerden secuencias de 20 letras aleatorias ( no secuencias que elijan ellos mismos, pero letras generadas aleatoriamente), entonces puede mostrar los valores de hash, ya que las contraseñas son suficientemente aleatorias. Fuera del alcance de los ataques de diccionario, de todos modos, podría decirse que ya no son contraseñas sino claves . Tenga en cuenta que esto no es una cuestión de longitud sino de aleatoriedad : una contraseña no es segura porque es larga, sino porque se produjo con suficiente aleatoriedad; solo necesitas la longitud para hacer espacio para la aleatoriedad.

Si necesita una referencia a los infieles no creyentes , invoque Publicación especial NIST SP 800-118 (aún en borrador, pero publicada, sin embargo), que incluye especialmente esta cita (del" resumen ejecutivo "):

  

contraseña   Los ataques de craqueo pueden ser mitigados usando fuerte   Contraseñas, eligiendo fuertes algoritmos criptográficos.   e implementaciones para el hashing de contraseñas, y proteger la confidencialidad de los hashes de contraseñas .

(El énfasis es mío.)

El hash de contraseñas es un arte difícil. Usted dice que usa "HMAC / SHA-1", pero HMAC no es una función hash; es un MAC . Los algoritmos MAC utilizan una clave . Lo que probablemente quiere decir es que utiliza una función de hash de contraseña que ha sido diseñada sobre una o varias invocaciones de HMAC / SHA-1 como un componente básico. PBKDF2 es una función de hashing de contraseña. Incluye un parámetro adicional que es el número de iteraciones y eso es importante.

Consulte esta respuesta para una discusión detallada sobre la contraseña El hash, su teoría y su práctica.

Primero, HMAC-SHA1 no es un buen algoritmo de hash de contraseña. Use algo como bcrypt , scrypt o PBKDF2 .

En este caso, es absolutamente trivial comenzar a descifrar contraseñas en tu sistema. Las contraseñas completamente aleatorias de al menos diez caracteres pueden ser seguras, pero cualquier contraseña que sea más corta o que haga un uso intensivo de patrones o palabras caerá en cuestión de minutos. Los crackers de contraseñas modernos tienen motores extremadamente sofisticados que pueden tomar una palabra de base como "contraseña" y modificar cada permutación plausible ("p4 $$ wOrd!", "PaSs; WORD1234", etc.) en una fracción de segundo. Algunos sistemas recientes incluso han superado velocidades de 348 mil millones de hashes por segundo .

Esta es la razón por la que su algoritmo actual no es lo suficientemente bueno, y por qué es una vulnerabilidad absolutamente crítica que los atacantes pueden revelar sus sales y hashes. Los algoritmos de hash específicos de la contraseña (generalmente conocidos como "hashes lentos") ayudan a derrotar este tipo de máquinas de descifrado de contraseñas aceleradas por GPU al requerir grandes cantidades de trabajo para calcular una sola contraseña. PBKDF2, por ejemplo, es un esquema que utiliza un HMAC repetido. Al hacer 100,000 o más iteraciones, ralentiza estas máquinas de descifrado de contraseñas por el mismo factor. Ahora puede llevarle medio segundo verificar la contraseña de un usuario en casos legítimos, pero los atacantes ahora requieren días solo para enumerar incluso las contraseñas más comunes.

Algoritmos como scrypt van aún más lejos, requiriendo una cantidad configurable de memoria para generar el hash. Si sus contraseñas requieren 128 MB de memoria para computar, esto apenas se notará mediante una aplicación web estándar. Pero para un cracker de contraseñas, se necesitarían cantidades extremadamente grandes de memoria para calcular los hashes en paralelo (que es como la mayoría de ellos logran velocidades tan grandes).

En su situación actual, debe cerrar la vulnerabilidad que permite a las personas revelar sales y hashes. Las contraseñas existentes deben considerarse comprometidas a menos que se pueda probar de manera inequívoca lo contrario. Debe migrar sus contraseñas a uno de los algoritmos de hash recomendados tan pronto como sea práctico. Simplemente puede componer los hashes existentes con el nuevo algoritmo, por lo tanto, dado h = HMAC-SHA1(password, salt) , calcule h' = bcrypt(h) y use h' como autenticador.

Si todas las contraseñas son largas y verdaderamente aleatorias, entonces no es mala. Mientras que todos los hashes que pueden filtrarse no sean vulnerables a ser atacados en función del rendimiento de hashing actual, entonces no hay ningún problema. Dicho esto, no puedes garantizar que los usuarios no harán cosas estúpidas (y prácticamente PUEDES garantizar que alguna voluntad lo haga).

En general, los ataques fuera de línea contra hashes son muy rápidos, por lo que la complejidad requerida se vuelve muy alta, muy rápidamente. Si la única opción son los ataques en línea, entonces se puede aplicar una limitación de velocidad que ayuda a prevenir los ataques contra el inicio de sesión y aumenta considerablemente la seguridad, sin embargo, todavía es bueno que los hashes sean resistentes si se filtran.

No conozco ningún documento de la industria, pero la respuesta simple es que las personas que usan cosas creativamente estúpidas como su contraseña son la razón por la que es mala. P @ ssw0rdPa $ sw @ rdpAs $ wOrd no es seguro, incluso si es largo.