Autenticación de usuario web segura incluso después del compromiso de la base de datos del lado del servidor

5

A estas alturas, todos deberíamos saber utilizar bcrypt o scrypt para almacenar hashes de contraseña con sal con un número suficiente de rondas. (Ver, por ejemplo, enlace ) La lección: asuma que su base de datos de autenticación estará comprometida en algún momento.

También debemos saber cómo diseñar cookies de autenticación de usuarios que cumplan con el nivel de seguridad y confidencialidad que nuestra aplicación requiere para usar HMAC con claves por usuario. El artículo más citado que he visto es enlace .

Sin embargo, cada documento y propuesta que he leído que aborda la autenticación segura de los usuarios aborda un conjunto de inquietudes diferentes y superpuestas (por ejemplo, escuchas ilegales, manipulación y ataques de repetición) y, a menudo, tienen como objetivo el almacenamiento de elementos opacos. datos de usuario también.

No puedo encontrar ninguna que aborde cómo hacer que las cookies de autenticación de usuarios del lado del cliente sean resistentes a los ataques, incluso después de que la base de datos de autenticación del servidor haya sido comprometida.

El documento anterior, por ejemplo, solo se basa en el secreto de la clave del servidor. Muchas implementaciones que he visto también generan un token por usuario que se utiliza en el HMAC y se almacena en el servidor. En cualquier caso, una vez que se comprometa el secreto del servidor, es trivial falsificar las credenciales de cualquier usuario.

¿Existen referencias o implementaciones conocidas que cubran este escenario para aplicaciones web típicas (es decir, fuera de los entornos corporativos y bancarios)?

    
pregunta Michael 05.10.2012 - 19:50
fuente

1 respuesta

2

Si todo el servidor está comprometido, entonces lo que el servidor pueda hacer, el atacante también puede hacerlo.

Por lo tanto, la única manera de tener una autenticación de usuario que resista más allá de un compromiso total del servidor es basar esa autenticación en algo que el usuario puede hacer, pero que el servidor no , pero de tal manera que el servidor puede verificar que el usuario lo está haciendo. Esto requiere una firma digital . El usuario debe almacenar de alguna manera una clave privada en algún lugar de su máquina y utilizarla para firmar algún tipo de desafío enviado por el servidor.

La clave privada no debe ser accesible desde Javascript; de lo contrario, el atacante podría colocar un código Javascript que recuperaría la clave privada del usuario. En un contexto web, firmas digitales pero sin el código enviado por el servidor, esto apunta al usuario certificados .

Esto se puede hacer. Además, este está terminado (lo he visto en algunos bancos, emitiendo certificados a sus clientes). SSL es compatible con los certificados del lado del cliente y las versiones recientes del navegador se han vuelto casi fáciles de usar cuando se trata de usarlos. Incluso podría distribuir tarjetas inteligentes (o dispositivos equivalentes que se enchufan en un puerto USB, para facilitar la instalación).

    
respondido por el Thomas Pornin 05.10.2012 - 20:05
fuente

Lea otras preguntas en las etiquetas