Talk:Digest access authentication

message: 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)
thread_title:  HA1 ??? 

message: 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)
replies: text: 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)
thread_title:  MD5 security? 

message: "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)
replies: text: 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)
replies: text:  The encyclopaedia's intentions are relevant to the article?  Miqrogroove 01:51, 4 August 2007 (UTC)
replies: text:  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)
thread_title:  Strike This Sentence 

message: 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)
thread_title:  Biased... 

message: 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)
thread_title:  Missing reference... 

message: 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)
replies: text: 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)
replies: text: Okey, thanks Mabdul for fixing this! Mårten Berglund (talk) 13:46, 27 November 2008 (UTC)
thread_title:  Browser Implementation Update 

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

message: 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)
thread_title:  Extra colon before nonce? 

message: 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)
thread_title:  How does one actually use digest access authentication? 

message: "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)
thread_title:  Contradictory term 

message: 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)
thread_title:  cnonce versus clientNonce 

message: Hello fellow Wikipedians,
I have just modified  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 ).
Cheers.—InternetArchiveBot (Report bug) 00:53, 13 December 2016 (UTC)
thread_title:  External links modified 

message: ... time for change  — Preceding unsigned comment added by 85.178.64.81 (talk) 08:37, 3 October 2017 (UTC)
thread_title:  June 2014, rfc 7235 updates 2617  

message: 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)
thread_title:  Salted Challenge Response Authentication Mechanism (SCRAM) 

message: 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)
replies: text: 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)
thread_title:  DIGEST does not require MD5! 

message: 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)
thread_title:  Disadvantages of storing HA1 on the server 

message: 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)
thread_title:  The HTTP scheme was designed by Phillip Hallam-Baker at CERN in 1993