Reading into what @dwbit just posted, I don’t think it means what people are asking for here. I think what it means is that instead of using entering your BW vault master password and 2FA (e.g. a Yubikey) to login to your BW vault, you will simply need to have a nearby authenticator device (i.e. a phone via bluetooth) after entering your user ID.
I do not think it means BW will have any capability to “proxy” if you will, your existing 2FA token or phone proximity (via bluetooth) to login to sites using this new “passwordless” authentication as many here are hoping. i.e. using BW as a central credential repository for these new credential tokens like it is for TOTP codes.
The use case is simple. How do I authenticate when I lose my phone? How do I enroll my new, replacement authenticator device? How can I have multiple authenticator devices enrolled? (i.e. one for me, one for my spouse/partner, and one for my “designated survivor” family member)
The above isn’t much of an issue for folks already using 2FA tokens (e.g. Yubikeys), but it will be for folks new to this and going from passwords straight to passwordless, so there isn’t an alternative 2FA to fall back on. It will likely look a lot like how we manage TOTP enrollments now. And since we can capture and use TOTP credentials within BW now, is there an articulable challenge to being unable to do exactly the same with these new FIDO2/WebAuthn credentials? i.e. unique FIDO2/WebAuthn credentials per vault entry, that are in turn, unlocked through your BW vault’s access FIDO2/WebAuthn credentials.
Yes, this feature request is about storing passkeys, but there is a secondary discussion that we can break out into a new post in the ‘ask the community’ section if needed, regarding using other devices to authenticate instead of master password (using confirmed devices) which is slated for the November release.
Confirming a device is as simple as logging into Bitwarden once on that device and then checking a tick box in the settings menu for ’ approve login requests’
Thank you, @dwbit. I agree there are two discussions. What’s coming to BW is WebAuthn/FIDO2 proximity authentication (aka “passwordless”) for BW itself - logging into your vault.
The other discussion (mixed into this one) is about using BW as a manager for these new credentials (alongside passwords and TOTPs) with the individual entries of our vaults. That’s what could be broken out as a separate topic as a feature request, maybe after the dust settles from rolling out the new capability.
My understanding is that this feature request is already about storing these new credentials (WebAuthn/FIDO2/passkeys) in your vault. You seem to be suggesting that topic should be a separate feature request, unless I’m misreading.
The passwordless feature already on the roadmap refers to something else (as clarified by @dwbit), while the feature discussed here is being worked on but not on the roadmap due to it being updated quarterly.
Microsoft, Google, and Apple have announced support for the FIDO2 passwordless initiative that media are calling “Passkeys”. Because Passkeys creates a new key pair for each web site login, there is the issue of moving all these key pairs among devices. I am sure that Google will do that for Android and Chrome and Apple will do it for their iPhones and Macs, but what about between Android and Apple or Linux?
Would Bitwarden be able to support the new Passkeys cross-platform like it does with current passwords? I want to sync Android to Linux desktop and I will wait for Bitwarden to support this, if the feature will be added.
Bitwarden does currently support FIDO2 WebAuthn for MFA verification in addition to your master password for vault unlocking.
Bitwarden doesn’t support using these “passkeys” to login in leui of the master password yet, but there is a current similar feature request for this to be supported. Though like most things in adopting to FIDO2 password less login fully will take quite a bit of engineering on the backend to integrate.
Slight nuance: many of us have been asking for non-FIDO unlock using Yubikeys. We’ve made many arguments as to why this relatively cosmetic feature would have security value.
This thread is a little bit confusing. There seems to be 3 ideas being discussed:
Bitwarden support for logging into other websites/apps (e.g. Google, Reddit, …) using FIDO2 passwordless login
Logging into Bitwarden using FIDO2 passwordless login
Unlocking the Bitwarden vault using a physical device such as a Yubikey, without needing to be FIDO compliant
I believe @kwe is referring to #1 in this list. I completely agree with needing cross-platform support, and hope that Bitwarden will support these Passkeys, switching from being a “Password Manager” to an “Account/Passkey Manager”.
While we don’t have many details yet, I’m concerned that the Apple approach will end up locking us into their ecosystem, even though I could use my Apple devices to log into any non-Apple device. Having Bitwarden support for Passkeys will also help with the current limit of 25 resident FIDO2 keys on Yubikeys for example (albeit slightly less secure).
Thank you, @landlesscampfire, you are entirely correct. After seeing my thread derailed and hijacked I gave up on getting any information.
We need third-party FIDO providers precisely because Google, Microsoft, and Apple will refuse to exchange key pairs among themselves in yet another attempt to wall their gardens.
I wish Bitwarden would just go ahead and announce multi-platform support for FIDO2. They are our only hope.
There’s also another interesting discussion happening here:
It’s still going to take a while before we can realistically use Passkeys, considering that as of today, only Microsoft is offering a passwordless login experience (so far it still seems restricted to Windows machines). On desktop, browsers still need to be updated to support software-based FIDO2 devices, and on mobile Apple/Google would need to allow 3rd party apps to provide FIDO2 logins (don’t see this happening for at least a couple of years since they seem to be pushing for their own passkey solution at the moment).
In any case, it would be good to hear from the Bitwarden team about what their high-level plans would be going forward.
Thanks for the feedback everyone! Here is a recent post from the Bitwarden team:
rest assured that Bitwarden is firmly committed to the FIDO Alliance (going on our 3rd year as a member) and developing FIDO2/WebAuthn functionality beyond the use cases in place now. The ideas and suggestions are welcome, Bitwarden remains active in this area, and we look forward to more ahead!
They actually still do. Passwordless.dev is about making ti easy for web sites to adopt WebAuthn sign on. It has nothing to do with storing WebAuthn credentials in Bitwarden… There still remains so much confusion around that.
Seems like the FIDO alliance is talking about crossplatform support, there is a little overhead, but still quite smooth process for creating passkeys on each platform/ecosystem. You can find a video on the fido alliance website, under standards and tech, then passkeys.
I think this portability could challenge the need for a central place to store Webauthn secrets, unlike the scenario with passwords today.
I don’t think that’s quite how Passkeys work. The “cross-platform” part is just the protocol implementation. Everyone is still creating passkeys “on each ecosystem”, where ecosystem is that individual website’s user identity pool.
From what I understand, it is more like an exension of the current TOTP authentication processes, except that instead of having to ask the authenticator for a code and then typing it in, it’s all automated in the protocol, and they’ve eliminated using a shared secret (seed) between the server (the website) and the client device. The idea is that you would only generate your Passkey using your secured access-controlled device.
Whether each “ecosystem” (which remember, could be each individual website/community) will require separate Passkeys or allow sharing with Google or Apple or Microsoft or FB/Meta or your banking institutions or your healthcare providers and insurers or your local, county, state, and federal government ecosystems is likely going to be complicated to sort out.
The same reasons you don’t want to share Passkeys across ecosystems (i.e. websites) is the exact same reasons you don’t want to use the same passwords across websites (aka ecosystems, or user pools) and the same reason you don’t share TOTP secrets, unless the ecosystem is federated across the websites to share a common authenticator - something like an Okta or Ping could do, but mostly don’t because nobody (from the server side) wants to share their user pool with another company/website/ecosystem whose interests might not always be the same as theirs.
You will still see the same “Login with your Google Passkey” and “Login with your FB/Meta Passkey” or “Login with your AppleID” just like you do now except whether or not your device lets you have multiple Passkeys or worse, doesn’t let you decide not to share a device/ecosystem’s passkey across other ecosystems and use separate Passkeys for each ecosystem under your preferences.
Then there’s the whole recovery and re-enrollment problem because we’re pushing a conflation of what is really device authentication and pretending it is user authentication when it is not. So that makes losing control over the device (physical loss or access) and re-enrolling a new device problematic. That will still remain a pain point in the overall UX.
The hard part in all of this has always been the individual provisioning of a secure, access-controlled individual client key. It’s why mutual-auth TLS never took off. We couldn’t figure out how to generate and give users the ability and the technology to maintain a client certificate, and compound the problem with certificates having expiration dates requiring users to renew them. This strips all of that down to just the bare asymmetric keypairs and hooks in client devices that browsers can access to generate and use as a keystore - just like they do for storing client certificates today. Whether it works and gets traction or not will all come down to the UX and ease-of-use. I hope it does, because it is better than what we have now.
