Talk:Digest access authentication
|WikiProject Computing / Security||(Rated B-class, Low-importance)|
|WikiProject Cryptography / Computer science||(Rated B-class, Low-importance)|
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 188.8.131.52 (talk) 20:18, 7 November 2009 (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)
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
- 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)
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)
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.
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. 184.108.40.206 (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)
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 220.127.116.11 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. 18.104.22.168 (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 ":". 22.214.171.124 (talk) Andy Henson 15 September 2010.
How does one actually use digest access authentication?
"reusing the server nonce value" is mentioned in "Example with explanation" below the frame with an example of hashes.
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. 126.96.36.199 (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 188.8.131.52 (talk) 14:13, 1 April 2015 (UTC)