Yes, the encrypted copy of this is held in Windows Credential manager: clients/apps/desktop/desktop_native/core/src/biometric/windows.rs at 789d66ce880933c1699545c3b1000e549359ca6a · bitwarden/clients · GitHub
1 Like
Biometrically locked? I bought biometrics was used to unlock a locked vault. Are you saying that there is more than one way to lock the vault?
Although I would hate to crash your party, paying very careful attention to the words exchanged in the messages above, you’ll see that the only thing that has changed is that Bitwarden may be willing to bring back “not requiring a password on restart.” However, with the 2025.8.0 implementation, Bitwarden removed it for a reason:
This means that while not requiring a password on restart using biometric unlock, if malware can come in, grab your encrypted vault, and obtain the keys stored in the credential manager, regardless of whether Bitwarden is running, locked, or unlocked, your lifted vault can be decrypted.
The exchanges between grb and quexten (after micah’s) above discussed the current 2025.8.0 implementation which requires password on restart, i.e., no long-term decryption keys stored in the credential manager. Even with this configuration, grb had mentioned earlier that he wasn’t willing to personally use it.
I would personally be arguing against people using biometrics unlock, not requiring password on restart, with this implementation. You have to do what you have to do, but please remember that it might not be as safe as you think it should be.
I read this as referring to two key-halves (one half stored in process memory, and one half held in the Windows Credential Manager), both of which would be combined to decrypt the protected vault key (“the key needed to decrypt the vault”). Hence my question about the location of the protected key.
Assuming that by “this”, @Quexten is now referring to the protected vault key (I believe the more precise technical term is the protected user key), then I understand the scheme as follows:
- The Windows Credential Manager holds the protected user key.
- The Windows Credential Manager also holds a key-half required to decrypt the protected user key (but this decryption also requires the second key-half)
- On first app-unlock, the Desktop app process memory holds the second key-half, which has been derived from the user-entered master password or unlock PIN.
I meant “locked with biometric unlock enabled”. The different approaches to locking/unlocking have in common that all decrypted vault contents are purged from memory when the vault is locked, but they differ in what information remains in memory (or in persistent storage in the credential manager and/or hard drive of the device) to allow the user to subsequently unlock the vault.
1 Like
It’s a shame what’s happening with BW. I really like this app, but like many here, biometric unlocking helps with workflow, and I don’t think PIN unlocking is the most secure option. I’m currently testing Proton Pass, and if this situation changes at some point, I’ll return to BW.
Honestly, this is a rubbish response from BW. I absolutely HATE having to type my long and complex password, which is the entire reason I spent money on a fingerprint reader.
I don’t want to have to type my password in front of my clients who usually sit next to me. Now I am forced to do this!
This should absolutely be the user’s choice, not something that is decided by BitWarden.
1 Like
You can set a PIN (temporary if you wish) as an alternative to entering your master password in front of your clients.
(This response is just an attempt to provide a work-around for mitigating the specific concern that you raised above; it is not intended to discount anything else expressed in this thread. Also, in case it needs saying, I do not work for or speak for Bitwarden.)
Hi @daxliniere just to clarify, this is just on app restart, not every unlock.
So while the team explores solutions that are both reliable and secure, unlock with pin or using master password on app restart (and then using biometrics after that) is an option in the meantime.
We understand your frustration and rest assured, your feedback has been passed along to the team.
The only thing taken away was the initial biometric unlock after application start. Biometrics continue to work at the other times, although I have occasionally found biometrics to break during upgrades, which can be fixed by setting up biometrics afresh.
I too mourn my favorite choice being taken away, but do keep in mind that there are a variety of options:
-
Use an unlock pin which is local to your device and therefore useless to your clients unless they also steal your laptop.
-
Set a long lock-timeout (e.g. 8 hours) so you remain unlocked in while in the presence of clients.
-
Change your timeout to “Logout” and use “login with device”.
-
Login to the app and then lock it before visiting the client. As long as the app stays running, biometrics work for the second and later unlocks.
-
Revert back to an older version of the client (complete with old behaviors and old vulnerabilities).
I think it important to realize that Bitwarden is the one with the corporate reputation to protect and therefore gets to set the minimum-security-level for their product. They have already explained why they felt this necessary and how they hope to " restore the previously supported behavior without downgrading the security of our implementation".
(Like @grb, I do not work for or speak for Bitwarden.)
I have found that if Firefox is open and the Bitwarden extension is locked before I log out of the desktop application and log back in (with device), the “Unlock with Biometrics” option is not available for the extension. That is, ensure that Firefox is closed, then log out and back in to the desktop, then open Firefox and unlock the extension with biometrics.
The behavior seems to make sense, as the secret (necessary to decrypt your vault) that was derived from the master password or PIN entry on restart is stored in the process memory of the Bitwarden Desktop app. Thus, if you log out from the desktop app, its process memory is wiped, and one of the secrets required for unlocking with biometrics is lost.
This will make the security WORSE, as the people who didn’t realize the hello window needed to be selected are likely also part of the demographic that would disable their security even further to reduce the inconvenience. I, for one, will be downgrading to a version with this critical feature I spent MONEY for (a fingerprint scanner). I know plenty of people that will simply just always keep it unlocked. Even a flawed experience would be better than removing it from a psychological perspective.
2 Likes
Thank you @grb , @dwbit and @DenBesten for your responses.
I want to mention that it’s not just once you must type your master password when using the browser extension (the only place I use it), but twice. Once to verify the desktop app, then once again to verify the browser extension and THEN you need to use fingerprint.
Also, where is the option to change Vault item clicks from View to Fill? (It should always be fill. If you want to view it, you would click the 3-dot menu button.)
Settings > Appearance > Click items in autofill suggestion to fill
1 Like
Excuse me for my probably silly question, but does that mean, that default chromium-based password vault is under the same risk since even latest version of MS Edge / Chrome are allowing you to see password unlocking with windows hello with no any “master password” at all: not at the first time after boot, nor for all of the next times. Am I correct in my understanding that MS / Google engineers missed that vulnerability but Bitwarden’s team not? 
Thank you @grb!
I’m not sure how this is an Appearance setting (should be in Vault settings), but I found it. 
1 Like
hey @daxliniere are you referring to initially setting up the integration for the first time? You shouldn’t need to be doing that each time (only master password or unlock with pin for desktop app on app restart), and then use browser extension biometrics as expected.
If you’re experiencing something else, let me know.
For context, what is discussed below is only relevant to Bitwarden insofar as it corresponds to how pre-2025.8.0 versions of the browser extension behaved when you disabled the requirement to unlock with master password on app restart. This comment is in response to the above question by @vova, who wants to know whether the vulnerabilities in the pre-2025.8.0 version of the Bitwarden browser extension still exist in the native password managers provided by browsers like Edge and Chrome.
I’m no expert in the inner workings of Chromium browsers, but I would think that this would indeed create a security vulnerability the native password managers. Windows Hello does not provide any functionality supporting encryption, so at best, an encryption key can be derived based on a “digital signature” that is produced by Windows Hello on successful biometric authentication. My understanding is that a malicious app can obtain the same digital signature (and hence derive the encryption/decryption key required to decrypt your passwords) by tricking you into completing a Windows Hello authentication.
I have to confess that I don’t fully understand how this would be done, since the Windows Hello creates the “digital signature” by using a private key to encrypt a “challenge” (a string created by the password manager app or browser for this purpose), and the app then uses the user’s public key to decrypt the signed challenge, thereby confirming that it was the user whit the matching private key who produced the signature. The remaining question for me is how does the attacker obtain a copy of the “challenge” string from the password manager or browser? Perhaps this is relatively simple for malware to do using available APIs, but I am not familiar with the details.
Chrome has their own application-bound-encryption which involves a service running as admin holding secrets, and only handing them out to “genuine” chrome applications. However, this has been bypassed multiple times already. GitHub - xaitax/Chrome-App-Bound-Encryption-Decryption: Fully decrypt App-Bound Encrypted (ABE) cookies, passwords & payment methods from Chromium-based browsers (Chrome, Brave, Edge) - all in user mode, no admin rights required.. There is GitHub projects that make this fairly easy for you tidy-browser/crates/decrypt-cookies at master · saying121/tidy-browser · GitHub.
2 Likes