5

Having just finished the chapter on digest authentication in HTTP - The Definitive Guide, I'm not quite sure what the server stores as the client's secret in its database:

  • the client's plaintext password or
  • an MD5 hash of the client's password concatenated with the username and realm

On page 287 of the book, it reads

The client and the server both know the secret password

Also this answer states that

[digest authentication] makes it necessary to store the passwords at the server in plain or in some equivalent form

This answer also indicates that the server stores the password in plaintext:

the server looks up the expected password for the user from its user DB

Yet RFC 2617 contradicts this (emphasis mine):

Normally [what the server stores] might contain pairs consisting of username and H(A1), where H(A1) is the digested value of the username, realm, and password as described above.

My question is: In the context of digest authentication, does the server store the client's plaintext password or does it store a hash of the plaintext password (combined with username and realm)?

Note: This is a theoretical question, I'm not intending to use Digest Authentication over non-encrypted HTTP and I know MD5 is prone to dictionary attacks.

† With "secret" I mean the string that the client combines with a nonce received from the server and then hashes to send it to the server for authentication.

2 Answers 2

5

It depends on the implementation. Digest authentication is just an authentication mechanism for communicating the credentials. The server will likely receive the plaintext password when the password is initially set, but can choose what it wants to do with it based on implementation. It could store it reversibly encrypted (effectively plain-text) and compare to the hash calculated on both sides (insecure), or it could hash the hash of the input from the user and verify it matches a stored hash that is similarly hashed with the nonce depending on how the server is storing the password.

For a windows server, it will depend on if the domain controller that is backing it has reversible passwords turned on or not.

5
  • 1
    Thanks for your answer AJ! I assume, since the client uses the server-generated nonce to hash whatever secret it is sending to the server, that the server can somehow communicate to the client what the server is expecting: either hash(nonce + username:realm:password) or hash(nonce + hash(username:realm:password)). Commented Jul 28, 2017 at 8:59
  • @MatthiasBraun - I updated my answer. I was a bit rushed and confused digest with basic. The basic concept is still the same, but there were some inaccuracies in my initial answer that should now be fixed. Commented Jul 28, 2017 at 14:57
  • "server will receive the plaintext password" this is wrong for Digest authentication. Wikipedia article about Digest authentication states "The password is not sent clear to the server."
    – Mike
    Commented Nov 17, 2020 at 16:47
  • @Mike "when the password is SET". A system using digest auth isn't going to necessarily use a digest to send the password over for setting. I'm not talking about normal transmission during authentication. I went ahead and modified the answer a bit to make this more clear and also to clarify it is possible a client could hash prior to transmission of the password even on set. Commented Nov 17, 2020 at 17:29
  • @AJHenderson That clarifies my concern, thanks!
    – Mike
    Commented Nov 18, 2020 at 10:58
2

Please read Wikipedia article on Digest access authentication. According to it, the server must either:

  • store cleartext password,
  • store password encrypted using reversible encryption,
  • store digested value of the username, realm, and password.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .