KDF values shown wrong(?) in webvault, upon changing algo type. CLIENT ISSUE.

[rdslw]

Vaultwarden Build Version

v1.32.2

Deployment method

Other method

Custom deployment method

personalized docker container

Reverse Proxy

none

Host/Server Operating System

Linux

Clients

Web Vault

Client Version

firefox 131.0.3

Steps To Reproduce

1. change KDF to non default, and i.e. 700007 while being on 1.2* version
2. update container to 1.32.* from below and restart
3. login, see first bug: brown popup saying: "Low KDF iterations. Increase your iterations to improve the security of your account. Change KDF settings "
4. go to 'change KDF setting' panel, and see '100000', (see sqlite verification)
5. while beeing at panel, change type to argon, do not change anything
6. change back to PBKDF2, and see '600000' -> second bug as I did not change anything, just switched tabs.

Expected Result

1. no popup
2. proper KDF 700007
3. no change in KDF displayed upon switching KDF types back & forth

Actual Result

sqlite> select email,password_iterations from users;
x1@x1|100000
x2@x2|700007
x3@x3|700007

Above steps used login x2.
Login x3 also shows bug no 2 (wrong value upon type switching), while there was popup, but was dismissed and does not appear again, ALTHOUGH kdf was not changed.

I'm not sure in which version it happenes.

Logs

No response

Screenshots or Videos

No response

Additional Context

No response

[BlackDex]

Not sure what we can do here. Vaultwarden stores what it receives.
I find the steps a bit strange but will try to reproduce it.

Are you sure you didn't mixed and the Vaultwarden KDF settings with the account KDF settings? Those are two totally different items.

[rdslw]

Thanks for fast reply.

1. as to reproducability: problem no2 (webvault shows different values just on clicking PKDF2 vs argon type) shall be easy to reproduce, as it happens on newest v1.32.2. Can provide short video here if interested to see it.

2. As to the problem no1 (different value in sqlite users table vs what webvault shows) and popup warning -> I'm not sure when it started, probably earlier. while on v1.3?.*

3. I understand that users table, and webavult (settings -> security -> keys) both shows account KDF settings. Am I correct?

4. where can I check/see Vaultwarden KDF settings? config.json + /admin ?

[BlackDex]

Also the kdf can't change without user interaction. Else you wouldn't be able to login again anymore.

[BlackDex]

The Vaultwarden kdf is visible in the admin settings

[rdslw]

ok, so what I'm seeing is relevant to the account KDF settings.

To summarize:

problem 1: popup shows, even if KDF settings (as verified in sqlite) are 700007

problem 2: values shown for KDF settings are wrong (settings -> security -> keys)

a. I have 700007 as sqlite shows
b. go to the settings>security>keys: I see there 100000 as current KDF
c. while being there, change PBKDF2 to argontype, and back (NB: just clicking, no clicking 'change kdf' button.
d. KDF shows 600000 (vaultwarden default)

[BlackDex]

Again, which column are you looking at? Since I am not able to reproduce this at all using the steps you mentioned.

I have done the following.
For the database i used this query:

SELECT uuid, password_iterations, client_kdf_type, client_kdf_iter, client_kdf_memory, client_kdf_parallelism FROM users

1. Started Vaultwarden 1.20.0 (The very first v1.2* version):
   docker run -it -e DISABLE_ADMIN_TOKEN=true -v "${PWD}/tmp:/data" -p8080:80 docker.io/bitwardenrs/server:1.20.0
2. Created a user and checked the database
   
3. Updated the KDF Settings and checked the database
   
4. Upgraded Vaultwarden to 1.32.2:
   docker run -it -e DISABLE_ADMIN_TOKEN=true -v "${PWD}/tmp:/data" -p8080:80 ghcr.io/dani-garcia/vaultwarden:1.32.2
5. Checked the settings and database
   

Database results:

version	uuid	password_iterations	client_kdf_type	client_kdf_iter	client_kdf_memory	client_kdf_parallelism
v1.20.0	5ce61ca9-9694-40ee-bac2-017851ff8637	100000	0	100000	-	-
v1.20.0	5ce61ca9-9694-40ee-bac2-017851ff8637	100000	0	700007	-	-
v1.32.2	5ce61ca9-9694-40ee-bac2-017851ff8637	600000	0	700007	NULL	NULL

I Did the same but then started from v1.29.2 which is the last v1.2* verison.

1. docker run -it -e DISABLE_ADMIN_TOKEN=true -v "${PWD}/tmp:/data" -p8080:80 ghcr.io/dani-garcia/vaultwarden:1.29.2
2. 
3. 
4. docker run -it -e DISABLE_ADMIN_TOKEN=true -v "${PWD}/tmp:/data" -p8080:80 ghcr.io/dani-garcia/vaultwarden:1.32.2
5. 

Database results:

version	uuid	password_iterations	client_kdf_type	client_kdf_iter	client_kdf_memory	client_kdf_parallelism
v1.29.0	cd1b2ee6-aac0-4345-a1a6-20946df19c4d	600000	0	600000	NULL	NULL
v1.29.0	cd1b2ee6-aac0-4345-a1a6-20946df19c4d	600000	0	700007	NULL	NULL
v1.32.2	cd1b2ee6-aac0-4345-a1a6-20946df19c4d	600000	0	700007	NULL	NULL

[rdslw]

I was originally looking at passwords_iterations column.

Here is result of your query run now.
sqlite> SELECT uuid, password_iterations, client_kdf_type, client_kdf_iter, client_kdf_memory, client_kdf_parallelism FROM users
...> ;
X1..e3|100000|0|100000||
X2..12|700007|0|900009||
X3..e4|700007|0|100000||

Looks like problem no1 was my mistake of X2 vs X3 user, which with problem no2 make me no trusting values shown. sorry for that.
shall probably change issue title to "KDF values shown wrong in webavult upon selecting different algo type"

Looks like only problem 2 exists, on both users (X2 and X3).

How to reproduce:

1. use current version v1.32.2

2. login to webavaul

3. go to settings/security/keys, see:
   

4. switch algorithm type to argon, DO NOT click button 'change kdf', see:
   

5. switch again algorithm type to PBKDF2, see wrong iterations:
   

problem no2 visible here: iterations is now 600000 while was 100000 on step 3. User iterations is 100000.

[BlackDex]

Well, that seems like a UI client issue, and it shows the default recommend value. If you do not click on save then it will still be 100_000 unless you save of course.

As this is a web-vault/client issue, and this project does not maintain or develop those, it's not something we can fix (easily).

If anything, I would suggest to check and verify if this also happens on the Bitwarden Cloud environment, if so, report this in there client repo on GitHub. Else it might be fixed already in a version newer than v2024.6.2, which Vaultwarden does not (yet) support.

As this is a client issue, I'm going to move this to a discussion.

[stefan0xC]

So to reproduce you have the client KDF set to 100000, if change the KDF algorithm to Argon2id it loads the recommended defaults for Argon2id and when switching back to PBKDF2 it loads the recommended defaults for that (which is now 600000 instead of the set value). Since you are in the process of changing the settings I don't think there's anything wrong with showing a recommended setting. So I would not consider this a bug but think that this is rather intentional.

[rdslw]

Yep. ( to the @BlackDex ), as to the @stefan0xC I will comment shortly in separate message.

Thank you for your help me on this issue. I appreciate it!

Although it shows default recommended value (being 600000) only after changing alghoritm type not on the first entering the settings, when it shows current value from backend (being 100000).

If you can answer 4 additional questions it would help me better understand for future reports:

1. If I cancel popup, without any changes, it does not appear on subsequent login (even after full logout). Where this cancellation state is stored? Client cookie? DB?
2. 'password_iterations' column from db is "Vaultwarden KDF settings" not account settings, correct?
3. why then it can differ per account basis?
4. what will happen if I update it in config.json and restart bitwarden. Will the store be updated to the new value on first vault change/save by the user?

[rdslw]

So to reproduce you have the client KDF set to 100000, if change the KDF algorithm to Argon2id it loads the recommended defaults for Argon2id and when switching back to PBKDF2 it loads the recommended defaults for that (which is now 600000 instead of the set value). Since you are in the process of changing the settings I don't think there's anything wrong with showing a recommended setting. So I would not consider this a bug but think that this is rather intentional.

First to say, it's a minor issue, but as shown in my report it definitely confused me, which connected with my mistake (which user I'm logged in) created confusion about vaultwarden working.

