Talk:Digest access authentication

HA1 ???

In the overview none of the algebraic acronyms are explained. This is not very helpful. What does HA1 stand for. I'm guessing it means HASH 1 .

Could some kind soul. Who knows what they are doing add some explanation under each equation. E.g Where HA1 stands for Hash 1, HA2 stands for hash 2... etc. —Preceding unsigned comment added by 86.140.38.249 (talk) 20:18, 7 November 2009 (UTC)

I agree with the above. I could not find a definition of what HA1 is (even on google!). I added an expand tag to the page. -Andriyko (talk) 01:07, 4 April 2010 (UTC)

If I'm not mistaken, HA1 is simply a hash string. It does not represent a particular hash method; rather, it is the result of applying the MD5 hash algorithm to the "A1" string, which is in turn the concatenation of the user's username, the authentication realm, and the user's password. Anyway, applying an expansion tag just for this is most unnecessary in my opinion. Wyverald (talk) 06:50, 18 April 2010 (UTC)

MD5 security?

The article talks about "MD5 cryptographic hashing". MD5 has got nothing to do with cryptography. It simply converts a string into a hash value (fingerprint).

It's like putting a meal in a blender: afterwards, it's hard to determine what the meal was. But it's easy to say if it was the same meal as another blended one. Nothing magic, nothing secure, nothing cryptographic.

--Jms 17:58, 30 November 2007 (UTC)

That's might be related to the fact that MD5 is not an ordinary hash function, but a cryptographic hash function. Honeyman (talk) 16:58, 5 March 2010 (UTC)

Strike This Sentence

"RFC 2617 assumes that the scheme is understood and fails to complete the example," I don't see the relevance of that statement to this article. Miqrogroove 08:57, 24 July 2007 (UTC)

Taking the example in the RFC by itself, it is quite difficult to see how you can get from the inputs to the outputs – at least not without actually writing the code to do it. This Wikipedia article tries to make the example as clear as possible, as a better guide to implementation (or understanding an implementation). Perhaps the sentence needs rewording, but the point is that the article is intended to be more useful than the original specification in this respect. Thanks.  — Lee J Haywood 18:59, 24 July 2007 (UTC)

The encyclopaedia's intentions are relevant to the article? Miqrogroove 01:51, 4 August 2007 (UTC)

Erm, well they're my intentions, not the encyclopaedia's. I think you mean that the sentence is very critical and implies an opinion, which really is irrelevant. The sentence was just an introduction to the second section of the example, but I've seen a way to improve it. I've reworded it now. (: Thanks!  — Lee J Haywood 07:32, 4 August 2007 (UTC)

Biased...

One of the first sentences is strange... "This method builds upon (and obsoletes) the Basic access authentication, allowing user identity to be established without having to send a password in plaintext over the network."

• "and obsoletes" is clearly biased and unsupported by any sources.
• "This method builds upon"... well... HTTP Digest Authentication most likely builds upon previous Digest Authentication schemes.

The article is overly positive towards digest authentication, while completely failing to discuss why Digest Authentication schemes have not been successful - while Form based authentication and HTTP Basic authentication has a much higher adoption/acceptance rate.

The article is missing a discussion on the "3.5 Storing passwords" section of Digest RFC, and more importantly the article fails to discuss that the password also has to be known to the server in order to perform "2.2 Digest Operation". This is key to realizing why Digest Authentication protocols are not well suited for i.e. enterprise authentication solutions (where the authentication server is different from the http server, i.e. an LDAP repository, and HA1/cleartext password is not available to http server).

--Blaufish 13:09, 26 September 2007 (UTC)

OK! Some hours later, I think I have resolved bias the problem! I made a minor change of the sentence, and added sections to discuss both advantages and disadvantages of Digest access authentication. I think this produces a richer and more complete understanding of the topic to the reader.

--Blaufish 20:10, 26 September 2007 (UTC)

Missing reference...

I agree it is not vulnerable to the most discussed class of MD5 collision attacks -- since they generate a collision from a know (plaintext,hash) pair -- but we should probably have a suitable reference here rather than just claiming it to be so. --Blaufish 13:18, 26 September 2007 (UTC)

I've changed the wording slightly, emphasizing that no MD5 attack has been shown to be a threat to Digest authentication. Also added references to known MD5 attacks. --Blaufish 21:25, 29 September 2007 (UTC)

Browser Implementation Update

After tests with Microsoft Internet Explorer (MSIE) 6 on 2000 and MSIE 7 on XP and Vista I'm not sure if the limitations mentioned are still present.

Therefore I suggest to update 'In the past ...' or to remove the 'Browser Implementation' section. —Preceding unsigned comment added by Lmuelle (talk • contribs) 17:28, 4 December 2007 (UTC)

The article quotes "Internet Explorer 5.0 and higher" from the source which is misleading since the source is over 6 years old and two version of IE have been released since it was written. This Apache documentation suggests suggest that IE 7 is fully compliant with the RFC. "Internet Explorer 5.x and 6.0" is a much more useful phrasing. 87.194.50.81 (talk) —Preceding undated comment was added at 14:44, 2 November 2008 (UTC).

Firefox is not mentioned here. I will add Firefox, if noone object. There are some other clients as well, mentioned on Apache. Mårten Berglund (talk) 12:19, 25 November 2008 (UTC)

Okey, thanks Mabdul for fixing this! Mårten Berglund (talk) 13:46, 27 November 2008 (UTC)

RFC 2069 or RFC 2617?

Is RFC-2069 still the correct reference? Or, isn't it superc by RFC-2617?--P Todd (talk) 21:26, 23 July 2008 (UTC)

Extra colon before nonce?

Is there a colon between HA1 and the nonce? The formulae given in this article suggest there is, however the standards suggest there is not.

RFC 2069 section 2.1.2 states :

        response-digest     =
         <"> < KD ( H(A1), unquoted nonce-value ":" H(A2) > <">

RFC 2617 section 3.2.2.1 confirms this for both qop and non qop cases.

But RFC 2617 section 5 example code gives:

           MD5Init(&Md5Ctx);
           MD5Update(&Md5Ctx, HA1, HASHLEN);
           MD5Update(&Md5Ctx, ":", 1);
           MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce));

