Please do this, or at least scrypt
Maybe that was a reasonable argument in 2018 (though I’d have to see data to be convinced), but no way that is the case in 2020. WASM is in all major browsers now…
Or maybe not switch, but add Argon 2? So that you can choose between the two. I mention this because in the vault settings there’s this menu, but with only 1 choice:
However, I have no idea how doable is this.
As several of you have indicated the strong desire for Argon2 as an option in Bitwarden clients, we have accepted this as requested enhancement. There has also been an update to the related GitHub issue here: https://github.com/bitwarden/jslib/issues/52.
I believe @michaelsmoody has created a fork for this process to get started already and any other collaborators I would encourage to group together on the effort, etc. Please provide any design discussions, decisions and roadblocks so the community and Bitwarden engineering team may assist as necessary. The framework that Kyle has created for KDF was intended to be able to be expanded to support more than a single algorithm.
We will absolutely accept a solid implementation of this feature if all PRs are presented together that meets quality standards and encompasses for each of the Bitwarden clients: Web, Browser, Desktop, CLI, and Mobile. Argon2 may not replace SHA256 as the default but should be an option to be configured by the user. Also, the license for any libraries used may not be GPL based.
Please feel free to post/ask any questions or concerns and thank you again for your support!
My apologies, I’ve been working locally, and haven’t committed to the public repository on my GitHub. With that said, II’ll look into the framework that Kyle created, and I’ll also look into the licensing. Libsodium was what I was working on, in order to provide a multi-platform, well-supported library that supports this and other methods. It is ISC licensed. Is that compatible? Libsodium is of course continually developed, and pretty heavily audited.
Awaiting your replies…
ISC license should be fine, yes. Thanks for checking.
Also, there is inflight implementation of SSO in the works, which includes a new user onboarding flow that may include additional areas of impact, I would recommend keeping your fork up to date and watching any of those PRs that contain the “SSO” keyword.
It wasn’t even a good argument back in 2018. ASICs are 1,000,000x faster than even modern SHA256 hardware accelerated PBKDF2 implementations. They shouldn’t have been focusing on the performance difference between desktop and mobile but any client device and an attacker with custom ASICs.
And Argon2 doesn’t get most of its strength from computation but random memory access. Modern memory is actually slower than PC133 from the '90s in terms of latency. As long as the memory size of Argon2 is configure large enough to overflow cache and force memory access, you’re golden. The concurrency and iterations don’t add nearly as much protection as the memory size.
Even just goolging the topic seems to lead to summaries of actual research and attempts to make Argon2 ASICs that it’s a fools errand and you’re better off buying more cheaper general hardware.
Hope to see this feature implemented soon!
Is there any progress?
We aren’t working on this internally at the moment, as @michaelsmoody has been leading the charge here.
We appreciate his efforts and time!
On that note, you may be interested in the three new security issues in Bitwarden I reported today. (I’m the person who reported this security issue with the KDF (assigned CVE-2019-19766) almost a year ago, which has not been fixed during that time and apparently still nobody at Bitwarden is working on fixing it.)
Details at: Three Major Bitwarden Security Issues
One of them allows anyone who can breach the Bitwarden infrastructure or release tooling/users the ability to steal every password of every desktop application user, via the no-user-intervention autoupdate mechanism. The web app at
vault.bitwarden.com of course already permits such an attack because it’s impossible to protect a webapp’s cryptography code from a server breach (because the code comes from the server itself on each pageload).
All webapps have that issue. Why I almost exclusively use FF/Chrome addon and android app.
The KDF Bitwarden uses is THE industry standard. It is not the best, but it is by no means “insecure”.
I’m not sure how backwards compatible BW is that you could actually use BW without auto-update. All updates are signed and should refuse to install by the OS/browser if not signed. The real question is how robust is the security around their signing system.
AES-256-GCM and Argon2d
This feature increases Bitwarden’s overall security.
Related topics + references
@michaelsmoody any news or any place to see the progress? GitHub?
I hope this feature will have a place in the new 2021 Roadmap!
Also less than a factor difference between Samsung S7, Intel i5, Samsung S20.
Other than development time, I see no reason to not do this. May want to warn the user about setting memory too high. May also want to have some way to test how long it will take for a calculation. A simple page with the config options and a timer would suffice.
It may not be the case it’s entirely about hardware acceleration per se, but hardware in general.
Argon2 looks to be optimized primarily for x86 multi-core and appears to derive its security from memory-hard functions.
Bitwarden must run on a range of architectures, all of which may not have the available RAM to perform large memory-hard processes.
Argon2 is completely configurable. You can do MiB to GiB and beyond. The end user just needs to be aware what platforms they plan on using it. For me it’s desktops with 32-64GiB of memory and cellphones with 6-12GiB.
It effectively comes down to this. pbkdf2 uses almost no memory at all, allowing a GPU to scale nearly perfectly with all of its thousands of cores. Setting Argon2 to even 8MiB would render most GPUs ineffective. It’s not just a total memory issue, but random memory access. Even if a GPU could handle the memory cost, they’re highly optimized for sequential access and limited shared cache.
The main thing is to make it optional, configurable, and maybe come with a decent warning when beyond certain memory parameters.