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> > > 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 https://www.ietf.org/mailman/listinfo/oauth
