I am aware of Argon2 and it’s benefits over PBKDF2, however, since bitwarden is a cross-platform application that is written on many different languages/frameworks we must use an algorithm that is a standard. PBKDF2 has native implementations on all platforms that we deal with. Argon2 is relatively young and is not yet widely implemented. If we were to use Argon2 we would have to rely on unproven third-party libraries.
Libsodium supports Argon2 and there are bindings for .NET, Java, and Swift. There are also transpilers for JS and WebAssembly.
Users are terrible at choosing passwords and your servers will inevitably get breached.
Between repurposed cryptocurrency mining clusters, probabilistic word lists, and three-letter-agencies plowing hundreds of millions into custom ASICs … your key derivation function is the single most important aspect of your security model. Switching to Argon2 would yield an immediate 3x improvement against brute force attacks on generic GPUs and 10x or more against ASICs.
i’m going to quote 1password’s security whitepaper for this, as it explains perfectly why most almost every password managers chooses PBKDF2 over Argon2:
The choice of PBKDF2-HMAC-SHA256 as our slow hash is largely a function
of there being (reasonably) efficient implementations available for
all of our clients. While we could have used a more modern password hashing
scheme, any advantage of doing so would have been lost by how slowly it
this is why it’s perfectly doable for Keepass, being a native desktop app only (and mobile C#/java ports), but unacceptable for BitWarden
But I guess it won’t be a problem if you install a binary in your system (like lastpass does but for other purposes) or if you have a mobile app.
PBKDF2 isn’t even as good as bcrypt or scrypt so absolutely it should moved away from and since Argon2 has been designed from the ground as the next-generation key-derivation function with industry backing, Bitwarden should switch to it as soon as is reasonably possible.
See how well these run on keeweb compared to the native versions used by keepass2
encrypting a database with a 1 sec delay on Argon2 set by keepass2 take over 10+ seconds to decrypt in the browser, which is unacceptable.
As already noted there are performant variants in all the platforms, except maybe JS for the browser plugin.
Except that I then looked into the WASM performance and it actually seemed reasonable, that is < 1s at the defaults and apparently this can be faster still under LLVM compiled WASM rather than using the older wasm.js, according to the author of the argon2-browser implementation. https://awesomeopensource.com/project/antelle/argon2-browser
Talking about performance, if you’re concerned enough about SHA256 that you have increased the number of iterations to the maximum with the known and warned about impact on performance on slower devices, does it really make sense to cry off about Argon being slow when the users are already taking that penalty with the existing solution?
It’s always worth coming back and reviewing stuff like this, and there seems to be genuine community support to at least implement this change as an option, even if it isn’t the default.
Agreed, is just matter of educate the users about what actually all of this means and how it affects in a REAL WORLD scenario.
“Switch”-to might be aggressive, but if added as an option with perhaps a big bold red sign encouraging users to change… I’m all ears.
BUT you’re talking about Argon2 trough WebAssembly and the original response of Kyle was:
And we’re back at square one (or zero?). Implementing something not widely tested with something even less tested… I don’t see it happening anytime soon, however I’ll cast my vote and wait for when the time is right since now (to be honest), we’re in the theoretic realm.
And we’re back at square one (or zero?). Implementing something not widely tested with something even less tested… I don’t see it happening anytime soon, however I’ll cast my vote and wait for when the time is right since now (to be honest), we’re in the theoretic realm
Actually, Argon2 is 5 years old, or so, at this point, its no longer as young as it was when the reply was first written by Kyle.
The implementations are young in some cases, but everywhere I’ve looked they are usually just wrappers around the C(++?) code implementation. Also, I think that WASM support in browsers is now considered production ready.
Sometimes I forget what time means… for me PGP is still my to-go encryption tool and others are “the new kid on the block”. You’re right, now that we have stupid versioning in the browsers (like Chrome v81) and rolling updates as default, we can count on users having support for (not-so-)edge features.
Hey, it’s good to challenge honestly don’t worry about it. It’s the whole reason why I posted in the first place, Kyle posted something that was reasonable at the time, but that time was two and a half /three years ago and things have changed a bit since then.