ie, it places a colon before the nonce (like the Wikipedia article).

I cannot believe that both RFC 2069 and RFC 2617 are incorrect, yet I'm reluctant to "correct" this when the example code shows something else. 82.152.115.137 (talk) Andy Henson 15 september 2010. —Preceding undated comment added 15:19, 15 September 2010 (UTC).

Update: Wikipedia is correct. See errata 1796 and 1914 in http://www.rfc-editor.org/errata_search.php?rfc=2617. It seems the , in the standard implies a ":". 82.152.115.137 (talk) Andy Henson 15 September 2010.

How does one actually use digest access authentication?

Assume that I can write server-side php code and client-side javascript. And I want to make use of digest access authentication. What exactly do I do? A fully worked out concrete example would be most appreciated. — Preceding unsigned comment added by Page Notes (talk • contribs) 17:25, 6 July 2011 (UTC)

Contradictory term

"reusing the server nonce value" is mentioned in "Example with explanation" below the frame with an example of hashes.

A Cryptographic_nonce is by definition only supposed to be used once. Does it really get reused? — Preceding unsigned comment added by 85.165.24.166 (talk) 07:32, 11 July 2012 (UTC)

The nonce is used in exactly one protocol exchange and then discarded. While it may appear in more than one message these messages form part of a single transaction. 108.7.229.221 (talk) 20:23, 1 November 2012 (UTC)

cnonce versus clientNonce

In the article we sometimes see "cnonce" (and it is described as client nonce) and other times the article says (in the algorithm details) that clientNonce is needed (e.g. to compute "response=...").

If this really holds the same value, there should be only one of this abbreviation. On the other hand, if they are or could be distinct, it should be noted what the difference is and when they are different — Preceding unsigned comment added by 2.239.144.183 (talk) 14:13, 1 April 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Digest access authentication. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20140714192236/https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf to https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:53, 13 December 2016 (UTC)

June 2014, rfc 7235 updates 2617

... time for change — Preceding unsigned comment added by 85.178.64.81 (talk) 08:37, 3 October 2017 (UTC)

Salted Challenge Response Authentication Mechanism (SCRAM)

This page should definitely reference the Salted Challenge Response Authentication Mechanism which is meant to be a more secure alternative to CRAM-MD5 and DIGEST-MD5. Individualiste (talk) 17:47, 12 January 2018 (UTC)

DIGEST does not require MD5!

The whole article suggests, that HTTP-Digest uses MD5 only and thus suffers from it's flaws. This is wrong!

According to RFC7616 from Sep2015, which obsoletes the old RFC2617, three hash algorithms are supported: MD5, SHA-256 and SHA-512-256. MD5 is the default, though not recommended. --80.136.7.107 (talk) 10:54, 21 June 2018 (UTC)

MD5 is not even the default any more, only "supported", according to this RFC. Unfortunately, this RFC does not address some other cryptographic weaknesses such as not using a salt nor key stretching… Aragorn2 (talk) 09:45, 22 July 2019 (UTC)

Disadvantages of storing HA1 on the server

I noticed that the "disadvantages" section didn't point out the biggest drawback of storing HA1 on the server: if the HA1 is leaked, even though an attacker can't reconstruct the password, just having HA1 lets them construct valid responses to the digest challenge as easily as if they had the password. I edited the 4th bullet point under "Disadvantages" (which as previously worded didn't explain why it was a disadvantage!) to make this clear. This drawback is pointed out right in the already-cited source for that bullet point (https://datatracker.ietf.org/doc/html/rfc2617#section-4.13), so no new citation was needed.

--Penfold81 (talk) 19:34, 7 August 2021 (UTC)

The HTTP scheme was designed by Phillip Hallam-Baker at CERN in 1993

Is there a source for this? The best I could find was the original proposal to the W3C in 1995.

https://www.w3.org/Protocols/HTTP/digest_specification.html

Sean Brunnock (talk) 16:33, 4 February 2022 (UTC)