Cleartext passwords required for digest authentication?

[adepue]

So, if I want to use digest authentication I have to store my passwords as cleartext in the DB? Makes me a little nervous... I'm not familiar with the digest spec, but is there really no way around this?

- Andy

[Ben Alex]

Afraid not Andy.

Quoting our good friends at http://www.faqs.org/rfcs/rfc2617.html:

Note that the HTTP server does not actually need to know the user's cleartext password. As long as H(A1) is available to the server, the validity of an Authorization header may be verified.

and separately:

A1 = unq(username-value) ":" unq(realm-value) ":" passwd

So, it sort of can work without having the cleartext password. However, the hashed value will need to exactly match username + ":" + realm-value + ":" + password. However, you probably didn't store the original encoded password in that hash form now did you? :-)

[adepue]

Fortunately for me, I'm still at that phase in my project where I can change how the password is stored.
Unfortunately, storing the password as cleartext complicates things (such as our backup process, but that's another topic). Anyway, not having looked at the new digest authentication yet, maybe storing my passwords in that form is an option? My security code currently borrows the same PasswordEncoder that is passed into DaoAuthenticationProvider to encode passwords before sending them to the DB. I'm not sure if PasswordEncoder is flexible enough to encode the form you specify, but maybe DigestProcessingFilter could expose a method or interface to my security code so that it could properly encode a password before storing it in the DB? I guess that means DigestProcessingFilter would need some new way to query my DAO for the direct hashed value?

- Andy

[rrsIPOV]

Just my 2cents; but when I first looked into it digest auth seems quite cool, as I explored it more I realized the 'plain' auth over HTTPS is usually a much better solution.

[Ben Alex]

I think most applications with anything to protect will run HTTPS and use form or Basic authentication. It's the most portable solution, too.

Where the opportunity for Digest comes in, though, is if you have a primary interface over HTTPS - such as the webapp - but some secondary interface that is technically too difficult to secure over TLS. A WebDAV web service comes to mind. With WebDAV you don't want users having to have HTTPS support in their clients (many simpler clients simply won't support it) yet you want to preserve the integrity of their password. In such situations, using Digest authentication becomes attractive.

I agree, we should add a static method to DigestProcessingFilter or to a PasswordEncoder to make this more tidy. I'll add it to my TODO list.