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

More generally, the OWASP recommendations will change and this document 
won’t, so it’s not a good idea to refer to what OWASP currently says 
but rather to point to them as a source of current advice.

-Jim

On 20 Mar 2021, at 18:35, steve@tobtu.com wrote:

> 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
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten