[PM-24051] Init crypto and update kdf with MasterPasswordUnlock #399

mzieniukbw · 2025-08-19T13:31:06Z

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-24051

📔 Objective

Initialise client with MasterPasswordUnlock via initialize_user_crypto_master_password_unlock in InternalClient, primary used used in auth login methods.
- Moved set_login_method to be the after the initialize_user_crypto function in execution order, since the latter overrides the set_login_method. Move everywhere else for consistency.
Update user's KDF settings with MasterPasswordUnlock via update_user_master_password_unlock in InternalClient, triggered in sync.

Continuation of #376

⏰ Reminders before review

Contributor guidelines followed
All formatters and local linters executed and passed
Written new unit and / or integration tests where applicable
Protected functional changes with optionality (feature flags)
Used internationalization (i18n) for all UI strings
CI builds passed
Communicated to DevOps any deployment requirements
Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
team

🦮 Reviewer guidelines

👍 (:+1:) or similar for great changes
📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
❓ (:question:) for questions
🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed
issue and could potentially benefit from discussion
🎨 (:art:) for suggestions / improvements
❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
⛏ (:pick:) for minor or nitpick changes

…tions

…ption-options-to-identity-sync-response

…r and docs improvements

…ption-options-to-identity-sync-response

…ns-to-identity-sync-response' into km/pm-24051-setting-master-password-unlock-into-state # Conflicts: # crates/bitwarden-vault/src/sync.rs

…ns-to-identity-sync-response' into km/pm-24051-setting-master-password-unlock-into-state

…ption-options-to-identity-sync-response

…ns-to-identity-sync-response' into km/pm-24051-setting-master-password-unlock-into-state # Conflicts: # crates/bitwarden-core/src/auth/mod.rs # crates/bitwarden-core/src/client/internal.rs # crates/bitwarden-core/src/key_management/crypto.rs

…nto-state # Conflicts: # crates/bitwarden-core/src/auth/api/response/identity_success_response.rs # crates/bitwarden-core/src/key_management/master_password.rs # crates/bitwarden-core/src/key_management/mod.rs # crates/bitwarden-core/src/key_management/user_decryption.rs

sonarqubecloud · 2025-09-03T14:43:48Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
7.8% Duplication on New Code

See analysis details on SonarQube Cloud

Thomas-Avery

Mostly just questions for my clarity and a few optional minor changes.

Thomas-Avery · 2025-09-03T21:04:47Z

crates/bitwarden-core/src/auth/login/access_token.rs

+        client
+            .internal
+            .initialize_crypto_single_org_key(organization_id, encryption_key);


💭 question:

initialize_crypto_single_org_key didn't have the side effect of setting the login method? Is this change just to have consistency with the others? I'm a little hesitant because it's SM.

Thomas-Avery · 2025-09-03T21:22:43Z

crates/bitwarden-core/src/auth/login/api_key.rs

+            r.access_token.to_owned(),
+            r.refresh_token.to_owned(),


💭 not a rust expert

It is weird to me that we are keeping .clone() in crates/bitwarden-core/src/auth/login/access_token.rs crates/bitwarden-core/src/auth/login/auth_request.rs and crates/bitwarden-core/src/auth/login/password.rs and only updating to .to_owned() here.

From the rust docs https://doc.rust-lang.org/std/borrow/trait.ToOwned.html

A generalization of Clone to borrowed data.
Some types make it possible to go from borrowed to owned, usually by implementing the Clone trait. But Clone works only for going from &T to T. The ToOwned trait generalizes Clone to construct owned data from any borrow of a given type.

It sounds like we should prefer clone when going from T to T? In this case we want to go from String -> String and Option<String> -> Option<String>.

