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

From: Jim Fenton <[email-masked]>
Date: Fri, 4 Sep 2020 17:53:32 -0700

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

---

From: Robbie Harwood <[email-masked]>
Date: Tue, 22 Sep 2020 12:59:29 -0400

> don't have any comments on them.

Hi Jim, thanks for taking a look.

Sam, have you had a chance to take a look at the review?

Thanks,
--Robbie

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 24 Sep 2020 13:36:33 -0400

My apologies, I don't really follow this list so I missed this reply. I
do need to make an update since I've received other feedback off list,
so replies inline (TL;DR — mostly I'm in agreement and will fix everything):

On Fri, Sep 4, 2020, at 20:53, Jim Fenton wrote:
> good to reference a specific definition, since RFC 4949, SP 800-132,
> and SP 800-63-3 all have different definitions.

I think the definitions these documents use are compatible and are
saying the same thing, but maybe it's worth pointing at a specific
definition for clarity.

> 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).

Yes, the pepper is used alongside the salt and resides outside the
database (eg. it may be baked into an application, or part of a config
file). I will attempt to clarify this.

> 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.

Good eye, I'll fix this. Thanks.

> function that is hopefully time- and memory-hard.

I am using my terminology loosely here, you're correct, I should be
saying "hashes are unsuitable, use a KDF" not "some hashes like PBKDF.2
are okay, but other hashes like SHA256 are not", which is not really
accurate enough for this document.

> long enough to make it impractical to construct a rainbow table. "If
> it is stored": the salt, I assume? Please be specific.

I think recommending randomness is still probably a good idea, but this
is fair. Will update.

> The pepper value should be stored at arm's length from everything
> else, such as in an HSM or otherwise separate place (example:

I disagree that storing it in an environment variable is bad (though of
course a HSM would be ideal), the point of the pepper is to provide a
separate value that isn't stolen if eg. the attacker can steal the
database. Of course, if the attacker can steal the DB they *may* be able
to enumerate environment variables as well, but then again they may not.

> 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).

I took these values from OWASP recommendations which are often more up
to date than the SP series, I'll make sure that's cited correctly.

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

I'll make sure the definitions mention this (and are referenced on first
use of the term).

> Replace blacklist with blocklist, denylist, or something else

Good idea; will do.

> 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.

Good idea; I've done pattern based stuff before for a company I worked
for, and it really does end up just being a mess for very little value
(I suspect).

Thanks for the feedback! I've recently started a new job so I'm not sure
if/when I'll have time to update this document again, but I am saving
feedback and will attempt to prepare a future update at some point.

—Sam