Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)

[Rifaat Shekh-Yusef <[e-mail]>]

Nat, John,

Do you guys have any thoughts on this errata?

Regards,
 Rifaat


On Sat, May 23, 2020 at 4:25 PM Benjamin Kaduk <[e-mail]> 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 <[e-mail]>
> >
> > 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
>