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

[Sam Whited <[e-mail]>]

Hi Jim et al,

Thanks for your reviews, I have published version 01 of the I-D which I
believe captures all of your feedback.

Thanks again,
Sam

On Fri, Sep 4, 2020, at 20:53, Jim Fenton wrote:
> 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
>
>
>

-- 
Sam Whited