github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-09 03:33:36 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

[PR #3044] [PM-6466] Implement passkeys User Verification #3986

New Issue
Closed
opened 2025-11-26 23:39:16 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-26 23:39:16 -06:00
Owner
Copy Link

Original Pull Request: https://github.com/bitwarden/android/pull/3044

State: closed
Merged: Yes

Type of change

  • Bug fix
  • New feature development
  • Tech debt (refactoring, code cleanup, dependency upgrades, etc)
  • Build/deploy pipeline (DevOps)
  • Other

Objective

Implement User Verification on Passkeys.

Note: For the moment, user verification preference preferred is being taken as required

Diagram of the different flows for User Verification:

graph TB
    A[Start] ==> TDEIF{Is TDE?}
    TDEIF --> |No| MPRIF{Has MP Reprompt?};
    TDEIF --> |Yes| UVPRIF{Is UV preference Required?}

    MPRIF -->|Yes| MPR{Show MP Reprompt};
    MPR -->|Valid| UVV[UV Verified];
    MPR -->|Invalid| UVNV[UV not verified];
    MPRIF --> |No| UVPRIF;
    
    UVPRIF -->|Yes| UDSRIF{Has Unlocked in Session?};
    UVPRIF -->|No| UVPPIF{Is UV preference Preferred?};

    UDSRIF -->|Yes| UVV2[UV Verified];
    UDSRIF -->|No| OSLIF{Can verify with OS unlock?}

    OSLIF -->|Yes| OSLVIF{Verify with OS unlock}
    OSLIF -->|No| BWPIF{Is BW Pin setup?}

    OSLVIF -->|Valid| UVV3[UV Verified];
    OSLVIF -->|Invalid| UVNV3[UV not Verified];

    BWPIF -->|Yes| BWPVIF{Verify BW PIN}
    BWPIF -->|No| MPIF{Has Master Password?}
    
    BWPVIF-->|Valid| UVV4[UV Verified]
    BWPVIF-->|Invalid| UVNV4[UV not Verified]

    MPIF -->|Yes| MPVIF{Verify Master Password}
    MPIF -->|No| SBWPS[Alert: Setup PIN in Bitwarden]

    MPVIF-->|Valid| UVV5[UV Verified]
    MPVIF-->|Invalid| UVNV5[UV not Verified]

    UVPPIF -->|Yes| UDSPIF{Has Unlocked in Session?};
    UVPPIF -->|No| UVNV2[UV not verified];

    UDSPIF -->|Yes| UVV6[UV Verified];
    UDSPIF -->|No| OSPLIF{Can verify with OS unlock?};

    OSPLIF -->|Yes| OSLV2{Verify with OS unlock};
    OSPLIF -->|No| UVNV8[UV not Verified];

    OSLV2 -->|Valid| UVV7[UV Verified];
    OSLV2 -->|Invalid| UVNV7[UV not Verified];

OS Unlock inner diagram:

graph TB
    A[From previous diagram step] --> OSL[Verify with OS unlock];

    OSL --> OSBLIF{Is OS Biometrics unlock available?};

    OSBLIF -->|Yes| OSBLVIF{Verify OS Biometrics unlock};
    OSBLIF -->|No| OSNBLIF{Is OS non-Biometrics unlock available?};

    OSBLVIF -->|Valid| UVV[UV verified]
    OSBLVIF -->|Invalid| UVNV[UV not verified]

    OSNBLIF -->|Yes| OSNBLVIF{Verify OS non-Biometrics unlock};
    OSNBLIF -->|No| C[Can't verify with OS unlock]

    OSNBLVIF -->|Valid| UVV2[UV verified]
    OSNBLVIF -->|Invalid| UVNV2[UV not verified]

Code changes

  • UserVerificationMediatorService: Core mediator class to handle all different kind of user verification. This interacts with strategies implemented for each type of verification flow.
  • CredentialProviderViewController.Passkeys / CredentialProviderViewController.Passkeys: Added passkey user verification and improved error handling.
  • UserPinService: Added methods to verify pin and check if pin is enabled.
  • Fido2GetAssertionUserInterface: Added cipherId to be passed in the user verification to check for master password reprompt.
  • Fido2MakeCredentialUserInterface: Added cipherId to be passed in the user verification to check for master password reprompt. Also, added a particular case where the user verification may have already been done, like when creating a new login with passkey (the UV is done before saving the new login).
  • Fido2AuthenticatorService: Added logic to check when to enforce required user verification, specifically in preferred it should happen when we have the ability to perform user verification.
  • SymmetricCryptoKey: Changed exceptions to more specific ones so we can catch them and do specific logic with that like when the Pin entered is wrong.

Before you submit

  • Please check for formatting errors (dotnet format --verify-no-changes) (required)
  • Please add unit tests where it makes sense to do so (encouraged but not required)
  • If this change requires a documentation update - notify the documentation team
  • If this change has particular deployment requirements - notify the DevOps team
**Original Pull Request:** https://github.com/bitwarden/android/pull/3044 **State:** closed **Merged:** Yes --- ## Type of change - [ ] Bug fix - [X] New feature development - [ ] Tech debt (refactoring, code cleanup, dependency upgrades, etc) - [ ] Build/deploy pipeline (DevOps) - [ ] Other ## Objective <!--Describe what the purpose of this PR is. For example: what bug you're fixing or what new feature you're adding--> Implement User Verification on Passkeys. _Note: For the moment, user verification preference `preferred` is being taken as `required`_ Diagram of the different flows for User Verification: ```mermaid graph TB A[Start] ==> TDEIF{Is TDE?} TDEIF --> |No| MPRIF{Has MP Reprompt?}; TDEIF --> |Yes| UVPRIF{Is UV preference Required?} MPRIF -->|Yes| MPR{Show MP Reprompt}; MPR -->|Valid| UVV[UV Verified]; MPR -->|Invalid| UVNV[UV not verified]; MPRIF --> |No| UVPRIF; UVPRIF -->|Yes| UDSRIF{Has Unlocked in Session?}; UVPRIF -->|No| UVPPIF{Is UV preference Preferred?}; UDSRIF -->|Yes| UVV2[UV Verified]; UDSRIF -->|No| OSLIF{Can verify with OS unlock?} OSLIF -->|Yes| OSLVIF{Verify with OS unlock} OSLIF -->|No| BWPIF{Is BW Pin setup?} OSLVIF -->|Valid| UVV3[UV Verified]; OSLVIF -->|Invalid| UVNV3[UV not Verified]; BWPIF -->|Yes| BWPVIF{Verify BW PIN} BWPIF -->|No| MPIF{Has Master Password?} BWPVIF-->|Valid| UVV4[UV Verified] BWPVIF-->|Invalid| UVNV4[UV not Verified] MPIF -->|Yes| MPVIF{Verify Master Password} MPIF -->|No| SBWPS[Alert: Setup PIN in Bitwarden] MPVIF-->|Valid| UVV5[UV Verified] MPVIF-->|Invalid| UVNV5[UV not Verified] UVPPIF -->|Yes| UDSPIF{Has Unlocked in Session?}; UVPPIF -->|No| UVNV2[UV not verified]; UDSPIF -->|Yes| UVV6[UV Verified]; UDSPIF -->|No| OSPLIF{Can verify with OS unlock?}; OSPLIF -->|Yes| OSLV2{Verify with OS unlock}; OSPLIF -->|No| UVNV8[UV not Verified]; OSLV2 -->|Valid| UVV7[UV Verified]; OSLV2 -->|Invalid| UVNV7[UV not Verified]; ``` OS Unlock inner diagram: ```mermaid graph TB A[From previous diagram step] --> OSL[Verify with OS unlock]; OSL --> OSBLIF{Is OS Biometrics unlock available?}; OSBLIF -->|Yes| OSBLVIF{Verify OS Biometrics unlock}; OSBLIF -->|No| OSNBLIF{Is OS non-Biometrics unlock available?}; OSBLVIF -->|Valid| UVV[UV verified] OSBLVIF -->|Invalid| UVNV[UV not verified] OSNBLIF -->|Yes| OSNBLVIF{Verify OS non-Biometrics unlock}; OSNBLIF -->|No| C[Can't verify with OS unlock] OSNBLVIF -->|Valid| UVV2[UV verified] OSNBLVIF -->|Invalid| UVNV2[UV not verified] ``` ## Code changes <!--Explain the changes you've made to each file or major component. This should help the reviewer understand your changes--> <!--Also refer to any related changes or PRs in other repositories--> * **UserVerificationMediatorService:** Core mediator class to handle all different kind of user verification. This interacts with strategies implemented for each type of verification flow. * **CredentialProviderViewController.Passkeys / CredentialProviderViewController.Passkeys:** Added passkey user verification and improved error handling. * **UserPinService:** Added methods to verify pin and check if pin is enabled. * **Fido2GetAssertionUserInterface:** Added cipherId to be passed in the user verification to check for master password reprompt. * **Fido2MakeCredentialUserInterface:** Added cipherId to be passed in the user verification to check for master password reprompt. Also, added a particular case where the user verification may have already been done, like when creating a new login with passkey (the UV is done before saving the new login). * **Fido2AuthenticatorService:** Added logic to check when to enforce required user verification, specifically in `preferred` it should happen when we have the ability to perform user verification. * **SymmetricCryptoKey:** Changed exceptions to more specific ones so we can catch them and do specific logic with that like when the Pin entered is wrong. ## Before you submit - Please check for formatting errors (`dotnet format --verify-no-changes`) (required) - Please add **unit tests** where it makes sense to do so (encouraged but not required) - If this change requires a **documentation update** - notify the documentation team - If this change has particular **deployment requirements** - notify the DevOps team
GiteaMirror added the pull-request label 2025-11-26 23:39:16 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#3986
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?