grb
September 19, 2025, 4:21pm
166
No, unfortunately, you are not making sense to me. Experience or not, it seems that you have significantly misunderstood the current limitations on biometric unlock, and the available work-arounds.
pmarnason
September 19, 2025, 6:06pm
168
I guess I must have misunderstood something here. My understanding was that the Windows Hello unlock implementation was secure but had issues gaining application focus, and so the feature was removed to offer a better user experience to those affected by the poor user experience.
grb
September 19, 2025, 6:12pm
169
pmarnason:
the feature was removed
The feature has not been removed. The main change is that if you close the Desktop app and subsequently restart it, then the first unlock after app restart must use a password (master password or alternative password configured under the “PIN” option). For all subsequent unlocks, you can use biometrics without entering any password.
grb:
In addition, you misunderstood @Nail1684 ’s recommended work-around, which was to set an unlock PIN for unlocking Bitwarden on app restart. The PIN is in effect an alternative password (on non-mobile apps, it can contain non-numeric characters), which would be shorter than the master password — and hence, even easier to type. If you use this work-around, you are not required to type your master password on app restart (only the PIN).
Hmmmm… yeah, I must admit, I tried to imply that. – But I think, we overlooked a change here too. I just realized, on my desktop app 2025.9.0 (maybe even since 2025.8.0?), there no longer is the option to “circumvent” using the master password with PIN unlock on first unlock after app start as well:
So in fact, you are required to type in the master password on app (re)start at the moment. (at least for the desktop app)
False alarm! It’s still there, but just hidden, as @grb pointed out in the “next” post here . (and I don’t delete my post as my mistake may help others now
PS: I didn’t want to restart the whole discussion now… please all bear in mind, that there are concrete efforts to reintroduce biometric unlock on app start:
main ← km/poc-windows-hello-2
opened 06:44PM - 27 Aug 25 UTC
## 🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-25373
## 📔 Object… ive
> [!NOTE]
> QA testing is still pending for whether the focus issues from https://github.com/bitwarden/clients/issues/13291 are still fixed with this PR.
> [!NOTE]
> Pending verification, the windows-hello key derived from signature will be replaced by PRF passkey gated by Windows Hello, once that becomes available.
This PR started as a research spike for the following goals:
1. Establish a good abstraction for biometrics, pushing all details to rust. The typescript code is minimal / just pass-through. This is intended to also be the abstraction for the mac-rewrite to SecItem
2. Evaluate bringing back unlock on app start on windows
- This needs more layers of unstable workarounds / hacks to fix the broken focus behavior of the Windows-Hello signing API
4. Evaluate anti-memory dumping techniques, to protect ephemeral biometric secrets in locked vaults
In the process, this completely re-writes the windows hello implementation from the ground up. And mostly re-write the linux implementation. Both are significantly simpler to understand, while at the same time being more robust, and more secure. All complex concepts like "clientKeyHalf", "osKeyHalf" are dropped in favor of better abstractions.
Both Windows and Linux are re-written at the same time here in order not to have to keep around multiple abstractions as an intermediary step.
### Windows Implementation
The windows implementation now has two paths. One for after first unlock, and one for on first unlock after app restart.
#### UV unlock (AFU)
The windows implementation now stores the keys protected using DPAPI memory encryption in memory after first unlock. This prevents access by memory dumping, closing existing attack vectors. It is possible this can still be cricumvented by injecting DLLs into the process. This will path will be closed down here: https://github.com/bitwarden/clients/pull/16156
#### Signing unlock (BFU)
Here the signing API is used as was the case before https://github.com/bitwarden/clients/pull/14953. A challenge (per-user) is signed. This signature is then hashed to derive a key. This key is used to decrypt the userkey. The userkey ciphertext + challenge + nonce are stored on the keychain, that is user-wide accessible.
#### Focus issues
https://github.com/bitwarden/clients/pull/14953 had to remove the signing API due to issues focusing. This PR adds additional unstable workarounds - such as attaching to the currently foregrounded window's thread - to force focus the windows-hello prompt. Once Microsoft releases the new API, this code will be replaced by the stable API that does not have focus issues.
Further, an additional feature is added - when the authentication starts, the currently foregrounded window is saved. After the authentication is done, that window is foregrounded + focused again. This makes it so that an extension / browser is properly re-focused.
### Linux Implementation
Pretty much the same as before, but instead of using libsecret + a client-side unprotected secret, which can be easily circumvented using memory dumping (on snap), memfd_secret is used alone. The userkey is directly stored to a hashmap that is protected with memfd_secret.
### Memory Protection
This add support for [DPAPI's](https://learn.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectmemory) memory encyrption, and [Linux's memfd_secret](https://man7.org/linux/man-pages/man2/memfd_secret.2.html). These are currently only used to hold the ephemeral keys for unlocking with biometrics, but will be used in more areas like SSH-agent in the future.
### Security
The security goal here is to prevent user-space apps from bypassing lock, which is not currently consistently possible with the current implementation. The attacker model here is user-space processes. A kernel or administrator account compromise is not specifically defended against / best-effort.
Both implementations, AFU, are protected with memory protections. As mentioned, debuggers/dll injection are still a problem on Windows, which will be dealt with in a [separate PR. ](https://github.com/bitwarden/clients/pull/16156) User-space applications can thus no longer access the keys required here, and thus to circumvent the unlock, Windows Hello / Polkit would need to be attacked directly.
For Windows-Hello BFU (on app start), a per-user challenge is signed with the Bitwarden-desktop signing key. The deterministic signature is hashed to obtain the Windows-Hello key. (Challenge, windows-hello-key-wrapped-userkey, encryption nonce) `WindowsHelloKeychainEntry` , are stored on the Windows keychain.
The security model here relies on the assumption that a user does not accept an unexpected Windows Hello prompt. To break the security, an attacker has to obtain the `WindowsHelloKeychainEntry` from the keychain (accessible to any userspace process). Subsequently, they have to phish a Windows-Hello prompt with the Signing API for the challenge. That is, a successful Windows-Hello authentication is required.
### Testing & Docs
This significantly increases the documentation for how the implementations work. Both Linux and Windows should be comprehensible with minimal background knowledge now. Manual tests are provided for polkit / windows hello, so these can be easily tested. Automatic integration-tests for rust are sadly not possible still, since it is unclear how the Windows-hello prompt would be emulated.
## 📸 Screenshots
https://github.com/user-attachments/assets/618072ea-7e8e-4e94-8968-14adfcee22ec
## (Unsigned commits)
> [!NOTE]
> If you're wondering about the unverified commits, I don't have signing set up on Windows. LMK if you require me to re-push a signed history.
## ⏰ 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
main ← km/pm-25373/windows-bio-v2
opened 07:12PM - 15 Sep 25 UTC
## 🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-25373
## 📔 Obje… ctive
Extracting out the Windows rewrite from https://github.com/bitwarden/clients/pull/16187 and putting it behind its own feature flag. The following are the windows specific notes from that original PR.
This completely re-writes the windows hello implementation from the ground up. This is significantly simpler to understand, while at the same time being more robust, and more secure. All complex concepts like "clientKeyHalf", "osKeyHalf" are dropped in favor of better abstractions.
### Windows Implementation
The windows implementation now has two paths. One for after first unlock, and one for on first unlock after app restart.
#### UV unlock (AFU)
The windows implementation now stores the keys protected using DPAPI memory encryption in memory after first unlock. This prevents access by memory dumping, closing existing attack vectors. It is possible this can still be circumvented by injecting DLLs into the process. This will path will be closed down here: https://github.com/bitwarden/clients/pull/16156
#### Signing unlock (BFU)
Here the signing API is used as was the case before https://github.com/bitwarden/clients/pull/14953. A challenge (per-user) is signed. This signature is then hashed to derive a key. This key is used to decrypt the userkey. The userkey ciphertext + challenge + nonce are stored on the keychain, that is user-wide accessible.
#### Focus issues
https://github.com/bitwarden/clients/pull/14953 had to remove the signing API due to issues focusing. This PR adds additional unstable workarounds - such as attaching to the currently foregrounded window's thread - to force focus the windows-hello prompt. Once Microsoft releases the new API, this code will be replaced by the stable API that does not have focus issues.
Further, an additional feature is added - when the authentication starts, the currently foregrounded window is saved. After the authentication is done, that window is foregrounded + focused again. This makes it so that an extension / browser is properly re-focused.
### Memory Protection
This adds support for [DPAPI's](https://learn.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectmemory) memory encryption. This currently only used to hold the ephemeral keys for unlocking with biometrics.
### Security
The security goal here is to prevent user-space apps from bypassing lock, which is not currently consistently possible with the current implementation. The attacker model here is user-space processes. A kernel or administrator account compromise is not specifically defended against / best-effort.
AFU is protected with memory protections. As mentioned, debuggers/dll injection are still a problem on Windows, which will be dealt with in a [separate PR. ](https://github.com/bitwarden/clients/pull/16156) User-space applications can thus no longer access the keys required here, and thus to circumvent the unlock, Windows Hello would need to be attacked directly.
For Windows-Hello BFU (on app start), a per-user challenge is signed with the Bitwarden-desktop signing key. The deterministic signature is hashed to obtain the Windows-Hello key. (Challenge, windows-hello-key-wrapped-userkey, encryption nonce) `WindowsHelloKeychainEntry` , are stored on the Windows keychain.
The security model here relies on the assumption that a user does not accept an unexpected Windows Hello prompt. To break the security, an attacker has to obtain the `WindowsHelloKeychainEntry` from the keychain (accessible to any userspace process). Subsequently, they have to phish a Windows-Hello prompt with the Signing API for the challenge. That is, a successful Windows-Hello authentication is required.
### Testing & Docs
This significantly increases the documentation for how the implementation works. Windows should be comprehensible with minimal background knowledge now. Manual tests are provided for windows hello, so these can be easily tested. Automatic integration-tests for rust are sadly not possible still, since it is unclear how the Windows-hello prompt would be emulated.
## 📸 Screenshots
## ⏰ 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
2 Likes
grb
September 20, 2025, 3:54pm
171
The option is “hidden”, and is only seen when you first set up the PIN. To enable or disable the option when you already have a PIN, you first need to disable “Unlock with PIN”, and then re-enable that option:
1 Like
Ah, obviously I didn’t remember that it was that much “hidden”. I’ll change my previous post.
PS: And the desktop app and browser extensions are inconsistent here (the latter doesn’t hide that sub-option when “turned on”):
klodoma
September 23, 2025, 12:12pm
173
Since some time, the master password need to be entered in order to unlock the desktop version of Bitwarden. Unlock with Windows Hello works afterwards… but not before.
I need to do this every day. I assume something changed, but it’s very very annoying.
Bitwarden version:
Nail1684
September 23, 2025, 12:20pm
174
@klodoma I moved your post into the relevant thread.
First, see this from the Release Notes 2025.8.0 :
The latest update from Bitwarden from @Micah_Edelblut :
Hey all, I wanted to jump in and provide an update on where Bitwarden is with this issue, as well as address some common themes in the comments.
First, an update. As @grb noted, we are researching ways to restore the previously supported behavior without downgrading the security of our implementation. We will let you know if this research leads to changes, but so far we’ve seen some encouraging results.
Second, a clarification as to why this change was introduced. The previous solution provide…
2 Likes
At some point, I presume after an update, Bitwarden desktop app in Windows started to require entering master password to unlock the vault after a Windows reboot despite my setting to lock the vault on timeout action. I have the timeout set to “on system lock”. In previous versions, all I needed was biometric verification to unlock the vault after a reboot. In my case, I use a fingerprint sensor or camera via Windows Hello. I wanted to ask if this change was intentional and if it was due to security concerns. Thanks.
marlin
October 1, 2025, 1:27pm
176
Yes, this change was intentional, see this answer for details.
2 Likes
@mveras1972 I moved your post into the corresponding thread. See the posts above for more explanations etc.
1 Like
Thank you. I did notice that the web extension now works more predictably and consistent than before and that is a welcomed behavior.
2 Likes
user154
October 13, 2025, 12:03pm
179
Hi all, I understand that the whole re-key-in password on app restart is a thing now and I am okay with that.
I have a query on making my workflow more smooth.
On app restart, is there a way to add the mobile notification login without logging out. Right now, I have to logout to use that functionality, which is kinda weird tbh. I also don’t want to logout everytime my vault timeouts.
If not, could there be a separate option added to set “auto-logout” on app restart?
grb
October 13, 2025, 3:19pm
180
@user154 Welcome to the forum!
You could propose this as a feature request .
A work-around that may accomplish the same result would be to create a shell script that deletes the Desktop app’s data.json cache, and then use your operating system’s scheduler to trigger that script to be executed whenever the Desktop app is closed.
1 Like
There is also a related feature request that you can vote for (which was already mentioned above):
Bitwarden already has a feature called “Log in with device”. What I am proposing is identical functionality but for unlocking your vault. This would provide a great alternative to manually typing in master password/pin and where biometric unlocks are unavailable - not every desktop machine has a camera or fingerprint reader, but most people will have their phone easily accessible at all times.
Similar to “Log in with device” feature, provide an “Unlock with device” button under the empty Mast…
Piercy
October 27, 2025, 3:20pm
182
So there was a bug with a windows feature that affected SOME users, and the solution is to inconvenience every user? I can understand making it an option so that the affected users can have a better experience, but we are encouraged to make incredibly long and complex master passwords, and now you are telling my I need to keep entering it? It very much defeats the purpose.
Bring back the old functionality with a setting for the affected people. Very poorly thought out decision.
grb
October 27, 2025, 3:46pm
183
@Piercy Welcome to the forum!
A fix to restore Windows Hello unlock on app restart has already been developed (PR #16432 ), and should be available in an upcoming release.
The underlying issue and justifications for changes made have been discussed at length in Github Issue #16106 .
Do note that if you keep the desktop app running and logged in, but locked, you only need to enter the master password upon reboot. If even that is too burdensome, you might check out login with device until another fix comes about.
Found in the 2025.11.0 release notes :
Windows Hello update : You can now unlock your vault with biometrics immediately after the Windows desktop app restarts, rather than entering a master password or PIN. When setting up biometrics in the Windows desktop app , uncheck Require master password or PIN on app restart .
3 Likes
xiixexe
November 14, 2025, 8:15am
186
Still doesn’t work on v11.0
Below is when Windows Hello option enabled. Disabled Windows Hello, re-enabled it again, there’s no checkbox that says, “Require master password or PIN on app restart .” anywhere. There’s no Windows Hello prompt when re-enabling it either. However, when vault is locked (not logged out), Windows Hello works. Biometric thru browser extension is broken.
1 Like
)
