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

[Sam Whited <[e-mail]>]

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

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.

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

Good eye, I'll fix this. Thanks.

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

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.

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

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:
> https://github.com/jimfenton/rehash ). Storing the pepper in an
> environment variable seems like a really bad idea to me.

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

Good idea; will do.

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

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