starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-26 09:46:00 +03:00

[GH-ISSUE #1166] Please allow custom CLIENT_KDF_ITER_DEFAULT #822

New issue

Closed

opened 2026-03-03 02:03:34 +03:00 by kerem · 7 comments

kerem commented

2026-03-03 02:03:34 +03:00

Owner

Originally created by @julian-klode on GitHub (Sep 30, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1166

Subject of the issue

The .env.template lists a PASSWORD_ITERATIONS variable, but it's not being used in the code:

$ git grep ITERATIONS
.env.template:# PASSWORD_ITERATIONS=100000

In src/db/models/user.rs the default is a constant defined as

    pub const CLIENT_KDF_ITER_DEFAULT: i32 = 100_000;

the same default is also in the sql default value.

I found that 100 000 iterations is fairly fast, and I think 1 000 000 iterations makes a lot of sense, but I can't change it without patching and recompiling.

Your environment

Bitwarden_rs version: 1.16.3
Install method: Built from source
Clients used: latest Android from play store and Desktop from snap store
Reverse proxy and version: Nginx from focal

Steps to reproduce

Set the variable, restart bitwarden_rs, create new vault

Expected behaviour

New vaults are created with specified number of iterations

Actual behaviour

new vaults are created with 100 000 iterations

Relevant logs

N/A

Originally created by @julian-klode on GitHub (Sep 30, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1166 ### Subject of the issue The .env.template lists a `PASSWORD_ITERATIONS` variable, but it's not being used in the code: ``` $ git grep ITERATIONS .env.template:# PASSWORD_ITERATIONS=100000 ``` In `src/db/models/user.rs` the default is a constant defined as ``` pub const CLIENT_KDF_ITER_DEFAULT: i32 = 100_000; ``` the same default is also in the sql default value. I found that 100 000 iterations is fairly fast, and I think 1 000 000 iterations makes a lot of sense, but I can't change it without patching and recompiling. ### Your environment * Bitwarden_rs version: 1.16.3 * Install method: Built from source * Clients used: latest Android from play store and Desktop from snap store * Reverse proxy and version: Nginx from focal ### Steps to reproduce Set the variable, restart bitwarden_rs, create new vault ### Expected behaviour New vaults are created with specified number of iterations ### Actual behaviour new vaults are created with 100 000 iterations ### Relevant logs N/A

kerem closed this issue

2026-03-03 02:03:34 +03:00

kerem commented

2026-03-03 02:03:35 +03:00

Author

Owner

@BlackDex commented on GitHub (Sep 30, 2020):

Hello @julian-klode,

This is incorrect.
That value PASSWORD_ITERATIONS is used when set, but only when a new user is created, not afterwards.

The other value you revere to, CLIENT_KDF_ITER_DEFAULT, is as it states the default when nothing is set.

If you run the following grep you can see this.

grep -i -r ITERATIONS *

This will run a case insensitive and recursive search.

@BlackDex commented on GitHub (Sep 30, 2020): Hello @julian-klode, This is incorrect. That value `PASSWORD_ITERATIONS` is used when set, but only when a new user is created, not afterwards. The other value you revere to, `CLIENT_KDF_ITER_DEFAULT`, is as it states the default when nothing is set. If you run the following grep you can see this. ```bash grep -i -r ITERATIONS * ``` This will run a case insensitive and recursive search.

kerem commented

2026-03-03 02:03:35 +03:00

Author

Owner

@julian-klode commented on GitHub (Sep 30, 2020):

I restarted the server by hand with an environment where it was set to 1e6 iterations, and looked at sqlite database prior to and after account creation and new accounts were created with 1e5 iterations.

But: It seems those are different things. PASSWORD_ITERATIONS is the number of iterations we hash the (hashed) password server side, and is being used; while CLIENT_KDF_ITER_DEFAULT is the number of iterations the client hashes the password (which creates the key we are signing with I suppose).

password_iterations columns indeed reflects PASSWORD_ITERATIONS setting, whereas client_kdf_iter is fixed at 100k and changeable via web vault.

It would be nice to be able to set a different default value for the number of client iterations, as 100 000 is quite low for modern smartphones.

@julian-klode commented on GitHub (Sep 30, 2020): I restarted the server by hand with an environment where it was set to 1e6 iterations, and looked at sqlite database prior to and after account creation and new accounts were created with 1e5 iterations. But: It seems those are different things. PASSWORD_ITERATIONS is the number of iterations we hash the (hashed) password server side, and is being used; while CLIENT_KDF_ITER_DEFAULT is the number of iterations the client hashes the password (which creates the key we are signing with I suppose). `password_iterations` columns indeed reflects `PASSWORD_ITERATIONS` setting, whereas `client_kdf_iter` is fixed at 100k and changeable via web vault. It would be nice to be able to set a different default value for the number of client iterations, as 100 000 is quite low for modern smartphones.

kerem commented

2026-03-03 02:03:35 +03:00

Author

Owner

@julian-klode commented on GitHub (Sep 30, 2020):

FWIW, I can try my hand at this, the change should not be that hard, just replicating the logic for password_iterations for client_kdf_iter.

@julian-klode commented on GitHub (Sep 30, 2020): FWIW, I can try my hand at this, the change should not be that hard, just replicating the logic for password_iterations for client_kdf_iter.

kerem commented

2026-03-03 02:03:35 +03:00

Author

Owner

@julian-klode commented on GitHub (Oct 1, 2020):

Aww, dang. The web frontend submits the number of client iterations, so the default in the code is actually irrelevant. Could do some minimal setting though, that would work.

@julian-klode commented on GitHub (Oct 1, 2020): Aww, dang. The web frontend submits the number of client iterations, so the default in the code is actually irrelevant. Could do some minimal setting though, that would work.

kerem commented

2026-03-03 02:03:35 +03:00

Author

Owner

@BlackDex commented on GitHub (Oct 1, 2020):

Yea, i was thinking about that today, thought it was something the client sets, because it does this when generating the vault data on user creation.

The only thing bitwarden_rs does is prepare a user so that we can validate it if you have invites disabled.
Unfortunately this is also nothing the server returns via there policies if i'm correct, so if you want to have this fixed i think you should suggest to have this configurable upstream for self-hosted systems.

I only don't know if they are willing to add this.

@BlackDex commented on GitHub (Oct 1, 2020): Yea, i was thinking about that today, thought it was something the client sets, because it does this when generating the vault data on user creation. The only thing bitwarden_rs does is prepare a user so that we can validate it if you have invites disabled. Unfortunately this is also nothing the server returns via there policies if i'm correct, so if you want to have this fixed i think you should suggest to have this configurable upstream for self-hosted systems. I only don't know if they are willing to add this.

kerem commented

2026-03-03 02:03:35 +03:00

Author

Owner

@BlackDex commented on GitHub (Oct 1, 2020):

You can only change this afterwards your self via the settings tab in the web-vault.

@BlackDex commented on GitHub (Oct 1, 2020): You can only change this afterwards your self via the settings tab in the web-vault.

kerem commented

2026-03-03 02:03:36 +03:00

Author

Owner

@julian-klode commented on GitHub (Oct 1, 2020):

Yeah, let's close this, maybe I'll just patch web vault. Or really just change the value for the 4 users I have when I set them up.

@julian-klode commented on GitHub (Oct 1, 2020): Yeah, let's close this, maybe I'll just patch web vault. Or really just change the value for the 4 users I have when I set them up.