Agree on this. In this case we are not even going from borrowed data to owned data, so semantically it is confusing saying "to owned" (implying we are converting to an owned object (by cloning usually).

We're going from String to String (T to T), so we should clone.

Thomas-Avery · 2025-09-03T21:46:34Z

crates/bitwarden-core/src/auth/login/api_key.rs

+        if let Some(master_password_unlock) = r
+            .user_decryption_options
+            .as_ref()
+            .map(UserDecryptionData::try_from)
+            .transpose()?
+            .and_then(|user_decryption| user_decryption.master_password_unlock)
+        {
+            client
+                .internal
+                .initialize_user_crypto_master_password_unlock(
+                    input.password.clone(),
+                    master_password_unlock,
+                    user_key_state,
+                )?;
+        } else {


⛏️
Since we care about both branches of logic match might be more readable here thanif let Some(

let master_password_unlock = r .user_decryption_options .as_ref() .map(UserDecryptionData::try_from) .transpose()? .and_then(|user_decryption| user_decryption.master_password_unlock); match master_password_unlock { Some(master_password_unlock) => { client .internal .initialize_user_crypto_master_password_unlock( input.password.clone(), master_password_unlock, user_key_state, )?; } None => { let user_key = r.key.as_deref(); let user_key: EncString = require!(user_key).parse()?; let master_key = MasterKey::derive(&input.password, &email, &kdf)?; client.internal.initialize_user_crypto_master_key( master_key, user_key, user_key_state, )?; } }

Thomas-Avery · 2025-09-03T21:57:49Z

crates/bitwarden-core/src/auth/login/auth_request.rs

+        client
+            .internal
+            .set_login_method(LoginMethod::User(UserLoginMethod::Username {
+                client_id: "web".to_owned(),
+                email: auth_req.email.to_owned(),
+                kdf: Kdf::default(),
+            }));


❓ Looking to clarify.

So this will be a change in behavior? Previously this would get overridden by the initialize_user_crypto setting the final state to:

client .internal .set_login_method(LoginMethod::User(UserLoginMethod::Username { client_id: "".to_string(), email: req.email, kdf: req.kdf_params, }));

With the difference being client_id will be getting set to web now?

Reading through the old flow previously kdf was getting set to default and emails match up.

Odd for initing crypto to have that side effect but I don't understand all the flows.

Thomas-Avery · 2025-09-03T22:03:34Z

crates/bitwarden-core/src/auth/login/password.rs

+            security_state: None,
+        };
+
+        if let Some(master_password_unlock) = r


⛏️ Same comment about the match for readability.

Thomas-Avery · 2025-09-03T22:13:55Z

crates/bitwarden-core/src/client/internal.rs

+            LoginMethod::User(UserLoginMethod::Username { kdf, .. }) => kdf,
+            LoginMethod::User(UserLoginMethod::ApiKey { kdf, .. }) => kdf,
+            #[cfg(feature = "secrets")]
+            LoginMethod::ServiceAccount(_) => return Err(NotAuthenticatedError)?,


Suggested change

LoginMethod::ServiceAccount(_) => return Err(NotAuthenticatedError)?,

LoginMethod::ServiceAccount(_) => return Err(NotAuthenticatedError),

I don't think returning the error needs the unwrap.

Thomas-Avery · 2025-09-03T22:14:07Z

crates/bitwarden-core/src/client/internal.rs

+                    kdf: new_kdf,
+                })),
+                #[cfg(feature = "secrets")]
+                LoginMethod::ServiceAccount(_) => return Err(NotAuthenticatedError)?,


Suggested change

LoginMethod::ServiceAccount(_) => return Err(NotAuthenticatedError)?,

LoginMethod::ServiceAccount(_) => return Err(NotAuthenticatedError),

Thomas-Avery · 2025-09-03T22:20:43Z

crates/bitwarden-core/src/key_management/crypto.rs

