[owasp-intrinsic-security] HTTP Authentication

Bil Corry bil at corry.biz
Mon Nov 3 14:59:50 EST 2008

Giorgio Maone wrote on 11/3/2008 4:05 AM: 
> The big drop is that the server needs to know the password, i.e. it needs to
> be *stored* in plaintext.

The server can also choose to store the hash instead of the cleartext password:

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.


Admittedly, that does mean using MD5 as the hash.  Not exactly the most secure method to store passwords, but better than cleartext.

> BTW, as long as you're strictly on HTTPS, basic auth is fine for web
> services *and* lets you store just password hashes.

Yes, this is the preferred way as it allows you to store the passwords on the server using any hash you want and is no different than having the client send the username/password in cleartext via a POST over HTTPS.  Well, not quite, the big difference is the POST (un/pw) is sent once then typically a session cookie is created, while the HTTP Auth header (with cleartext un/pw) is sent on every request.  And as I stated at the start of this thread, once the client has cached the HTTP Auth info, it doesn't let go of it and the server has no way to tell the client to release the cached Auth info.  There is a workaround I use, but it seems HTTP Authentication could be greatly improved in this area.

And FWIW, a downside to Basic Authentication is that it doesn't send the Realm information with the Auth header (as Digest does), so if you have two different Realms on your system, you don't know which Realm the Basic Auth header is for.

- Bil

More information about the owasp-intrinsic-security mailing list