Proposal: better key derivation functions

[bakkot]

pbkdf2 is getting rather old. While it's still acceptable, society as a whole has put quite a lot of work into fast hardware for computing SHA-256 in the past decade. For this reason it is no longer the default recommendation. Specifically, as I understand it, bcrypt and scrypt are the standard boring choices these days (with argon2 sometimes showing up).

Cite: the "password handling" section of this essay gives the right answers for password handling as

Percival, 2009: scrypt or PBKDF2.
Ptacek, 2015: In order of preference, use scrypt, bcrypt, and then if nothing else is available PBKDF2.
Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2.

It would be nice if the web platform exposed something other than the "if nothing else is available" option.

[Edit a few years later: this conflates "password hashing" and "key derivation", which are different. bcrypt is a reasonable password hashing algorithm but not a reasonable KDF, per this. Fortunately both scrypt and argon2 can serve either role.]

[twiss]

Hi 👋 Personally, I definitely agree. It's unfortunate that, if developers are going by what's available in Web Crypto, that they're led to choose PBKDF2. If there is implementer interest for this, it would be nice to add a more modern alternative to the spec indeed.

IMO, it'd make the most sense to add Argon2, as it's the most modern of the three, and https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ seems quite far along.

Key derivation functions somewhat stand out in Web Crypto as one of the few algorithms that don't have any application in TLS (usually one of the main drivers behind implementing crypto in a browser). However, web apps of course have different needs than TLS does. So for those web apps that need a KDF, it would be great to add a more modern one indeed.

[FredericJacobs]

I definitely agree on the need for supporting something other than pbkdf2.

I'm under the impression, but without having any data, that scrypt is deployed at a much larger scale than argon2 and that it might be worth getting it included first. Scrypt already has an informational RFC, and from a security perspective has been proven to be maximally memory-hard.

So I think that Scrypt would be a better candidate shorter-term, and then add argon2 once the RFC has been finalised at the CFRG.

[keks]

The Argon2 RFC has been finalized: https://datatracker.ietf.org/doc/html/rfc9106.

[bakkot]

I've opened an issue in WICG/proposals, per #280 (comment).

[dead-claudia]

FYI, OWASP's cheat sheet very explicitly recommends Argon2id for passwords, with scrypt (based on PBKDF2) as a fallback, only recommending PBKDF2 (with very high iteration counts) when NIST validation is a hard requirement. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

And for scrypt, relying on
crypto.subtle for the inner PBKDF2 is apparently as much as 2x slower than rolling the entire algorithm in JS. (Though, I suspect some of that perf loss comes from inefficient memory usage.)

This has implications for most server-side runtimes that implement https://common-min-api.proposal.wintercg.org/.