+            login_method.as_ref()
+        {
+            assert_eq!(*email, test_account.user.email);
+            assert_eq!(*kdf, test_account.user.kdf_params);


Should we add an assert for the client_id to be the empty string?

quexten

Looks mostly good, I have some stylistic / readability improvements noted.

quexten · 2025-09-04T06:11:10Z

crates/bitwarden-core/src/auth/login/password.rs

@@ -41,26 +42,48 @@ pub(crate) async fn login_password(
            r.refresh_token.clone(),
            r.expires_in,
        );
+
+        let private_key = r.private_key.as_deref();


Looks like this two-line pattern to convert from Option<&str> to EncString repeats a fair bit in this PR. Could we just implement TryFrom<Option<&str>> for EncString, and then remove all of thees temporary variables? It would make this a bit shorter and more readable.

quexten · 2025-09-04T06:11:34Z

crates/bitwarden-core/src/auth/login/password.rs

+                    user_key_state,
+                )?;
+        } else {
+            let user_key = r.key.as_deref();


Ref the comment above about TryFrom<Option<&str>>

quexten · 2025-09-04T06:11:56Z

crates/bitwarden-core/src/auth/login/api_key.rs

            r.expires_in,
        );

-        let master_key = MasterKey::derive(&input.password, &email, &kdf)?;
+        let private_key = r.private_key.as_deref();


Ref the other comment about TryFrom<Option<&str>>

quexten · 2025-09-04T06:12:15Z

crates/bitwarden-core/src/auth/login/api_key.rs

+                )?;
+        } else {
+            let user_key = r.key.as_deref();
+            let user_key: EncString = require!(user_key).parse()?;


Ref the comment about TryFrom<Option<&str>>

quexten · 2025-09-04T06:18:10Z

crates/bitwarden-core/src/auth/login/api_key.rs

+        };
+
+        if let Some(master_password_unlock) = r
+            .user_decryption_options


Suggestion (non-blocking): We have this long chain quite a bit. It may be nice to just implement "master_password_unlock() -> Option" on the decryptionData.

Then, you can rewrite as (untested):

let decryption_data: UserDecryptionData = r.user_decryption_options. if let Some(master_password_unlock_data) = decryption_data.master_password_unlock_data() { client .internal .initialize_user_crypto_master_password_unlock( input.password.clone(), master_password_unlock, user_key_state, )?; } else { client.internal.initialize_user_crypto_master_key( MasterKey::derive(&input.password, &email, &kdf)?, r.key.try_into()?, user_key_state, )?; }

quexten · 2025-09-04T06:53:51Z

crates/bitwarden-core/src/auth/login/api_key.rs

+            r.access_token.to_owned(),
+            r.refresh_token.to_owned(),


Agree on this. In this case we are not even going from borrowed data to owned data, so semantically it is confusing saying "to owned" (implying we are converting to an owned object (by cloning usually).

We're going from String to String (T to T), so we should clone.

quexten · 2025-09-04T06:56:01Z

crates/bitwarden-vault/src/sync.rs

@@ -39,6 +44,18 @@ pub(crate) async fn sync(client: &Client, input: &SyncRequest) -> Result<SyncRes
        .await
        .map_err(|e| SyncError::Api(e.into()))?;

+    if let Some(master_password_unlock) = sync
+        .user_decryption


Ref the comment about implementing the masterpassword function on the decyrption data

quexten · 2025-09-04T07:04:09Z

crates/bitwarden-core/src/key_management/master_password.rs

    /// The key derivation function used to derive the master key
-    kdf: Kdf,
+    pub kdf: Kdf,


Looks like this can be pub(crate) unless I'm missing something?

quexten · 2025-09-04T07:07:40Z

crates/bitwarden-core/src/auth/login/api_key.rs

+
+        let user_key_state = UserKeyState {
+            private_key,
+            signing_key: None,


(Not in this PR) looks like we don't have support for parsing the new keys from the token response here yet. We should make a follow-up ticket somewhere to fix this.

mzieniukbw added 30 commits August 4, 2025 23:40

Adds MasterPasswordUnlock into identity's response user decryption op…

44773f7

…tions

Adds MasterPasswordUnlock KDF change handling in sync

0712878

simplification

8ca20a8

clippy fix

28a8423

formatting

b089ea0

no handling, just response parsing

0d35393

test coverage

a08179d

wasm

b3647f2

wasm unit test coverage

36d3136

wasm unit test coverage

7c8664d

Added UserDecryption data, response model with handling

9c7d50d

autogenerated wasm responses, UserDecryption struct, use of TryFrom

70ad9d3

failing unit test

110f4db

lint

ff86adf

lint

fa253a3

KdfType enum duplicate

4a95dc5

revert identity crate wasm, since there it's not used right now

cd37e31

docs

3bf880f

formatting

93a3d0c

Merge branch 'main' into km/pm-24051-add-master-password-unlock-decry…

f0c4f2a

…ption-options-to-identity-sync-response

revert user decryption response parsing in wasm

3e6a46a

fixed unit test

7c34725

revert wasm dependencies

042678c

bring back wasm and uniffi bindings to MasterPasswordUnlockData, erro…

9676069

…r and docs improvements

identity separate user decryption options response model

7973f12

review suggestions

5a4f314

identity name prefix for UserDecryptionOptions

7e425ca

IdentityUserDecryptionOptionsResponseModel mapping to UserDecryptionData

c9aaa8c

clippy

2591773

Merge branch 'main' into km/pm-24051-add-master-password-unlock-decry…

3212002

…ption-options-to-identity-sync-response

mzieniukbw added 10 commits August 25, 2025 18:46

public crate user decryption options

ae10e35

Merge branch 'km/pm-24051-add-master-password-unlock-decryption-optio…

1f32993

…ns-to-identity-sync-response' into km/pm-24051-setting-master-password-unlock-into-state # Conflicts: # crates/bitwarden-vault/src/sync.rs

fix build

b5218cd

change from unused_imports to dead_code

6861006

Merge branch 'km/pm-24051-add-master-password-unlock-decryption-optio…

b22537f

…ns-to-identity-sync-response' into km/pm-24051-setting-master-password-unlock-into-state

use UserDecryptionData instead of MasterPasswordUnlockData

edd0cbf

require! stringify without reference

af667b0

update InternalClient using MasterPasswordUnlockData

7d538ca

rename to update_user_master_password_unlock

e5f16dc

user friendly require! error message

3cf5cc4

mzieniukbw marked this pull request as ready for review August 27, 2025 12:29

mzieniukbw requested review from a team as code owners August 27, 2025 12:29

mzieniukbw requested review from coroiu, Thomas-Avery and shane-melton and removed request for a team August 27, 2025 12:29

mzieniukbw added 5 commits August 29, 2025 14:55

increased test coverage

13ecd8e

fix clippy

1b8ccee

allow dead code on struct

6b98aaf

Merge branch 'main' into km/pm-24051-add-master-password-unlock-decry…

4a00571

…ption-options-to-identity-sync-response

Base automatically changed from km/pm-24051-add-master-password-unlock-decryption-options-to-identity-sync-response to main September 3, 2025 14:32

mzieniukbw requested a review from quexten September 3, 2025 14:44

Thomas-Avery reviewed Sep 3, 2025

View reviewed changes

quexten reviewed Sep 4, 2025

View reviewed changes

	LoginMethod::ServiceAccount(_) => return Err(NotAuthenticatedError)?,
	LoginMethod::ServiceAccount(_) => return Err(NotAuthenticatedError),

[PM-24051] Init crypto and update kdf with MasterPasswordUnlock #399

Are you sure you want to change the base?

[PM-24051] Init crypto and update kdf with MasterPasswordUnlock #399

Uh oh!

Conversation

mzieniukbw commented Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🎟️ Tracking

📔 Objective

⏰ Reminders before review

🦮 Reviewer guidelines

Uh oh!

sonarqubecloud bot commented Sep 3, 2025

Quality Gate passed

Uh oh!

Thomas-Avery left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

quexten left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mzieniukbw commented Aug 19, 2025 •

edited

Loading