hashing de contraseñas: maximice las colisiones para almacenar el historial de contraseñas

-2

Para el inicio de sesión activo de un usuario, claramente es mejor usar el algoritmo más lento posible con las menores colisiones posibles para evitar que un atacante inicie sesión como otro usuario.

Cuando se trata de almacenar el historial de contraseñas, la principal preocupación es proteger el texto simple de la contraseña anterior del usuario porque aún pueden usarla en otros lugares o usar una contraseña similar a la actual.

Estoy pensando que un hash MD5 o CRC truncado permitiría al sistema verificar el historial de contraseñas, aunque con falsos positivos ocasionales (el usuario solo puede pensar en otra cosa), pero hacerlos imposibles de revertir *. Cuando digo "imposible", quiero decir que habrían colisión plaintexts por diseño y que serían indiscernibles del texto simple de la contraseña original elegida por el usuario.

Si se debe mantener el historial de contraseñas, ¿es este un enfoque práctico?

Un atacante podría buscar en esas colisiones buscando qué contraseña era más probable la entrada humana, tal vez buscando palabras del diccionario o sufijos del tipo "1234".

¿Con colisiones lo suficientemente altas, ese tipo de estrechamiento sería poco práctico? Tal vez hash la mitad de su contraseña?

¿Demasiadas colisiones del historial de contraseñas no permitirían demasiadas contraseñas nuevas?

    
pregunta Jesse Adam 02.09.2016 - 19:32
fuente

1 respuesta

2

Creo que estás sugiriendo el siguiente diseño

  1. Cuando el usuario crea una contraseña, el sistema almacena un hash lento de la contraseña completa Y un hash rápido de la primera mitad de la contraseña (por ejemplo, los primeros cuatro caracteres)
  2. Cuando el usuario cambia una contraseña, el sistema mantiene el hash rápido en el historial de contraseñas, pero elimina el hash lento

Tenga en cuenta que en el paso 1 debe generar y mantener ambos hashes. No puede generar el hash rápido más adelante, porque no hay garantía de que la contraseña de texto simple esté disponible más adelante, por ejemplo. si el usuario cambia su contraseña utilizando un flujo de trabajo "Olvidé mi contraseña".

No estoy seguro de lo que se supone que esto debe lograr.

Me imagino que lo que pasaría después es

  1. Hacker obtiene una retención de la base de datos de contraseñas
  2. Hacker ataca la contraseña actual / activa a través de su hash rápido para aprender los primeros cuatro caracteres de la contraseña. El ataque es más fácil porque es un hash rápido.
  3. Hacker usa los primeros cuatro caracteres para reducir el espacio problemático involucrado en el craqueo del hash lento
  4. El pirata informático quiebra el hash lento en 1 / 10,000th del tiempo habitual, y aprende la contraseña del usuario

Probablemente no sea una gran idea Jesse.

Si le preocupa que el historial de contraseñas presente un objetivo atractivo para un pirata informático, no almacenar el historial de contraseñas .

Si está intentando acelerar la búsqueda en el historial de contraseñas, primero marque la nueva contraseña y luego compare con los hashes antiguos. Esto es posible si la sal es única por usuario y no por contraseña ( que está perfectamente bien ). En ese momento, simplemente está haciendo una comparación de cadenas, por lo que la velocidad del algoritmo de hash no es un problema.

Además, no haga rodar su propia seguridad .

    
respondido por el John Wu 02.09.2016 - 20:49
fuente

Lea otras preguntas en las etiquetas