Aceptar otras contraseñas similares cuando se almacena una contraseña con sal y hash

  

Si alguien tuviera que mantener esta base de datos e intentar descifrar la   contraseñas, permitirían estas combinaciones adicionales significativamente   reducir la fuerza de la contraseña?

Yo diría que no lo haría en esta situación específica. Dudo mucho que estén almacenando tres formas de la contraseña con hash en la base de datos, sino que más bien mezclen tres versiones diferentes de la contraseña proporcionada y la comparen con la única contraseña con hash que se encuentra en la base de datos.

Aquí hay una publicación interesante que explica cómo Facebook tiene esta funcionalidad de contraseña. y si bien no entra exactamente en lo que está pasando en segundo plano, el consenso parece ser que no es un riesgo de seguridad significativo.

La respuesta a esta pregunta depende de dos factores:

1. el vector de ataque
2. la implementación de permitir contraseñas diferentes

Los sitios web deben almacenar contraseñas que no estén en texto sin formato o en cualquier otra forma que permita obtener la contraseña del valor guardado. Por lo tanto, generalmente se utiliza una función hash irreversible, de modo que solo se comparan los hashes de las contraseñas.

Ahora hay principalmente dos métodos para permitir contraseñas similares:

1) (El malo, no debe usarse, solo para completar) Uno podría almacenar muchos hashes diferentes de la contraseña del usuario en la base de datos. Ejemplo: el usuario ingresa 'abc123' como contraseña, y se guardan los hashes de

abc123
Abc123
ABc123
abc!"§

y así sucesivamente. Ahora, al iniciar sesión, hash la contraseña dada y mira si coincide con alguna contraseña del usuario.

2) Solo se guarda el hash de la contraseña real, y en el momento del inicio de sesión, la contraseña dada se altera (si la original no coincide) y las sales resultantes se comparan con la de la base de datos.

Ahora a diferentes vectores de ataque :

Si alguien obtiene la base de datos descrita en el método 1, la seguridad es un poco más débil de lo normal, porque hay muchos hashes diferentes para el usuario y las posibilidades son más altas que una. Con la base de datos del método 2, solo hay un hash, y se debe encontrar la ortografía exacta.

Hablando en términos generales, tienes más entropía en el espacio de tu personaje con el segundo método, porque haces una diferencia entre las letras mayúsculas y minúsculas.

Para un atacante que posee la base de datos (siempre que se realice de manera razonable), no existe un déficit de seguridad con este enfoque.

Pero en el caso de un ataque de fuerza bruta en el sitio web, siempre existe una mayor posibilidad de que el atacante inicie sesión con éxito en la cuenta del usuario. Por lo tanto, se deben tomar medidas adicionales para evitar este tipo de ataque.

La respuesta simple no es realmente. La forma más fácil de lograr esto sería usar un .ToLower () antes de la salazón y el hash, y lo mismo cuando se comprueba la contraseña.

Sin embargo, vale la pena pasar un tiempo pensando en por qué te molestarías. No es el navegador el que hace el uso de mayúsculas después de todo, es el usuario. No es diferente de usar @ en lugar de A o 3 en lugar de e.

En principio, deberías aceptar cualquier cosa que el usuario ingrese como su contraseña sin jugar con ella.

Además, la investigación parece indicar que la longitud de la contraseña y no la complejidad es la mejor manera de ir Midiendo el efecto de Políticas de Composición de Contraseña .