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

[Jim Fenton <[e-mail]>]

Some comments on the draft:

Abstract: “other authentication secrets”: There are authentication 
secrets with high enough entropy that iterated/salted/peppered storage 
is overkill. An example (although I’m not sure how relevant to SASL) 
is a secret used for generating time-based one-time passwords; in this 
case you can’t hash the secret at all. I’d suggest targeting this 
more specifically to modest-entropy secrets (memorized secrets being the 
obvious example).

1.1 Pepper definition: “They must not be stored alongside…” This 
is a normative MUST, so all caps. But the better place to put a 
normative requirement like this is probably in section 4.2 rather than 
in the definition.

3.1 “man in the middled”: aside from the verbing of a common term, 
this is inappropriately gendered. Suggest “has successfully executed 
an in-the-middle attack”

3.2 “authenticators”: suggest “authentication secrets” (2 
places). Similarly in 4.1; perhaps other places.

4.1: I’m concerned that the MUST NOT here conflicts with the SHOULD 
NOT regarding OBSOLETE and LIMITED mechanisms in Section 2. Of course, 
MD5 is not an SASL mechanism per se, and “support any mechanism” in 
this context may not necessarily mean an SASL mechanism, but I still 
found this vaguely confusing.

4.2: “more up to date numbers may be found in [OWASP.CS.passwords]” 
I couldn’t find this in the OWASP recommendations. As I think I 
commented before, I think the salt and pepper minimums are too large. 
Salt is needed to make rainbow tables impractical and to deduplicate 
entries with the same password, so 32 bits should be sufficient (this 
value is used in NIST SP 800-63B). The pepper value needs to be large 
enough to resist brute-force and other likely attacks; NIST SP 800-131A 
specifies 112 bits. I’d suggest not getting carried away on the 
minimums.

4.3: “using a cryptographically secure hash such as SHA256” is a 
poor example because elsewhere it says not to use plain SHA256 since 
it’s fast. Suggest you use a real KDF as an example.

5.2: Bcrypt is no longer the current (top) OWASP recommendation.

7: Suggest saying something about Unicode characters and password 
length, that the 8 character minimum doesn’t mean 8 bytes of Unicode. 
SP 800-63B says, “Each Unicode code point SHALL be counted as a single 
character” which is better but I’m not sure is the perfect wording 
since accents, etc. are code points and the Scottish flag is apparently 
7 code points.

-Jim