Hi Dmitry, Thanks for clarifying the motivation. I think it's shifted my stance a bit, to lean more towards classifying as "editorial" (in that the protocol in the RFC itself is not affected) with status of "Hold for document update".
-Ben On Tue, Jun 02, 2020 at 12:32:48AM +0000, Dmitry Khlebnikov wrote: > Naveen, > > My concern with that section is that it provides misleading information about > salting and that was the primary reason I was recommending to remove it. > However, knowing that we cannot amend what was already released as RFC > (Unfortunately, somehow I missed the discussion in 2014 when I could have > influenced that part), even if we make an errata saying that this part of the > RFC is not applicable and one should not even think about applying a salt to > a single unique hash the number of people confused and not being aware of the > errata is going to be significant. Still, I think it is the right thing to do > for those who are seeking for the information. > > What prompted me to write it up (the request for errata) was that in a week I > had several people approaching me in regard to this RFC and asking for advice > (I am a Senior Security Adviser for one of Australia's largest realestate > advertising platforms). This coupled with the overall misunderstanding of > salting (a techique against rainbow tables) and peppering (a technique to > protect hashes from bruteforcing once the dataset is exfiltrated) of hashes > pushed me to reach out. > > -- > Dmitry Khlebnikov > Senioe Security Adviser // REA Group > +61 428 425291 > > ________________________________________ > From: Naveen Agarwal <n...@ohauth.com> > Sent: Tuesday, 2 June 2020 03:47 > To: Rifaat Shekh-Yusef > Cc: Benjamin Kaduk; Dmitry Khlebnikov; n-sakim...@nri.co.jp; oauth; RFC > Errata System > Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179) > > [External Email] > > > As one of the author, writing from my persona email. > > I think at the time someone must have suggested that we should add a salt for > the code_verifier before hashing and this was added to explain that there is > no need to do that. As Dmitry agreed that salting is not really applicable in > this case and I agree that the section could have been written in a better > way. But I do think when people try to implement they may ask the same > question as they have been told again and again that you should salt your > hashes. So leaving it in place doesn't hurt (as it is not making any bad > recommendation but not doing a great job justifying why we didn't add > salting). > > Thanks > > Naveen > > On Sun, May 31, 2020 at 12:41 PM Rifaat Shekh-Yusef > <rifaat.s.i...@gmail.com<mailto:rifaat.s.i...@gmail.com>> wrote: > Nat, John, > > Do you guys have any thoughts on this errata? > > Regards, > Rifaat > > > On Sat, May 23, 2020 at 4:25 PM Benjamin Kaduk > <ka...@mit.edu<mailto:ka...@mit.edu>> wrote: > Authors, WG, any comments? > > Right now the likely dispositions seem to me to be Editorial/HFDU or > Rejected; the text is noting that salting is not used and attempting to > give an explanation of why that's the right choice. It's not clear that > the WG was in error to include some such discussion at the time of > publication, which is essentially what this errata report is claiming. > > Thanks, > > Ben > > On Mon, May 18, 2020 at 03:04:26AM -0700, RFC Errata System wrote: > > The following errata report has been submitted for RFC7636, > > "Proof Key for Code Exchange by OAuth Public Clients". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6179 > > > > -------------------------------------- > > Type: Technical > > Reported by: Dmitry Khlebnikov > > <dmitry.khlebni...@rea-group.com<mailto:dmitry.khlebni...@rea-group.com>> > > > > Section: 7.3 > > > > Original Text > > ------------- > > 7.3. Salting the code_challenge > > > > To reduce implementation complexity, salting is not used in the > > production of the code challenge, as the code verifier contains > > sufficient entropy to prevent brute-force attacks. Concatenating a > > publicly known value to a code verifier (containing 256 bits of > > entropy) and then hashing it with SHA256 to produce a code challenge > > would not increase the number of attempts necessary to brute force a > > valid value for code verifier. > > > > While the "S256" transformation is like hashing a password, there are > > important differences. Passwords tend to be relatively low-entropy > > words that can be hashed offline and the hash looked up in a > > dictionary. By concatenating a unique though public value to each > > password prior to hashing, the dictionary space that an attacker > > needs to search is greatly expanded. > > > > Modern graphics processors now allow attackers to calculate hashes in > > real time faster than they could be looked up from a disk.. This > > eliminates the value of the salt in increasing the complexity of a > > brute-force attack for even low-entropy passwords. > > > > Corrected Text > > -------------- > > > > > > Notes > > ----- > > The section misrepresents the information about "salting" and the whole idea > > of "salting" is not applicable to a standalone hash. I suggest to drop the > > entire > > section as irrelevant to the rest of the standard. > > > > For some reason the section implies that "salting" is protecting and > > increasing > > entropy of a single hash, which is not what "salting" is about and is not > > the > > reason for the technique. The section is also making a speculative > > assumptions > > about the low-entropy tendency in password hashes and makes an incorrect > > conclusion on the benefits of "salting" for a password hash. > > > > One could argue that the entropy and the complexity required to bruteforce > > a hash > > and a salted hash for the same password (where the same hashing algorithm is > > applied) are approximately the same in most cases (or just slightly more > > complex for the salted version if the producer of the hash used a > > non-standard > > routine in relation of mixing in the salt, e.g. instead of appending the > > salt > > it inserts in in the middle of the password to be hashed). In any case, > > that > > public data is already known to the attacker and it is just a matter of the > > configuration for the bruteforcing tool (such as JohnTheRipper) to > > incorporate > > the knowledge. > > > > Just as an illustration: consider an example password ('abc'), an example > > salt > > ('123'), and that the hash is generated using a concatinated version of > > these > > two (e.g. HASH('abc123')). Since the salt is included with the hash in > > plain > > text, the bruteforcer would just need to set their tool up with the > > "^.*123$" > > pattern making the salt essentially a string terminator which is not > > affecting > > the bruteforce effort in any way). > > > > More and more people I meet are confused about the problem area the > > "salting" > > technique was invented to address: it is to increase the entropy of a set of > > passwords, so the same password would not result in the same hash value, > > with > > the primary goal is to prevent attackers to be able to re-use pre-calculated > > hashes (e.g. rainbow hash tables) or, in the early stages of the attack, to > > make it impossible to quickly assess what hashes the attacker should focus > > on > > (e.g. when you have 1000 hashes and without salts you can easily spot that > > some hashes are the same, which means breaking these one would gain much > > more > > in comparison to unique hashes in the same set). > > > > This being said, I am suggesting to drop section 7.3 completely as > > irrelevant, > > since what we currently have is very confusing and seeds unnecessary and > > wrong ideas that "salting" can improve the security of a single hash by > > itself. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7636 (draft-ietf-oauth-spop-15) > > -------------------------------------- > > Title : Proof Key for Code Exchange by OAuth Public Clients > > Publication Date : September 2015 > > Author(s) : N. Sakimura, Ed., J. Bradley, N. Agarwal > > Category : PROPOSED STANDARD > > Source : Web Authorization Protocol > > Area : Security > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
