[kitten] Comments on draft-ietf-kitten-password-storage-00

[Jim Fenton <[e-mail]>]

Hi,

I'm not generally up to speed on the work of the kitten WG, but someone
pointed out this draft and thought I'd be interested, and I am. Please
bear that in mind if some of my suggestions conflict with GSS-API,
Kerberos, etc. And I'm not familiar with the various SASL mechanisms so
don't have any comments on them.

1.1 Terminology

Since the term "salt" is so widely used in this document, it would be
good to reference a specific definition, since RFC 4949, SP 800-132, and
SP 800-63-3 all have different definitions.

For "pepper", does "not unique" mean that there is one pepper value for
the entire database that is stored separately? This would be OK if the
database is salted as well (need to de-duplicate cases where different
users have the same password).

3.1 Mechanisms

The end of paragraph 4 talks about providing a strong authenticator
assurance level. In NIST SP 800-63B, authenticator assurance level is a
categorization of authentication transactions (1-3), and single-factor
authentication such as a password is only ever AAL1 regardless of how
it's done. I suggest a different term be used here.

4.1 SASL requirements

Hashes that are unsuitable for use with authenticators such as SHA256:
Should explain what makes them unsuitable. I gather that's because
SHA256 is too fast, especially with all the stuff developed for
cryptocurrency mining. But really all hashes are too fast to be used
alone; they need to be used iteratively or as part of a key derivation
function that is hopefully time- and memory-hard.

4.2 Storage

Salts don't really need to be random; they just need to be unique, and
long enough to make it impractical to construct a rainbow table. "If it
is stored": the salt, I assume? Please be specific. The pepper value
should be stored at arm's length from everything else, such as in an HSM
or otherwise separate place (example:
https://github.com/jimfenton/rehash ). Storing the pepper in an
environment variable seems like a really bad idea to me.

As I mentioned above, a minimum salt length of 16 bytes seems excessive.
NIST SP 800-63B requires 32 bits. Similarly, 32 bytes for the pepper is
more than is really needed; SP 800-63B calls for 112 bits (but calls it
a "salt" which is confusing).

4.3 Authentication and rotation

Paragraph 2, "iteration count" - some algorithms refer to this as a work
factor so suggest "iteration count or work factor".

Paragraph 3, Pepper rotation: In cases where the password is salted and
iteratively hashed, and then a keyed hash with the pepper value is
performed after that, it has been suggested that the keyed hash could be
replaced by a keyed encryption, which has the advantage of allowing the
key to be rotated by sending the verifier values to the peppering
process, which could decrypt the verifiers with the old key and
reencrypt with the new key. This makes a lot of sense; encryption isn't
really a problem here because there isn't a practical brute force threat.

6. Password complexity

Replace blacklist with blocklist, denylist, or something else of course.

"(when paired with the same email or other uniquely identifying
information)" - This would only result in denial of use of a password if
it was used by the same account, when really we want to deny the use of
things like passw0rd entirely. So just compare against the list without
identifying information (which you don't want to have anyway). I'd leave
out the part about commonly used patterns -- that leads down a slippery
slope to the complex composition rules we have today, when really we
just want to make sure common passwords aren't used. So if "aaaaaaaa" is
considered a common password, just put it on the blocklist.

I'm happy to discuss any of this further. Thanks for putting together
this draft.

-Jim