A side discussion in the feature request thread “Support more than 5 FIDO2/WebAuthn keys for 2FA” became off-topic to the original feature request topic, so I’ve moved the discussion into this new topic.
Good idea, BUT: my last info is, that the FIDO2 credential Bitwarden uses for it’s 2FA, is a ‘non-discoverable credential’ and therefore not a passkey, altough Bitwarden (falsely) labels it (still) “passkey”.
A passkey is a ‘discoverable credential’ - and don’t confuse it with “login with passkey” from Bitwarden… the latter credential is a passkey = discoverable credential, that get’s created.
(BTW we had that discussion a few weeks/months ago on Reddit with Mika and Ryan from Bitwarden, why Bitwarden “falsely” labeled it that and I critized it, because it leads to confusions like this one. No offence. My last info here is “the team discusses it”…)
PS: And I guess I wanted to say by that: the FIDO2-Bitwarden-2FA can’t be “syncable”, as it is a non-discoverable credential - and not a (potentially syncable) passkey.
Does that mean that people who store passkeys on a phone (or in their OS) are not able to use such passkeys for their Bitwarden 2FA?
Agreed, non-resident does mean Bitwarden can not properly call it a Passkey, but I don’t believe non-resident would preclude it being “syncable”. Syncable and resident are two related, but independent concepts.
Syncable means that the private key can be copied from one “vault” to another.
Resident means that the private key is stored in the “vault”, as opposed to non-resident meaning it is downloaded from the RP (“website”) on demand – and additionally encrypted with the keypair belonging to the “vault”/yubikey itself.
So, one could “sync” non-resident fido2-things, by syncing the private key for the “vault”/yubikey itself. But, outside a theoretical discussion, I can not imagine why.
Do you mean whether the “login-with-passkey”-passkeys you created for Bitwarden can also be used as a 2FA? - I have no possibility to test it thoroughly now… One “obstacle” I just encountered: for a test account, I once created a “login-with-passkey”-passkey… but as I just tested to log in with that as 2FA, I can’t even choose the passkey/FIDO2-option, as I didn’t set up the FIDO2-2FA option separately for that account.
On the other hand, I tested myself, that e.g. my Android phone and Windows Hello are indeed capable of storing a Bitwarden-FIDO2-2FA-credential (and that can successfully used as 2FA for login to Bitwarden then!). Whether that is all the time a non-discoverable credential then (or if sometimes, when certain conditions are met, also a discoverable credential can be created?), that get’s stored, is above my head. (and I can’t remember, if Micah or Ryan said anything about that)
You people are the FIDO experts - I’m not. So, but as I understand it so far, isn’t the “new thing” with passkeys mainly, that they are syncable? I mean, the hardware-bound passkeys existed before, though they weren’t called passkeys e.g. 4 years ago. But they were not syncable… and, I know I repeat myself now, the new thing about passkeys was then, that they are also syncable. (so that there are two types of passkeys now: hardware-/device-bound and syncable)
So I’m a bit confused and honest question: non-discoverable credentials were syncable then from the beginning?
PS: Ah, and one thing I forgot before: to the whole discussion adds, that Bitwarden has some restrictions for the FIDO2-2FA- and login-with-passkey-creation. E.g. you can’t store those credentials via the browser extension in your Bitwarden vault - so I guess they prevent the creation of a “syncable” credential from the beginning and “force” the hardware-/device-bound route. ?!
No, I’m only talking about two-step login (2FA), not “login with passkey”. For someone who doesn’t have a Yubikey or other hardware key available, can they use their phone (or Windows Hello) to create a “passkey” as their Bitwarden second factor when doing a conventional login with master password?
Ah, okay. - But I thought I answered that also/already :
Apologies, I’m doing a lot of things at once and didn’t read your comment carefully. I don’t think that Android and Windows Hello store nonsyncable non-discoverable U2F keys, so your observation indicates that Bitwarden’s 2FA “passkeys” can indeed be bona fide syncable resident FIDO2 passkeys.
It would be interesting to use the Yubikey Manager to disable the U2F protocol on a Yubikey, and see if this results in creation of a syncable resident FIDO2 key when registering the Yubikey as a 2FA “passkey” in Bitwarden.
Edit: Revised some terminology to be more accurate.
The word “Passkey” and the concept of “syncable” both came about around the same time, but they are not co-dependent.
Here are a few references I have found extremely helpful:
FIDO Alliance’s Passkeys 101 – Great over view of passkeys. It does include “Passkeys can be securely synced across a user’s devices, or bound to a particular device (device-bound passkeys).”
Yubikey’s Discoverable vs Non-discoverable – explains what makes a key “discoverable” and states “non-discoverable credentials are not considered passkeys”.
My understanding is that “non-discoverable” harkens back to the earlier U2F FIDO days, with the goal of hardware keys not requiring local storage, beyond that what which was factory-programmed.
A syncable FIDO credential refers to the ability that its private key is synced in some way between different devices.
This is just not possible.
The private key of a FIDO credential created on a YubiKey, by design, is stored inside the YubiKey and is suposed to never leave it [*]. So, by definition, it can not be synced anywhere (whether that credential is a resident one or not).
[*] Except with attacks like YSA-2024-03.
I think you’ve misunderstood what I’m asking/proposing, because I used imprecise terminology (which I have now fixed).
There is some question as to whether Bitwarden’s two-step login option “Passkey” only allows non-resident, non-discoverable U2F credentials or also resident, discoverable FIDO2 credentials. In my experience, when a Yubikikey as both the U2F and FIDO2 protocols enabled, Bitwarden will only register a non-resident, non-discoverable U2F key when using the two-step long workflow. On the other hand, @Nail1684 has observed that when setting up a passkey for two-step login in Bitwarden, it is also possible to store the created passkey in Android; to me, this observation suggests that Bitwarden has created a resident, discoverable FIDO2 key stored in the Android OS (and possibly synced via Google).
What I intended to ask was whether disabling the U2F protocol on a Yubikey would allow it to store a resident, discoverable FIDO2 key to be used for two-step login (not passwordless login) into your Bitwarden account.
As you, @grb , mentioned the word terminology… just some remarks on that:
Well, one things seems to be clear: Bitwarden doesn’t use the older U2F protocol for creation anymore. So whatever it is, it is FIDO2.
(source: Two-step Login via FIDO2 WebAuthn | Bitwarden Help Center)
And that (my “whatever it is…” ) leads me to:
resident (older term) = discoverable (new term)
non-resident (older term) = non-discoverable (new term)
FWIW… (and though I think @grb knows this also, but you used both terms - and for whoever reads this in the future… )
PS: To my first part:
I guess, then it is also questionable, whether deactivating U2F on a YubiKey changes anything here… (as the credential Bitwarden tries to generate is FIDO2 and not U2F)
I think that you are already aware that the terminology used in Bitwarden’s documentation is not always precise, either. Thus, I would take with a grain of salt the warning that “U2F-only keys can not be added”.
Just did that on a test bitwarden account with a spare YubiKey 5NFC: with all yubikey’s interfaces disabled (even FIDO U2F) except FIDO2, then when adding the yubikey as 2SV Passkey it creates a non discoverable FIDO credential (whether the YubiKey’s FIDO2 app has a pin or not).
Well, I would also, because with that same account and YubiKey 5NFC, with all yubikey’s interfaces disabled (even FIDO2) except FIDO U2F, then it lets me add that YubiKey as a 2SV Passkey.
Btw, I think this is getting way off-topic from the original feature request.
I’ve now moved this side discussion into its own topic.
Yes, you can. I just did that for one of my two test accounts (on chrome browser extension). One requisite is that the account you are logged in on your browser extension and the account for which you are trying to create the Passkey must be on different servers (my main account is on bitwarden.eu and the test account for which I created those Passkeys is on bitwarden.com).
I could create both Passkeys for login-with-passkey (which are discoverable) and for 2SV (which are non-discoverable).
However, as expected, when logging in with the Passkey it asked me the master password to decrypt the vault (because, I guess, the bitwarden extension does not support HMAC-Secret).
I don’t think so.
I guess they prevent the creation of a Passkey for bitwarden into a bitwarden vault on the same server to avoid people locking themselves out of their accounts.
PS.: I know that bitwarden 2SV Passkeys are not discoverable, and thus, they are not Passkeys strictly speaking. However, FIDO credential is a mouthful, and I think this is the reason that bitwarden itself (and many other websites) calls them both (discoverable or not) just Passkeys.
When I had experimented with this just after passkey login was first introduced 9 months ago, it was not necessary for the two accounts to be hosted on different servers.
I recall hat there was some safety rail preventing you from storing a login passkey in the same vault where the passkey would be used for logging in.
But I did replicate your observation the passkeys stored in the Bitwarden vault are not capable of decrypting using PRF.
Interesting, but I guess “No, you can’t.” is still right, as I wrote “in your Bitwarden vault”.
Interesting again. Thanks for the experiments!
I’m a bit confused about your terminology here… okay, 2FA = “2 factor auth” and 2SV = “2 step verification”. But do you mean (when you use “2SV passkey”) that the passkey is itself (or has) 2SV or is (just) used as 2SV (the latter meaning being one of the 2 steps - or even both steps?)?
(probably you wrote it - explicitly or implicitly - and I didn’t get it)
Yeah, I know and I get that reasoning. On the other hand, this is not consistent with what the FIDO alliance itself says. In my spare time, I watched some videos of them on YouTube, and at least in the videos from 2022 and 2023, it is constantly said (when they wanted to be exact), that passkeys are discoverable credentials. I don’t know if this has changed by now as I’m did not not completely arrive in the year 2024 (before that sounds too odd: I mean with the FIDO videos ).
And because discoverable (passkeys) and non-discoverable credentials behave differently, I’m still not convinced, it is less confusing, to call them all “passkeys”. (e.g. if you call them all “passkeys”, why are some shown on my YubiKey and some not? - that is not confusing then? )
Yes, by 2SV I meant 2-step-verification (or 2-step-login, as bitwarden calls it on the web vault).
I try to resist calling it 2FA, because often, depending on the second step used, it is not really a second factor.
Yes, by 2SV Passkey I meant a Passkey set up for 2-step-login, not the ones used for login-with-passkey.
Yes, and I agree with you. But the truth is that this whole discoverability of fido credentials can be extremely confusing for users.
From the perspective of a normal user, when you create a fido credential on a website, you create something into your passwords wallet (be it your password manager vault, your android/iphone/windows hello account, or whatever).
The discoverability of that fido credential does not matter at all to you. That’s why, with bitwarden, the only way to know if a fido credential stored on your vault is discoverable or not is by looking at the internal json object with something like bitwarden cli: not very easy.
And using that fido credential is exactly the same whether it is discoverable or not. You don’t care at all.
The only case when the discoverability of a credential might be of interest to you (as a user, I insist) is when you store it on a hardware key with limited slots for discoverable ones. And, let’s be realistc, we, end users of hardware keys, are a minority.
So, if, from the point of view of a majority of users, discoverable and non-discoverable credentials are the same, why not call them always Passkeys everywhere and avoid unnecessary confusion?
Thats the reasoning, I guess, behind websites like bitwarden and others for calling them Passkeys everywhere. And I personally agree with it.
This makes easier to explain to a non technical user what a Passkey is: something like a password, that it is stored on your device, and since you do not have to remember or type it, is easier to use, being also more secure.
Yes, it is. But, as I tried to argument above: I believe the other way around is even more confusing, to more people.