2009-06-16 10 views
9

El tema de cómo almacenar contraseñas de usuarios en tablas ha aparecido varias veces en SO y el consejo general es almacenar un hash de la contraseña, eventualmente un hash HMAC. Esto funciona bien para autenticación básica o para autenticación basada en formularios (realmente lo mismo). Mi problema es que también debo proporcionar autenticación Digest, dirigida a las herramientas automatizadas que se conectan a mi servicio. He estado viendo este problema y, como lo veo, el único hash que puedo almacenar es el HA1 part of the Digest: el hash de username : realm : password. De esta forma puedo validar tanto Basic/forms como Digest.Almacenamiento de contraseña en tablas y autenticación implícita

Mi problema es que no veo ningún beneficio al hacerlo. Ahora, de hecho, un atacante no puede usar la autenticación básica o basada en formularios si obtiene mi tabla de contraseñas (ya que solo tiene el valor hash y necesita enviar la contraseña clara), pero nada le impide usar la autenticación implícita y dar una respuesta válida para mi desafío de servicio: simplemente comienza desde el HA1 pre-calculado de la tabla y continúa elaborando la respuesta desde allí (es decir, lo mismo que haría para validar a un usuario en el back-end).

¿Echo de menos algo? ¿La adición del requisito de Digest básicamente hace que el almacenamiento de contraseñas hash sea una operación de seguridad punto de vista, una ofuscación en el mejor de los casos?

Respuesta

7

La razón por la que estoy usando hashes pre calculados no es la protección contra ataques, sino para proteger la privacidad de los usuarios.

El atacante puede autenticar, pero no puede (fácilmente) ver la contraseña de mis preciosos usuarios y comprometer otros servicios que están usando, etc.

Cuestiones relacionadas