¿Cómo hacer que las contraseñas débiles sean más fuertes?

La única forma de hacer que las contraseñas sean más seguras es no permitir contraseñas débiles. La razón por la que una contraseña es débil es que un atacante puede adivinarla, no por la forma en que la almacena.

He encontrado que enlace es un gran recurso para estudios académicos sobre contraseñas. Es posible que le interese Diseño de políticas de contraseñas para fortaleza y usabilidad , que explora la efectividad de las políticas para hacer que las contraseñas sean difíciles de adivinar. Y lo fáciles que son para recordar.

Si me inscribo en su servicio y uso la contraseña "contraseña", todo lo que está haciendo su proceso es realizar mucho trabajo para hacer hash, salt, rehash, resalt y asaltar la misma contraseña. Luego lo guardas en tu base de datos.

Todos los datos que desea "agregar" deben almacenarse en algún lugar y, si se almacenan, se pueden recuperar.

No veo ningún beneficio para su propuesta sobre la realización de los procesos estándar de hashing y salado.

Porque al final, mi contraseña sigue siendo "contraseña" ...

  

¿Debería este proceso hacer que las contraseñas sean más seguras / más seguras?

No

La única forma de hacer que las contraseñas sean más fuertes es aumentar la longitud. la complejidad ayuda un poco, pero la entropía de las contraseñas aumenta significativamente más cuando la contraseña es más larga que cuando "se requieren" más caracteres para ser usuarios. por ejemplo: el aumento de 5 caracteres más en el alfabeto aumenta la complejidad de la contraseña con el alfabeto + 5 ^ n caracteres. mientras que aumentar la cantidad de caracteres aumenta la complejidad con Alfabeto ^ n + 5 caracteres. el último es exponencialmente más que el primero.

El problema fundamental es que el cliente solo necesita saber su contraseña y ésta puede ser débil.

Lo que usted propone es, en efecto, no cambiar el hecho de que utiliza PBKDF2 para almacenar las contraseñas o la contraseña básica del cliente.

Creo que su problema podría ser sobre el modelado de amenazas: ¿contra qué riesgos está ahora protegido (se está exponiendo la base de datos de contraseñas) y contra qué riesgos adicionales está tratando de evitarlo?

No creo que exista un gran desacuerdo acerca de que las contraseñas de los usuarios sean problemáticas en el mundo real, y en el mundo real, existen algunos sistemas ampliamente adoptados, que tienden a caer bajo el concepto general de 2FA.

Bajo este otoño, elementos como tokens de hardware, generadores de códigos TOTP / HOTP (es decir, Google Authenticator), códigos SMS (que son TOTP, AFAIK) y x509 (es decir, certificados SSL).

Creo que la solución en su caso es imponer requisitos de contraseña (más fuertes) o buscar una segunda contraseña, usar certificados de cliente o usar algún otro medio para implementar 2FA de alguna forma.

O ambos.

El proceso que describiste no hace que la contraseña sea "más fuerte", solo estás haciendo que el proceso de hash sea más complejo de una manera que no dificulte tanto a un atacante. Debería suponer que un atacante que tuvo acceso a los hashes de contraseña también tuvo acceso a todos los demás datos de su base de datos, incluidas las sales (KMS y PBKDF), en este caso, su esquema de hashing no proporciona ninguna seguridad adicional

Las políticas de contraseña son la única forma de garantizar una seguridad mínima de la contraseña. Dado que el factor más importante para la seguridad de la contraseña es la longitud de la contraseña, puede requerir una longitud mínima y simplemente recomendar el uso de números y / o caracteres especiales si no desea restringir tanto a sus usuarios

Además de eso, es posible que desee proporcionar algún tipo de autenticación de dos factores como Google Authenticator o un token físico. Esto no hará que las contraseñas sean más seguras, pero proporcionará una capa adicional de seguridad

A menos que su cadena aleatoria adicional se almacene en un HSM , proporcionará un pequeño beneficio adicional.

En cambio, la mejor defensa contra contraseñas fáciles de descifrar es una combinación de tres cosas:

1. Hashing contraseñas con un hash muy lento como bcrypt o scrypt , con factores de trabajo de alto costo (un alto número de rondas, etc.). Esto ralentiza los ataques fuera de línea de alta velocidad (diccionarios, máscaras, reglas, fuerza bruta, etc.)

2. No permitir contraseñas conocidas con una lista negra. Esto reduce aún más la utilidad de los ataques directos de diccionario.

3. Apoyar a los usuarios en la elección de contraseñas largas por A) que requieren una cierta longitud mínima; B) alentar el uso de frases de contraseña generadas aleatoriamente (para las contraseñas que deben recordarse) o cadenas generadas aleatoriamente (para las contraseñas que se pueden almacenar en un administrador de contraseñas); y C) proporcionar una interfaz de usuario que admita contraseñas largas (permitiendo pegar contraseñas en el campo de la contraseña, etc.)

Los métodos tradicionales para mejorar la seguridad de las contraseñas como las reglas de composición están en desuso. Requerir contraseñas más largas es más efectivo que los requisitos de complejidad / composición, como se señala en en el borrador del NIST 800 -63b . Las plataformas de crack deben usar rules que imitan la psicología de cómo las personas crean contraseñas memorables que satisfacen dichos requisitos, lo que reduce la utilidad de las reglas de composición.

En cambio, fomente las frases de contraseña generadas aleatoriamente. Pueden ser memorables, pero a la vez resistentes a los ataques de fuerza bruta. La introducción de esta alternativa claramente a los usuarios (como en esta política de Stanford ) les permite elegir buenas contraseñas.

No podemos dictar completamente la selección de la contraseña, pero podemos controlar la implementación del lado del servidor. Los hashes lentos y las listas negras son esenciales para esto.