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

[Android] Forcing user to re-authenticate if the system fingerprint settings are changed #881

New Issue
Closed
opened 2025-11-26 22:33:09 -06:00 by GiteaMirror · 7 comments
GiteaMirror commented 2025-11-26 22:33:09 -06:00
Owner
Copy Link

Originally created by @alxndrv on GitHub (Dec 5, 2019).

This is strictly related to Android. While playing around I noticed that removing a fingerprint from my device and adding a new one does not affect Bitwarden's fingerprint unlock at all.
Simple way to reproduce this would be:

  1. Enable fingerprint locking with Fingerprint A
  2. Remove Fingerprint A through Android's system settings
  3. Register Fingerprint B in Android's system settings
  4. Successfully unlock Bitwarden with Fingerprint B.

As a counter-example to this, a mobile banking application that I use (with fingerprint unlocking support) forced me to re-authenticate with a password after I followed the steps described above.

While this whole thing is technically only a risk when someone has physical access to the device, I can see a scenario where a user's carelessness can lead to issues.

Question is, should the user be forced to re-authenticate when device fingerprints are changed? It seems that this is technically possible. Any thoughts on this?

Originally created by @alxndrv on GitHub (Dec 5, 2019). This is strictly related to Android. While playing around I noticed that removing a fingerprint from my device and adding a new one does not affect Bitwarden's fingerprint unlock at all. Simple way to reproduce this would be: 1. Enable fingerprint locking with **_Fingerprint A_** 2. Remove **_Fingerprint A_** through Android's system settings 3. Register **_Fingerprint B_** in Android's system settings 4. Successfully unlock Bitwarden with **_Fingerprint B_**. As a counter-example to this, a mobile banking application that I use (with fingerprint unlocking support) forced me to re-authenticate with a password after I followed the steps described above. While this whole thing is technically only a risk when someone has physical access to the device, I can see a scenario where a user's carelessness can lead to issues. Question is, should the user be forced to re-authenticate when device fingerprints are changed? It seems that this is technically possible. Any thoughts on this?
GiteaMirror commented 2025-11-26 22:33:10 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Dec 6, 2019):

This is expected today. I could possibly change it to disable the fingerprint option Bitwarden if it detects the device's fingerprint settings have changed. The only issue there is I don't know how to detect that event. Do you?

@kspearrin commented on GitHub (Dec 6, 2019): This is expected today. I could possibly change it to disable the fingerprint option Bitwarden if it detects the device's fingerprint settings have changed. The only issue there is I don't know how to detect that event. Do you?
GiteaMirror commented 2025-11-26 22:33:10 -06:00
Author
Owner
Copy Link

@alxndrv commented on GitHub (Dec 6, 2019):

Some quick googling suggests that Android's KeyStore API can be set up to invalidate fingerprint-associated keys when new fingerprints are added to the device. Alternatively, the FingerprintManager API may be used somehow.

I'm not exactly sure how fingerprint locking is implemented in Bitwarden so I'll try and set up a dev environment and play around with the code a bit. I'll let you know if I find a solution.

@alxndrv commented on GitHub (Dec 6, 2019): Some quick googling suggests that Android's KeyStore API can be set up to invalidate fingerprint-associated keys when new fingerprints are added to the device. Alternatively, the FingerprintManager API may be used somehow. I'm not exactly sure how fingerprint locking is implemented in Bitwarden so I'll try and set up a dev environment and play around with the code a bit. I'll let you know if I find a solution.
GiteaMirror commented 2025-11-26 22:33:10 -06:00
Author
Owner
Copy Link

@alxndrv commented on GitHub (Dec 6, 2019):

Okay so I looked into this and here's what I found. As of right now the application makes no specific distinction between a fingerprint lock and other locking options (let's say PIN).

