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.
Just a guess, but I would assume that PBKDF2 (or SHA256) has hardware support which may be required for good performance while other algorithms don’t. This may be especially relevant on mobile
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
would run within JavaScript in most web browsers
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.
If it takes 10 secs in javascript and 2 secs with the binary I can live with that just in order to have a better security.
Bitwarden has a C# and JavaScript codebase and while there is a native PBKDF2 implementation available in the browser, there are C#, JS, and WASM ports of Argon2. They could split the hashing, with X rounds of PBKDF2 in the browser and X rounds of Argon2 on the server.
Hell, I would advocate setting up GPU instances just for handling the key derivation load. When combined with hash caching, you would really be giving password crackers a run for their money!
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.
I’ve created a (planned to be temporary) fork at https://github.com/michaelsmoody/bitwarden-jslib-argon2. If you would like access to help move to Argon2, let me know. The goal is simply to do the work, and create a PR for upstream, rather than being a permanent fork.
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.
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.