2009-06-16 5 views
9

Le sujet de la façon de stocker les mots de passe des utilisateurs du site Web a été soulevé plusieurs fois sur SO et le conseil général est de stocker un hachage du mot de passe, éventuellement un hachage HMAC. Cela fonctionne bien pour l'authentification de base ou pour l'authentification basée sur les formulaires (vraiment la même chose). Mon problème est que je dois fournir aussi l'authentification Digest, destinée aux outils automatisés se connectant à mon service. J'ai regardé ce problème et comme je le vois, le seul hash que je peux stocker est le HA1 part of the Digest: le hachage de username : realm : password. De cette façon, je peux valider à la fois Basic/forms et Digest.Enregistrer le mot de passe dans les tables et l'authentification Digest

Mon problème est que je ne vois aucun avantage à le faire. Maintenant, un attaquant ne peut pas utiliser Basic ou l'authentification par formulaire s'il obtient ma table de mot de passe (puisqu'il n'a que la valeur hachée et qu'il doit envoyer le mot de passe), mais rien ne l'empêche d'utiliser l'authentification Digest et donne une réponse valide à mon défi de service: il commence simplement à partir du HA1 pré-calculé de la table et continue l'élaboration de la réponse à partir de là (c'est la même chose que je ferais pour valider un utilisateur sur le back-end).

Ai-je raté quelque chose? Est-ce que l'ajout de l'exigence Digest rend fondamentalement le stockage des mots de passe hachés comme un non-op du pov de sécurité, une obfuscation au mieux?

Répondre

7

La raison pour laquelle j'utilise des hachages pré-calculés n'est pas la protection contre les attaques, mais pour assurer la confidentialité des utilisateurs.

L'attaquant peut en effet s'authentifier, mais il ne peut pas (facilement) voir le mot de passe de mes précieux utilisateurs et compromettre les autres services qu'ils utilisent, etc.

Questions connexes