Am I just really dumb or bad at searching? This isn’t the first time I searched for something, didn’t find it, made a post, found out it was made.
Oh well lol, thank you.
Thanks; I have merged the threads. Don’t forget to click the Vote button at the top of the thread if you support this request.
doodle7119
take bitwarden for example, the login can be protected with a passkey, and the 2FA section is protected by another passkey(under webauthn) but the two keys don’t work interchangeably.
This. passkeys (or let me specify … things being seen by password software as passkeys) are now being used for both full login as well as 2FA… which are different passkeys (one being seen as a devicebased passkey usually shown as the browser and one being seen as an hardware passkey, usually FIDO) and both can be saved to Bitwarden.
However as it is now we have to choose which of the two to save.
Not to big of an issue as the websites will always accept username/password regardless so im not to much of a fan of fully relying on passkeys for both at the same time… but it nonetheless can be annoying and is something to be discussed for sure 
That is not the case with the Bitwarden account. The “login-with-passkey”-passkey for the Bitwarden account is a real ‘passkey’, but the 2FA-“passkey” for the Bitwarden account is not a real passkey.
I know, Bitwarden renamed it’s 2FA-“passkey” recently to “passkey” (before they called it “FIDO2 WebAuthn”), but the team is already discussing to change the name again, because it is not a passkey…
Real passkeys are so-called “discoverable credentials” - but Bitwarden’s 2FA-“passkey” is a so-called “non-discoverable credential” and therefore not a passkey, as defined by the FIDO alliance et al.
I think something is not quite right here…
Device-based and hardware-based passkeys are the same thing.
There are two types of passkeys:
- hardware-bound/device-bound passkeys
- synced/“software-bound” passkeys (usually ‘synced’ via cloud, therefore sometimes also called “cloud-based passkeys”)
And they are both FIDO2.
And Bitwarden itself can only store synced passkeys, not hardware-bound passkeys.
1 Like
Sure… the thing is that all of that doesnt matter and changing names isnt fixing anything.
Its very simple… if I go to paypal and enable passkey to replace login, bitwarden pops up and can save that key.
However, if I go to paypal and enable 2fa hardware key… Bitwarden also pops up and is able to save it.
And both then can work… both the password replacing passkey as well as the 2fa passkey work.
It however ofcourse cannot save both.
And this is one of multiple sites ive seen that on so far.
And how it works, how it differs or how its named has ZERO impact on what an user actually experiences.
They can call it the ultimate void key for whatever cares about it, but as long as Bitwarden can save both those keys, pops up to make users aware of that and then only allows one to be saved… that user is gonna be annoyed and ask support about it.
And the more sites that allow this, the more this will start happening.
Whatever the reason is fully separate, only thing users care about is what is shown on their screen and nothing else.
2 Likes
@Timeraider I agree, that it is complex and confusing - and probably anything but intuitive for users. And it would be much better if it was better explained and would work more intuitively.
On the other hand, it is not as simple as you imply.
2FA-“passkeys”:
- some services use real passkeys for that = discoverable credentials
- but most services use non-discoverable credentials as “2FA” (= not a passkey)
And by the way: a passkey is a passkey. I mean, “two types of passkey” (as I wrote before) may be confusing as well, because a passkey can theoretically be stored as either one… You usually can store a passkey either as hardware-bound or synced. Mostly. But some services provide restrictions about that, e.g. only allowing to store the passkey on a device/on hardware.
And as far as I know, you can’t store non-discoverable (FIDO2) credentials in the Bitwarden vault. And here, I guess, you can’t demand something being stored in Bitwarden, that can’t be stored in Bitwarden at the moment (BTW, is there a feature request for storing non-discoverable credentials? - I remember, the team is aware of that…). [Edit: Seems you can store non-discoverable credentials in Bitwarden. See new comment from me below.]
That it is implemented so heterogenous around services, adds to the confusion, I guess.
Other than that… back to the topic: my current standpoint: I guess, for most services, one passkey for a Bitwarden vault item is enough - until now I never had the need for a second passkey… other than that, I agree now, that it wouldn’t harm, to be able to store more than one passkey per vault item, just in case… (given the user experience wouldn’t be harmed by that then)
I haven’t tried it - but I would guess, that PayPal creates in both situations the same passkey, that can do “both”. Have you tried to create it one way and use it the other way? Would be interesting to know. (if Bitwarden can store both, as you say, it must be discoverable credentials = passkeys - and therefore I guess they are the “same”. A passkey can perform “full login” and can perform just 2FA.)
You should be able to save both, albeit in two separate vault items.
From this page: Storing Passkeys | Bitwarden Help Center
“Passkeys are stored and invoked via Bitwarden browser extensions and mobile apps. This means that both discoverable and non-discoverable passkeys can be stored in Bitwarden and used to log in to websites with passkey capabilities.”
I’m a bit confused about the different types of passkeys though, so I’m not sure that non-discoverable (FIDO2) credentials and non-discoverable passkeys are the same thing.
That’s a given though, isn’t it? I personally like to organize my vault in a way that each account needs one vault entry. So far, I never had a problem achieving that. I suspect most people like it this way.
Oh, interesting! I just did one (!) test with GitHub, because there you can create a passkey (for full login) or a “security key” (only for 2FA) - and here my report:
It seems, Bitwarden can indeed store the GitHub-2FA-“security key” labeled as a passkey (which is incorrect). And in fact, it can only be used as 2FA and not for the full login to GitHub.
Only the real passkey created in GitHub can provide full login then.
So obviously, Bitwarden can indeed store both - discoverable and non-discoverable FIDO2 credentials.
Though, again, not ideal, to call this a stored passkey then, as non-discoverable credentials are not passkeys.
And then I would suggest, that it should indeed at least be possible, to store one discoverable credential (= passkey) and one non-discoverable credential (whatever it should be called 
) in one vault item. And both shouldn’t be called passkeys then, because they are not the same thing.
@RyanL @Micah_Edelblut (–> see text above also 
)
“Non-discoverable passkeys” is an interesting term. I’m no WebAuthn expert, but it is not a right use of the terminology. Bitwarden seems to use the terminology not as it should be, unfortunately… PS: Somehow Bitwarden decided to call all discoverable and non-discoverable FIDO2 credentials passkeys, which goes agains the right terminology…
PS: Here two sources for the terminology (and BTW I think matters to use it correctly, because otherwise it only creates more confusion):
"Passkeys are Discoverable Credentials." (Terms | passkeys.dev )
And here Yubico describes it more detailed and a bit more unclear in the first sections maybe: Discoverable vs non-discoverable credentials But then in the paragraph about “Non-discoverable credentials” they write relatively clear: “While non-discoverable credentials are not considered passkeys…”
… Just an idea: what about the name “2FA-key” for the non-discoverable credentials (instead of incorrectly calling it passkeys - and as it’s main or only function is providing 2FA…)?! @RyanL @Micah_Edelblut
PS: And I would like displaying it like this:
“2FA-key (non-discoverable FIDO2 credential)” (PS: or “2FA-only-key”)
→ simple label, and the full technical term for those who want to know it exactly
WHAT IS A PASSKEY?
Any passwordless FIDO credential is a passkey.
According to this definition, a non-discoverable credential can be a Passkey.
The difference between discoverable and non-discoverable credentials is just who stores the public key:
- discoverable: the user authenticator device
- non-discoverable: the relying party server.
As I understand it: no, because a non-discoverable credential doesn’t provide passwordless login - it is only be used as a 2FA and doesn’t replace a password.
And if you read on on the link you provided, it says a few paragraphs later: “From a technical standpoint, passkeys are FIDO credentials that are discoverable by browsers or housed within native applications or security keys for passwordless authentication.” (emphasize is my edit)
I don’t know the complete details - but the non-discoverable credential doesn’t store anything on an authenticator. That is why e.g. a YubiKey has unlimited (!) “storage” for non-discoverable credentials. (see e.g. here https://www.corbado.com/glossary/non-resident-keys)
So not only the location differs, but the kind of data that is stored or not stored (and if it only provides 2FA or full passwordless and/or username-less login) differs between discoverable vs. non-discoverable credentials.
I’ve found this: Firstyear's blog-a-log
Under “So Why Are Resident Keys a Problem?”, it talks about the definition of passkeys.
Essentially, it says that in the beginning there wasn’t a clear definition of what a passkey is. The definition of “discoverable WebAuthn credentials” came later and it just stuck.
This solution wouldn’t always solve the problem with 2FA though as I understand it because a 2FA implementation could also require a discoverable credential.
A non-discoverable credential can provide passwordless login. Duo implements passwordless login with non-discoverable credentials (or at least it did so a couple of months ago, the last time I tried it).
It is true that a discoverable credential has advantages in the login flows that it enables (eg. to be able to login without even entering a username, like in this forums, for example). But the drawback is the limited storage available on (old, and not so old) hardware keys.
I repeat, being able to login passwordless is perfectly possible with non-discoverable credentials. Being able to login without a password and a username is not.
1 Like
It works much like Bitwarden’s cloud-vault.
Your Yubikey encrypts the private key with its own “master password” and uploads it to the RP (relying party == website), calling it the “credential id”. When you go to login, the RP gives the ID back, and the Yubikey decrypts it to retrieve the private key.
This also hints at why one must provide a “username” to the RP when a non-resident key is used – the website needs to know which credential ID to hand out.
3 Likes
“2FA-Key” would be a wrong name as it can also be used as a passkey
Non discoverable simply means that it is not written on the key, so you have to type your username on the website in order for the passkey login to work.
For a discoverable one, it is written on the key, so you can login without typing anything 
Blockquote
The difference between discoverable and non-discoverable credentials is just who stores the public key:
-discoverable: the user authenticator device
-non-discoverable: the relying party server.
Did you mean the private key ? Normally the public one is stored by the relying party in any case
It was just a suggestion… And… no, only a passkey would be a passkey. A non-discoverable credential is not a passkey, per definition…
Non-discoverable = not a passkey. 
Did you see the definitions I provided here?
Please read this one Firstyear's blog-a-log It will explain you better than me why the definition is wrong