Storing password in tables and Digest authentication

The subject of how to store web site users passwords in tables has come up several times on SO and the general advice is to store a hash of the password, eventually an HMAC hash. This works fine for Basic authentication or for forms based authentication (really the same thing). My problem is that I must provide also Digest authentication, aimed at the automated tools connecting to my service. I've been looking at this problem and as I see it, the only hash I can store is the HA1 part of the Digest: the hash of username : realm : password . This way I can validated both Basic/forms and Digest.

My problem is that I don't see any benefit in doing so. Now indeed an attacker cannot use Basic or forms based authentication if he gets hold of my password table (since he only has the hashed value and he needs to send the clear password), but nothing prevents him from using Digest authentication and give a valid response to my service challenge: he simply starts from the pre-computed HA1 from the table and continues the crafting of the response from there (ie. the same thing I'd do to validate a user on the back-end).

Am I missing something? Does the addition of Digest requirement basically makes the storing of hashed passwords a no-op from security pov, an obfuscation at best?

---

The reason I am using pre-computed hashes is not protection against attacks, but to secure users privacy.

Attacker can indeed authenticate, but he cannot (easily) see password of my precious users and compromise other services they are using etc.

链接地址: http://www.djcxy.com/p/3752.html

上一篇: 用于更新和删除的HTTP状态码？

下一篇: 在表中存储密码和摘要式身份验证