Argon2 KDF Support

Pull request for mobile argon2id now lives here:

7 Likes

Any idea when this will go live?

1 Like

Considering the Bitwarden team is actively involved in all 3 PRs and mobile and server changes are pretty much finished, I don’t think it should take too much longer. Do keep in mind Bitwarden still needs to do QA on the changes and they have a 5 week release cycle.

7 Likes

Still fairly quick comparatively for any corporate software honestly IMO.
Really glad the team is so quick and ready to accept such changes and work to get them implemented.

4 Likes

Considering the Bitwarden team is actively involved in all 3 PRs

PR? What’s that mean?

Still fairly quick comparatively for any corporate software honestly IMO.
Really glad the team is so quick and ready to accept such changes and work to get them implemented.

That’s open source for you.

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?”

2 Likes

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

@Quexten

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.

2 Likes

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

8 Likes

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;
export const DEFAULT_ARGON2_PARALLELISM = 1;
export const DEFAULT_ARGON2_ITERATIONS = 2;

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.

3 Likes

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).

3 Likes

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

4 Likes

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.

2 Likes

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.

2 Likes