It’s enabled automatically after you have logged in with a password successfully the first time. Something like a “familiar client” token is saved in your Bitwarden data directory, and the next time you try to log in (you need to be logged out, not just locked), this option will be presented on the password screen (the second screen, with the first screen asking for the email address).
You need to have logged in with a password on an approved device (web, mobile, desktop). You probably have, since the option is available on your web app, but I would have a logged-in mobile handy, just in case.
You also want to make sure that you don’t have a really old desktop app.
If that fails, I would try uninstalling the desktop app, deleting the associated data directory, and then reinstalling it.
Although my desktop client is entirely up to date, some of the settings may have become corrupted, resulting in the ‘Login with Device’ feature becoming unavailable.
I’ll try the full delete and reinstall option you suggested.
This is a misunderstanding I think. The biometrics option we are talking about here does not bypass login. It only can unlock a vault you’re already logged in to. (only if we had passkeys for login in all BW apps we could have a biometric login option – all biometric options that are available at the moment, are just biometric unlock options)
Despite technically correct, this is a pure wordplay in the end for all the affected people. The end result is that some of our users are blocked from logging in purely with Windows Hello, which is a primary authentication system on which our company fully relies, and the ones who do not remember the long passwords and had the bad luck in form of Bitwarden mobile app getting logged out for whichever reason are blocked from logging in to their vault at all now and have to reset their vaults.
The main point is that if a vendor deprecates features, especially authentication features which can result in losing access and all data, the customers have to be informed in time, which clearly did not happen. I am reading every e-mail that comes and properly analyse the announced changes, if they can affect us or not and this was not there.
This would not change anything for ISO 27001 compliant organizations who MUST deploy patches within a specified time frame to mitigate vulnerabilities - we have it in our audited policy. However, this policy also counts with a proper change management on the vendors’ side. So if a vendor releases a f—up, well, we have a f—up here.
Furthermore, even if Bitwarden gives us the option within the software, that would not change anything for us - we use a third-party patch management system.
To Bitwarden developers - I would expect now that in response to the cowboy style release you release a rollback allowing the authentication again for, say, at least 3 months, with a clear warning about the vulnerability during the logon process. Also you should then send out at least 3 emails to all your customers mentioning the deprecation of this feature
This would enable everyone affected to mitigate the data loss cases and communicate and process the change as is normal in any company with a change management process.
That mentioned is the bare minimum i would expect from you. Much better solution would be implementation of an organizational policy that would give the admins the option to allow or disallow the Windows Hello login without the Master Password prompt.
Also one more thing - if you enable any master password bypasses, there should be at least one reminder prompt every week from the logged in UI for the user to enter the master password to simply remind the user about its existence and need. This is how e.g. Signal implements it and it’s a perfect solution that mitigates the forgotten password cases effectively.
Sorry that it came across as wordplay for you as it wasn’t meant as such.
Even before the change that now occured for the desktop app, it was never possible to use Windows Hello as a form of logging in (exception: using passkeys for the web vault, which is a completely different thing). You mean the first unlock on app start - but I still think it is necessary to correct that misunderstanding, as due to that recent change, no one is blocked from logging in (!) to the desktop app.
The change of the desktop app in regards to Windows Hello has nothing to do with “logging in”.
No offence, but for the sake of your user’s accounts, your company should rethink this approach, as it is based on a misconception of the software.
As long as your users have a master password, it remains the primary authentication system - and that should be made clear to your users, your company and you.
Sorry for the wordplay again Logging in…true. That was not the case. Unlocking the vault after half a year of not needing to enter the Master Password…well…that’s what happened.
No offence, but for the sake of your user’s accounts, your company should rethink this approach, as it is based on a misconception of the software.
No offence, but if you allowed such s----y UX, then killed it without warning and in the end tell the customer to bear the consequences for that all is maybe also a misconception. First of all of the basic UX design rules, second of your end users and third of the corporate customers that pay for your service.
We made sure the TPM keys are stable, it worked flawlessly for two years, we had backup devices in place with a completely separate authentication flows set up for every user and a well thought training program in place. The only thing we did not have was recovery for 30 percent of users who were onboarded before we were even allowed to turn on the account recovery for legal reasons. If someone has lost access because they forgot the password, it was their problem. Now it was caused by your development, which is simply unjustifiable. If you allowed a scenario in your software, then you should count with the scenario.
Hey @m.snapka, just a reminder to review the community guidelines. Our community moderators are volunteers (not Bitwarden staff). Rest assured, we understand your frustration, and the feedback in this thread has been passed to the appropriate Bitwarden teams for review.
Well, I thought I had this figured out, but I guess I’m missing something.
This morning, after booting up my laptop, I opened the desktop app and logged out. Then I logged back in using “login with device”. Then I opened Firefox and attempted to unlock the browser extension. I was expecting to see the option to “Unlock with Windows Hello”, but it wasn’t there. I had to log out of the browser extension and log back in with device to be able to use it.
There are a number of activities that can require you to log back in and therefore need the master password. For example:
Getting a new laptop or phone, resulting in biometrics being reset.
Reinstalling Bitwarden clients to repair upgrade failures.
User suspects a compromise and selects “deauthorize sessions” (in the web vault).
User decides to strengthen their encryption settings (in the web vault).
Bitwarden detects a threat and decides to deauthorize everyone’s sessions as a preventative measure.
A software bug cause Hello to misbehave (e.g. A MS bug results in the prompt displaying in the background and nobody has yet discovered the workaround of covering the camera until they have manually brought it to the foreground)
To avoid setting your users up for failure, you ought to ensure they have contingency plans. Everyone should have an emergency sheet. Everyone. All your users. The only exception would be for those that login to Bitwarden with SSO, and even then it still would be a good idea.
Desktop: Make sure you can use biometrics to unlock the desktop.
Desktop: In the settings, ensure “Allow browser integration” is on.
Desktop: For good measure, at least temporarily turn off “Require verification for browser integration.”
Extension: In the settings, if “Unlock with biometrics” is already on, try turning it off. Click the “back” arrow on the extension, go back to “Account Security,” and turn it back on again; it will ask you to authenticate at this point. If it’s turned off, turn it on. I also have “Ask for biometrics on launch” enabled.
Extension: If the above doesn’t work, you might have to try turning the extension off and on, or uninstalling and reinstalling it.
The procedure discussed was as follows, and it worked yesteday:
Log out of desktop
Log into desktop using “login with device”
Log into extension using Windows Hello
This morning, the above approach did not work. I had turned the laptop off overnight and rebooted it this morning. On reboot, the desktop app started and began running locked and was minimized to the task bar, as specified. I logged out of it and logged back in successfully using “login with device”. Firefox was open and running, and the extension was locked. I clicked the extension icon and expected “Unlock with windows Hello” to appear. It did not. So I proceeded to log out of the extension and log into it using “login with device”. The laptop has been running all day this way.
Awhile back, I closed Firefox and just now restarted it. The extension was locked, as it should have been. I clicked on the icon and, lo and behold, the “Unlock with Windows Hello” option was available!
I am having the same problem, in both Chrome and Firefox browsers, on Windows 10 Pro. This problem happened before not too long ago for a while and then went away. I noticed now that if I unlock the desktop app first with the master password, then I am able to subsequently unlock the browser vaults with biometrics, and that sticks even when they lock again after timeout. But after a reboot of my computer, I have to repeat this with the desktop app.
Regarding the issue with the Windows Hello prompts not coming to the foreground/focus,
I have been using the follow AutoHotkeys script as a workaround for at least a couple months and it has been working reliably:
#Requires AutoHotkey v2.0
Persistent
SetTimer(KeepOnTop, 1000) ; Check every 1 second
KeepOnTop(*) {
hwnd := WinExist("ahk_exe CredentialUIBroker.exe")
if hwnd {
hwnd := WinExist("ahk_exe CredentialUIBroker.exe")
if hwnd {
WinActivate("ahk_id " hwnd) ; Bring to foreground
hwnd := WinExist("ahk_exe CredentialUIBroker.exe")
if hwnd {
WinSetAlwaysOnTop(true, "ahk_id " hwnd) ; Set always on top
}
}
}
}
It basically just looks for the Windows Hello UI Windows and brings it to the front and focus if it exists. I got this from somewhere else online, but originally it through occasional errors due to weird race conditions. That is why I added the redundant nested if statements, which all re-check that the window still exists before attempting to bring it to focus.
I know this is just a super janky workaround, but it had been working reliably once I added to extra if statements, so I suspect with more consideration and proper error handling, I wonder if it might be possible to do something similar inside the Bitwarden code, as a way to resolve the original issue: which was to do with the “Windows Hello” prompt stuck in the background and not automatically being given window focus.
That being said, I’ve done enough software dev to know that the full scope of the situation is likely far more complex that what my over-simplified workaround can solve.
Logging in…true. That was not the case. Unlocking the vault after half a year of not needing to enter the Master Password…well…that’s what happened.