Argon2 KDF Support

PR = Pull request, I.e someone writes code and suggests to (in this case) Bitwarden: “Hey, there is this code I wrote, would you like to include (pull) it?”


Oh, ok. So, considering that the core teams are involved in this, you think it won’t be long. Good.


It seems that the password-protected JSON exports are hardcoded to use PBKDF2:

Perhaps this requires a separate PR, but it would be nice if when a user sets the hash function option to Argon2 for their vault, this setting would also be carried over to exports (and Sends).


I already have a PR for this open :wink:

By the way, Sends (which I don’t really use) also have 100K fixed pbkdf2. But they don’t even store the kdf / iterations in the database, so changing it would require another database migration / backend change which I didn’t really feel like taking on considering how low the risk for a send is anyways.


Mobile and Server support has been merged to master :partying_face:, only clients (Web/Desktop/Browser/CLI) is still in-progress.


Good stuff! I have one comment regarding the Argon2id default parametes as I noticed that you have chosen extremely conservative default values:

export const DEFAULT_ARGON2_MEMORY = 19;

It seems that the default values are based on the OWASP recommendation which I believe applies to server side operations where you may have a significant number of hashing/key derivation operations at the same time. This is not the case with Bitwarden as the key derivation is done on the client side. KeePass, for example, recommends following method to determine the memory parameter:

Find out the RAM size of each of your devices on which you want to open your database file. Let M be the minimum of these sizes. Set the memory parameter to min(M /2, 1 GB) (i.e. use the half of M , if it is less than 1 GB, otherwise use 1 GB).

1 Like

I agree, they are based on OWASP. The defaults should run on all devices, so 1GiB is too large as a default. But I have suggested higher defaults on the configuration pull requests, let’s see what the bitwarden team thinks on this.


OWASP recommendations are apparently cribbed from Steve Thomas, who explains the rationale for his recommendations in the Info section at the bottom of his Minimum Password Settings page. The settings are designed to throttle an attacker’s hash speeds to 10kH/s/GPU. Of note is that this is the recommendation when using passwords for authentication purposes only. As I’ve noted in another post, when the password is used for encryption, hash rates should ideally be much slower (<1kH/s/GPU).


Thanks for finding this! I’ll note this on the GitHub thread aswell.


Thanks for the hard work you‘re doing. Really appreciate it.

Have a nice day

Updated defaults now to Iterations = 3, Memory = 64MiB, Parallelism = 4 from RFC9106’s recommendation on “safe defaults”. If you have significantly worse system specs, then you can go lower. If you have higher specs on your devices you can go higher.


The recommended defaults in RFC9106 also specify “128-bit salt, and 256-bit tag size” — are these specs also implemented in your PR?

The salt is the email, so we don’t directly influence how many bit’s it has. Since it has to be at least 8 bytes, I had to update it to be the SHA256 hash of the email such that even very short emails will work correctly. So it is 32 Byte i.e 256 bit.

Tag size = hash size. This is 32 Byte (or 256), same as for PBKDF2.


The last 2 Pull-requests have now been merged! :partying_face:


I saw comments about that WASM support is only affecting old browsers, in this thread and other KDF related threads.

Please be aware, there are modern web browser setups where WASM is disabled by default. Reliance on WASM is not that an optimal solution and I imagine it will break some clients.

By default it is enabled in (nearly) all popular, modern browsers (WebAssembly | Can I use... Support tables for HTML5, CSS3, etc). Though I agree there are browsers where it is disabled (someone mentioned iOS in lockdown mode, possibly also the Tor browser?). Do you have as specific modern browser in mind?

There is not much that can be done about this unless web browsers natively implement argon2. If that happens, switching out the wasm implementation is only a few lines of code.
Users who have such a browser setup should stick with pbkdf2 for the time being.

Do you have as specific modern browser in mind?

Chromium on OpenBSD by default has WASM disabled.

Ah, I see. Well as I said, can’t do much about that unless browsers implement argon2 natively after it getting added to WebCrypto. My advice would be either to continue using pbkdf2 or to enable WebAssembly in chromium.

Hey @Quexten we’re switching over to Github discussions to keep the PR chats closer to the code. all new threads here are locked, but replies will still function for the time being.

Feel free to resume discussion on Github:

Yeah, I saw that, I just responded to @mkucharski’s question :slight_smile: This PR (set of PR’s) is completed and merged anyways, so I don’t see a need to re-open it on GitHub.