Según enlace nginx puede leer hashes de contraseñas de estos tipos:
crypt (), apr1, SHA1 & SSHA.
Así es como entiendo cómo funcionan estos hashes y cuál es el problema con ellos:
crypt () descarta todo después del carácter 8., así que si mi contraseña es "12345678UltraSecurePa $$ w0rd" Puedo iniciar sesión correctamente escribiendo "12345678". ¿Eso no anula el propósito de una contraseña fuerte (larga)? Brutar a través de 8 contraseñas de cualquier personaje parece ser trivial en estos días. No entiendo por qué la cripta debería ser más segura que el texto simple.
apr1 es MD5 pero se desaceleró mil veces . Que todavía es muy débil en estos días. Uno puede encontrar informes de fuerza bruta a través de > 300.000.000.000 (300 mil millones) hashes por segundo con un par de GPU .
SHA1 no es mucho mejor que MD5, es un algoritmo de hash optimizado para ser rápido y, por lo tanto, es vulnerable a los ataques de fuerza bruta. Tampoco está salado en este caso.
Y el último método es SHA1 salado. Este parece ser el método menos débil para codificar las contraseñas de autenticación básica de http en nginx. Pero cuando alguien roba el hash, también tiene la sal (la sal solo está codificada en base64), por lo que SSHA aún tiene la debilidad de usar algoritmos de hashing rápido para "cifrar" las contraseñas.
nginx no puede usar bcrypt o PBKDF2.
Para concluir: si quiero que mis hashes de autenticación HTTP básicos sean "seguros" (seguro significa que es demasiado caro descifrarlos). Tengo que seguir estas reglas:
- nunca uses cripta.
- haga cumplir las contraseñas con al menos 16 caracteres porque esto parece ser lo suficientemente largo contra los ataques de fuerza bruta (ignoremos los ataques de diccionario aquí por un momento).
Y: convenza a los chicos de nginx de que deberían implementar mejores métodos de hashing para la autenticación básica de HTTP.
¿Hay algún error en mi conclusión?