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

Note on OWASP, it is going through massive changes and should not be looked at for about a week. Also settings are now based on benchmarks or theoretical speeds, except bcrypt because "9 feels low".

Argon2id:
m=37 MiB, t=1, p=1
m=15 MiB, t=2, p=1

bcrypt:
cost 12

PBKDF2:
HMAC-SHA1: 720,000 iterations
HMAC-SHA256: 310,000 iterations
HMAC-SHA512: 120,000 iterations

> On 03/20/2021 7:31 PM Jim Fenton <fenton@bluepopcorn.net> wrote:
> 
>  
> 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
> 
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten