Skip to content

[PM-33111] Implement device auth key#816

Draft
iinuwa wants to merge 8 commits intomainfrom
PM-33111/sdk-device-auth-key
Draft

[PM-33111] Implement device auth key#816
iinuwa wants to merge 8 commits intomainfrom
PM-33111/sdk-device-auth-key

Conversation

@iinuwa
Copy link
Copy Markdown
Contributor

@iinuwa iinuwa commented Mar 5, 2026

🎟️ Tracking

PM-33111

📔 Objective

This adds methods to create and use a Bitwarden "device auth key", which is a passkey with PRF that can login and unlock the vault. The handles:

  • generation of the passkey and PRF seed
  • derivation of the rotateable key set wrapping the UserKey
  • registration of the passkey and key set with the server
  • unregistration of the passkey

Clients are responsible for implementing a trait to store and retrieve the passkey in secure device storage.

Depends on:

🚨 Breaking Changes

No breaking changes.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Mar 5, 2026

Logo
Checkmarx One – Scan Summary & Details51428060-ffd2-4132-a15a-8a650259d232

Great job! No new security vulnerabilities introduced in this pull request

@iinuwa iinuwa force-pushed the PM-33111/sdk-device-auth-key branch from da66377 to c404e6d Compare March 6, 2026 16:19
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Mar 6, 2026

🔍 SDK Breaking Change Detection Results

SDK Version: PM-33111/sdk-device-auth-key (86eb07f)
Completed: 2026-03-12 16:41:25 UTC
Total Time: 246s

Client Status Details
typescript ❌ Breaking changes detected TypeScript compilation failed with new SDK version - View Details

Breaking change detection completed. View SDK workflow

@codecov
Copy link
Copy Markdown

codecov bot commented Mar 6, 2026

Codecov Report

❌ Patch coverage is 0% with 611 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.21%. Comparing base (3385058) to head (86eb07f).

Files with missing lines Patch % Lines
crates/bitwarden-fido/src/device_auth_key.rs 0.00% 408 Missing ⚠️
crates/bitwarden-fido/src/types.rs 0.00% 129 Missing ⚠️
crates/bitwarden-uniffi/src/platform/fido2.rs 0.00% 65 Missing ⚠️
crates/bitwarden-fido/src/client_fido.rs 0.00% 9 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #816      +/-   ##
==========================================
- Coverage   82.40%   81.21%   -1.19%     
==========================================
  Files         350      351       +1     
  Lines       41751    42362     +611     
==========================================
  Hits        34404    34404              
- Misses       7347     7958     +611     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@iinuwa iinuwa force-pushed the PM-33111/sdk-device-auth-key branch from 04e5d6c to 86eb07f Compare March 12, 2026 16:29
@sonarqubecloud
Copy link
Copy Markdown

Comment on lines +54 to +59
// TODO: These parameters are limiting:
// - Is there some way to accept the master password hash directly instead of having to do
// it in here?
// - Do we need to support all the options (master password hash, OTP, secret, auth access
// token)? Or just master password hash and OTP?
// We do this in get_user_api_key, consider centralizing this logic
Copy link
Copy Markdown
Contributor Author

@iinuwa iinuwa Mar 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As listed in the TODO comment, I'm not sure where to go with this:

  • What's the expected pattern for deriving a SecretVerificationRequest from a master password? Should the app do it, and then send it to the SDK, or does the SDK do it by referencing the internal KdfClient? The KdfClient seems to be marked as a "stop-gap," but is used in other places in the SDK. Not sure which way to go.
  • Should I turn SecretVerificationRequest into an enum? E.g.,
struct MasterPasswordSecretVerificationRequest  {
    /// User's email
    email: String,
    /// User's master password to be hashed.
    password: String
    /// KDF parameters for the user's account.
    kdf: Kdf,
}

impl MasterPasswordSecretVerificationRequest {
    async fn hash_password(&self, kdf_client: KdfClient) -> Result<String, _> {
        kdf_client.hash_password(
            self.email.clone(),
            self.password.clone(),
            self.kdf,
            HashPurpose::ServerAuthorization
        ).await
    }
}

enum SecretVerificationRequest {
    MasterPassword(MasterPasswordSecretVerificationRequest),
    Otp(String),
    AuthAccessToken, // I don't really know what these two are,
    Secret,          // but I see their definitions in the server
}

None
};

// TODO: Make this an enum?
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See note above on this TODO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant