w3c / webcrypto

The W3C Web Cryptography API
https://w3c.github.io/webcrypto/
Other
263 stars 53 forks source link

Proposal: better key derivation functions #265

Open bakkot opened 3 years ago

bakkot commented 3 years ago

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.

twiss commented 3 years ago

Hi :wave: 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 commented 3 years ago

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 commented 2 years ago

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

bakkot commented 2 years ago

I've opened an issue in WICG/proposals, per https://github.com/w3c/webcrypto/issues/280#issuecomment-1151509624.