Incremento del factor de trabajo de las funciones de hash a lo largo del tiempo

8

Durante mucho tiempo, las funciones hash han requerido un factor de trabajo para mantener la operación lo suficientemente lenta como para proteger contraseñas individuales en el caso de una fuga de base de datos. Bcrypt y PBKDF2 son ejemplos notables.

También soy consciente de lo que se dice de "No rodar por tu cuenta" cuando se trata de seguridad, pero es fácil imaginar una situación en la que, con el tiempo, el factor de trabajo del esquema de hashing de contraseñas se vuelve demasiado rápido debido al aumento de hardware. También se podría imaginar una situación en la que los propietarios de la base de datos actualicen su propio hardware y, por lo tanto, un factor de trabajo más alto sea adecuado en comparación con lo que se estaba utilizando antes de la actualización del hardware para garantizar una mejor seguridad por contraseña.

El problema viene con tener que "volver a cifrar" una contraseña, ya que no desea almacenar un texto sin formato o incluso una contraseña cifrada en una base de datos, por lo que el sistema no tiene forma de acceder a la contraseña nuevamente para volver a cambiarla. El factor trabajo. Para solucionar este problema, simplemente vuelva a aplicar el código cuando un usuario inicie sesión. Cuando el usuario inicie sesión con su contraseña de texto sin formato ya esté disponible para el sistema, en una verificación correcta de la contraseña, el sistema puede verificar el factor de trabajo anterior asociado con el hash de la contraseña (fácil de hacer en bcrypt) y si es menor que el factor de trabajo estándar seleccionado por los operadores del sistema, entonces la contraseña de texto sin formato se reinicia y se almacena con el nuevo factor de trabajo y la nueva sal. No es necesario restablecer las sesiones ya que se usa la misma contraseña que antes, solo un factor de trabajo y sal diferentes.

Aparte de que la contraseña de texto simple está en la memoria durante un tiempo más largo durante la verificación de la contraseña y un mayor tiempo para verificar la contraseña cada vez que se emite un aumento del factor de trabajo, no puedo encontrar ningún fallo en este modelo. ¿Hay algún fallo de seguridad que haya pasado por alto?

    
pregunta Seth M. Larson 07.04.2016 - 16:03
fuente

2 respuestas

4

Parece que lo has resumido bastante bien.

El único inconveniente que se me ocurre es que los usuarios inactivos en su sistema: seguirán teniendo un factor de trabajo anterior porque es posible que nunca vuelvan a iniciar sesión o que no tengan la oportunidad de iniciar sesión antes de su próxima infracción, es decir, su contenido almacenado. La contraseña es más vulnerable al ataque. Como el factor de trabajo es visible dentro de los datos almacenados, el atacante sabría cuáles están usando la configuración anterior (aunque no sabrán la entropía relativa dentro de cada contraseña).

Para evitar esto, puede desactivar regularmente la cuenta en la que no se haya iniciado sesión durante, por ejemplo, 6 meses, dejando su contraseña en blanco al mismo tiempo. Si necesitan iniciar sesión en el futuro, simplemente pueden acceder a su funcionalidad de contraseña olvidada para habilitar una nueva contraseña para ser configurado y almacenado con el nuevo factor de trabajo.

    
respondido por el SilverlightFox 07.04.2016 - 16:41
fuente
3

Un punto clave es que tiene los hashes de contraseña en su base de datos para que no tenga que volver a hash la contraseña. Digamos que los hash (correctamente, con sal ect.) N veces. Para duplicar su factor de trabajo, puede repetir los hashes N más veces en la base de datos. Y luego aplique este mismo refrito para iniciar sesión en el futuro. Consulte enlace y ¿Es posible aumentar el costo de BCrypt o PBKDF2 cuando ya está calculado y sin la contraseña original? para más detalles.

    
respondido por el AstroDan 07.04.2016 - 16:50
fuente

Lea otras preguntas en las etiquetas