When unlocking the vault, the application simply asks the OS to authenticate the user using the native biometrics prompt. Upon successful authentication, Bitwarden simply flags the fingerprint lock as "unlocked" and proceeds to retrieve the vault key (master password or encryption key, I'm not sure which one) from secure storage.

I looked into the source code of Xamarin's secure storage and it seems they are using Android's KeyStore API to generate keys which are then used to encrypt the stored values. The encrypted values are then stored using SharedPreferences.

Note that the KeyStore API has a way to generate keys which require user authentication in order to be used and make those keys become invalid when fingerprints are added/removed. Xamarin's Secure Storage however, does not use this option, meaning that those keys are always retrievable (within the context of the app) despite changes to device's security settings.

A proposed solution to this would be to re-write the biometric authentication implementation for Android. This would mean generating a new key using the KeyStore API whenever a user enables fingerprint locking and using that key to encrypt the vault key (and manually storing the encrypted vault key somewhere). This way, if we try to use the key after adding/removing fingerprints, the KeyStore will throw a KeyPermanentlyInvalidException which we can handle by requesting the user to re-enter their master password and forcing them to manually re-enable fingerprint locking via Settings.

Any thoughts on this? The proposed solution would require a lot of work.
Feel free to correct me if I've made any mistakes with the way fingerprints are currently handled.

@alxndrv commented on GitHub (Dec 6, 2019): Okay so I looked into this and here's what I found. As of right now the application makes no specific distinction between a fingerprint lock and other locking options (let's say PIN). When unlocking the vault, the application simply asks the OS to authenticate the user using the native biometrics prompt. Upon successful authentication, Bitwarden simply flags the fingerprint lock as "unlocked" and proceeds to retrieve the vault key _(master password or encryption key, I'm not sure which one_) from [secure storage](https://docs.microsoft.com/en-us/xamarin/essentials/secure-storage?tabs=android). I looked into the source code of Xamarin's secure storage and it seems they are using Android's KeyStore API to generate keys which are then used to encrypt the stored values. The encrypted values are then stored using SharedPreferences. Note that the KeyStore API has a way to [generate keys which require user authentication](https://developer.android.com/training/articles/keystore.html#UserAuthentication) in order to be used and make those keys become invalid when fingerprints are added/removed. Xamarin's Secure Storage however, does not use this option, meaning that those keys are always retrievable _(within the context of the app)_ despite changes to device's security settings. A proposed solution to this would be to re-write the biometric authentication implementation for Android. This would mean generating a new key using the KeyStore API whenever a user enables fingerprint locking and using that key to encrypt the vault key (and manually storing the encrypted vault key somewhere). This way, if we try to use the key after adding/removing fingerprints, the KeyStore will throw a [KeyPermanentlyInvalidException](https://developer.android.com/reference/android/security/keystore/KeyPermanentlyInvalidatedException.html) which we can handle by requesting the user to re-enter their master password and forcing them to manually re-enable fingerprint locking via Settings. Any thoughts on this? The proposed solution would require a lot of work. Feel free to correct me if I've made any mistakes with the way fingerprints are currently handled.
GiteaMirror commented 2025-11-26 22:33:10 -06:00
Author
Owner
Copy Link

@smanelli commented on GitHub (Jan 30, 2020):

Hi,
I'm no expert, but reading this Stackoverflow article , it seems simple enough. From the article:
So to check if any new fingerprints have been enrolled since you created your fingerprint-associated key, just create a cipher with that key and try to init the cipher. If any new fingerprints have been enrolled, the init call should trigger a KeyPermanentlyInvalidatedException
Could this work?

@smanelli commented on GitHub (Jan 30, 2020): Hi, I'm no expert, but reading[ this Stackoverflow article](https://stackoverflow.com/questions/44515668/android-fingerprint-detect-new-finger-added) , it seems simple enough. From the article: _So to check if any new fingerprints have been enrolled since you created your fingerprint-associated key, just create a cipher with that key and try to init the cipher. If any new fingerprints have been enrolled, the init call should trigger a KeyPermanentlyInvalidatedException_ Could this work?
GiteaMirror commented 2025-11-26 22:33:10 -06:00
Author
Owner
Copy Link

@alxndrv commented on GitHub (Jan 31, 2020):

@smanelli That solution seems roughly the same as the one I described earlier, and it makes sense to use Android's built-in API to invalidate keys when biometric options change.

If I recall correctly, right now the vault key is stored using Xamarin's "secure storage". The problem is that Xamarin is also the module which is responsible for getting the keys which are used to encrypt items in secure storage. While its handy and all, this means that we can't directly use Android's key invalidation API.

@alxndrv commented on GitHub (Jan 31, 2020): @smanelli That solution seems roughly the same as the one I described earlier, and it makes sense to use Android's built-in API to invalidate keys when biometric options change. If I recall correctly, right now the vault key is stored using Xamarin's "secure storage". The problem is that Xamarin is also the module which is responsible for getting the keys which are used to encrypt items in secure storage. While its handy and all, this means that we can't directly use Android's key invalidation [API](setInvalidatedByBiometricEnrollment(boolean)).
GiteaMirror commented 2025-11-26 22:33:10 -06:00
Author
Owner
Copy Link

@cleveHEX commented on GitHub (Jan 25, 2024):

Hello there, was there any progress since?

@cleveHEX commented on GitHub (Jan 25, 2024): Hello there, was there any progress since?
GiteaMirror commented 2025-11-26 22:33:11 -06:00
Author
Owner
Copy Link

@vvolkgang commented on GitHub (Jun 20, 2024):

Issue migrated to https://github.com/bitwarden/mobile/issues/666

@vvolkgang commented on GitHub (Jun 20, 2024): Issue migrated to https://github.com/bitwarden/mobile/issues/666
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
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#881
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?