134

How does Digest Authentication differ from Basic Authentication other than sending credentials as plain text?

SoftwareGeek
  • 15,234
  • 19
  • 61
  • 78
  • 1
    Great explanation by @Gumbo right here: http://stackoverflow.com/a/5288679/591487 – inorganik Feb 26 '14 at 16:28
  • 3
    Something you should NEVER EVER use. Doesn't protect the password in transit and requires the server to store passwords in plain. – CodesInChaos Jul 31 '15 at 12:16
  • 3
    Digest does provide better in-transit security than Basic authentication for _unencrypted_ traffic, but it's weak. It is MUCH safer to use Basic auth in combination with SSL/TLS instead, because that way you can also keep the passwords on the server encrypted. – rustyx Jul 09 '16 at 14:24
  • It is actually much better to user Digest Authentication with TLS. That way you are not giving out your password to phishing sites. Would be better still if they used a secure hashing algorithm. – Tuntable May 11 '21 at 01:10

3 Answers3

226

The main difference is that it doesn't require sending the username and password across the wire in plaintext. It is also immune to replay-attacks, as it uses a one-time number from the server.

The server gives the client a one-time use number (a nonce) that it combines with the username, realm, password and the URI request. The client runs all of those fields through an MD5 hashing method to produce a hash key.

It sends this hash key to the server along with the username and the realm to attempt to authenticate.

Server-side the same method is used to generate a hashkey, only instead of using the password typed in to the browser the server looks up the expected password for the user from its user DB. It looks up the stored password for this username, runs in through the same algorithm and compares it to what the client sent. If they match then access is granted, otherwise it can send back a 401 Unauthorized (no login or failed login) or a 403 Forbidden (access denied).

Digest authentication is standardized in RFC2617. There's a nice overview of it on Wikipedia:

You can think of it like this:

  1. Client makes request
  2. Client gets back a nonce from the server and a 401 authentication request
  3. Client sends back the following response array (username, realm, generate_md5_key(nonce, username, realm, URI, password_given_by_user_to_browser)) (yea, that's very simplified)
  4. The server takes username and realm (plus it knows the URI the client is requesting) and it looks up the password for that username. Then it goes and does its own version of generate_md5_key(nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
  5. It compares the output of generate_md5() that it got with the one the client sent, if they match the client sent the correct password. If they don't match the password sent was wrong.
Community
  • 1
  • 1
Ian C.
  • 3,783
  • 2
  • 24
  • 33
  • Nice explanation. Are the username & pwd for a windows user? Where are they generated from? – SoftwareGeek Mar 05 '10 at 03:37
  • 1
    They are whatever the user types into the browser. The password needs to match whatever the server has stored for the password for that user. More likely than not it's something specific to that web application and not your Windows password. It very much depends on the way the web application is put together. – Ian C. Mar 05 '10 at 03:48
  • 25
    This answer is 6 years old, but I guess all security-aware systems store passwords in a salted-hash format by now. There is no, and there should not be any, method to obtain the original password from the database making digest authorization impossible. – Ramon de Klein Apr 20 '16 at 15:25
  • 6
    If digest hash of username and password is stored in db instead of plain passwords, then it's still possible to use digest auth @RamondeKlein – karakays Jul 20 '17 at 19:40
  • 1
    @BlueBockser I think karakays meant that instead of using a plain password, a _hash_ resulting from combining both the username and its password should be stored in the server when signing up and computed in the client side before authenticating. It can also be done with just a hash of the password. – logo_writer Aug 01 '17 at 02:33
  • @RamondeKlein How does salting a password protect against Phishing, which is by far the most common form of attack. Digest Auth + TLS would kill phishing if it used a secure hash algorithm. – Tuntable May 11 '21 at 01:12
  • @Tuntable It doesn't help against phishing. Because phising is a common form of attack, it doesn't mean you don't need to prevent other forms of attacks. The only way to deal with phishing is to use 2FA, but that's wasn't the question. – Ramon de Klein May 11 '21 at 07:42
17

A hash of the credentials is sent over the wire.

HA1 = MD5(username:realm:password)

Wikipedia has an excellent article on this topic

Philip Fourie
  • 111,587
  • 10
  • 63
  • 83
1

The only way to get the hash HA1 of the credentials is to know the password. The server knows HA1 but not the password that generated it. If HA1 was known to an attacker it could get in to the system. So it is not sent down the wire. A further hash based on nonce, etc. is done before doing this, and this must agree with a similar calculation done on the server. Thus, as long as the server keeps HA1 private the system is secure.

Chris Oakley
  • 11
  • 1