RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 7636, "Proof Key for Code Exchange by OAuth Public Clients", September 2015

Source of RFC: oauth (sec)

Errata ID: 5687
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Collin Sauve
Date Reported: 2019-04-09
Verifier Name: Benjamin Kaduk
Date Verified: 2019-04-14

Section 5 says:

Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_verifier"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.

It should say:

Server implementations of this specification MAY accept OAuth2.0
clients that do not implement this extension.  If the "code_challenge"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility revert to the OAuth 2.0 [RFC6749]
protocol without this extension.

As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not
and SHOULD send the additional parameters as defined in Section 4 to
all servers.

Notes:

The code_verifier is not sent in the authorization request.

Status: Reported (2)

RFC 7636, "Proof Key for Code Exchange by OAuth Public Clients", September 2015

Source of RFC: oauth (sec)

Errata ID: 6179
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Dmitry Khlebnikov
Date Reported: 2020-05-18

Section 7.3 says:

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.

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.

Errata ID: 6471
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Tom Crossland
Date Reported: 2021-03-10

Section 7.1 says:

The client SHOULD create a "code_verifier" with a minimum of 256 bits
of entropy.  This can be done by having a suitable random number
generator create a 32-octet sequence.  The octet sequence can then be
base64url-encoded to produce a 43-octet URL safe string to use as a
"code_challenge" that has the required entropy.

It should say:

The client SHOULD create a "code_verifier" with a minimum of 256 bits
of entropy.  This can be done by having a suitable random number
generator create a 32-octet sequence.  The octet sequence can then be
base64url-encoded to produce a 43-octet URL safe string to use as a
"code_verifier" that has the required entropy.

Notes:

The "32-octet sequence" referenced in the original text seems to be inconsistent with Section 4.1, which states that the minimum length of the code_verifier is 43 characters. It would be consistent by changing "code_challenge" to "code_verifier".

Report New Errata



Advanced Search