As to what you say: current behavior, while I understand why it may make sense (2. below) IMHO, is erroneous, because of three things:

1. switching back from argon to PBKDF (without actually changing) is no different than entering settings at start with PBKDF selected from user perspective. IMO it shall either shows current setting, either recommended on both occasion.
2. taking into account that there are two warnings on this page related to KDF, and small grey note about 600k being default, this further complicates understanding what is current value, and what is default and what is recommended.
3. showing recommended values for the argon, which is not in place, looks fine for me. Sth needs to be shown in the fields because there is nothing in the db. But for PBKDF, IMHO it shall be presented as current value from db.

[BlackDex]

1. If I cancel popup, without any changes, it does not appear on subsequent login (even after full logout). Where this cancellation state is stored? Client cookie? DB?

If you mean the popup regarding the Low KDF Warning, that is stored in the browsers local storage.

2. 'password_iterations' column from db is "Vaultwarden KDF settings" not account settings, correct?

That is a Vaultwarden setting. That is used to hash the already hashed master-password the clients send.
This is done to prevent easy decryption of the users/hashed-masterpassword from the database.

3. why then it can differ per account basis?

The hash stored in the database is hashed using the password_iterations amount of iterations.
It can only be updated on a new login of the user, as at that point we are sure a user is logging in using the account password, and we then need to hash that using the current stored amount of iterations. If we then see that the requested iterations is different from what is stored in the database, we use the original master-password hash and hash that using the newly wanted amount of iterations. In Vaultwarden we increased the default from 100_000 to 600_000 and that is why it will change.

4. what will happen if I update it in config.json and restart bitwarden. Will the store be updated to the new value on first vault change/save by the user?

See my answer at 3., which explains what will happen. So in short, it will update the users iteration on first new login (no unlock btw)

---

1. switching back from argon to PBKDF (without actually changing) is no different than entering settings at start with PBKDF selected from user perspective. IMO it shall either shows current setting, either recommended on both occasion.

That is not true. You are switching between possible options. Maybe it is even a way of Bitwarden to force people to a higher standard this way. But i have not had the urge to check the client code for this.

2. taking into account that there are two warnings on this page related to KDF, and small grey note about 600k being default, this further complicates understanding what is current value, and what is default and what is recommended.

I can understand the confusion. But since you entered the page possibly wanting to update it, you should have checked what the original value would be, and else just save to be sure.

3. showing recommended values for the argon, which is not in place, looks fine for me. Sth needs to be shown in the fields because there is nothing in the db. But for PBKDF, IMHO it shall be presented as current value from db.

Again, if that is what you think it should do, verify if this is also done by Bitwarden via there free cloud option.
If it was an issue, and they have solved it, it might be in a newer version of the web-vault which Vaultwarden does not (yet) support. And there currently is not something we can do about changing the way those values are currently shown.

[rdslw]

Thank you kindly for your help @BlackDex !