Hi,
I’m perplexed at passkey support for Windows in both the standalone app (2024.6.2) and the chrome extension (also 2024.6.2). Specifically, the bitwarden documentation page seems entirely different than reality when it comes to passkeys.
I see two major bugs where reality deviates from the documentation page.
- Created passkeys are not showing (nor persisting) the user ID attached to them. Neither in the “edit” not “view” mode. Neither in windows desktop app nor windows chrome extension.
- You cannot create multiple passkeys for the same origin. After the first one exists, the second one always overwrites the first even if you press the button to create a new passkey.
Here’s an easy reproduction:
Enter a made up username and create a passkey. Observe that the username is not persisted in the bitwarden UI.
Next, enter another unique username and try to register a second passkey. Pressing the “save passkey” button in fact overwrites the first one. You can actually press the plus button in the upper right to create a second passkey. But “save passkey” being an “overwrite” is not expected behavior IMHO.
I think that perhaps both bugs are related though. Since there’s no username attached to either (bug #1), I think bitwarden is forcing an overwrite because it is de-duping on a username that happens to be… (drumroll)… an empty string. (thus bug #2)
In my own experience calling the passkey registration API from javascript, I cannot find any way to coerce bitwarden in to saving the username or ID provided by JS. Windows credential manager works just fine, persisting and presenting both origin and user ID.
Is bitwarden broken? Why does the docs page suggest an entirely different experience where usernames are shown and persisted? it looks like the screenshots on the docs page might be macOS… so it it only other platforms that don’t get the correct behavior?
Passkeys are incredibly important, and this broken experience is disappointing to see broken and unaddressed. At the very least, a warning should be posted on the bitwarden docs page until the issue is resolved.
Thanks,
FWIW, as a follow-up, it would be incredibly userful to ensure that passkey details from the registration ceremony can transparently be shown in the bitwarden UI. This would include public key algorithm, the public key itself, user verification requirement, and the user object fields of id, name, displayname, and the passkey credential_id. I could see a PM arguing that this is too much detail for a product, but the reality is that in order to properly allow users to identify sign in activity (or failures) or audit a security incident, these details must be available, even if subjected to a secondary button press.
Bitwarden is seen as one of the most successful password managers by technical minded folks- so transparency & security auditability is a must- not just to retain that audience, but also to ensure the product plays its part in security incident review and login activity review for all levels of users.
@davidfiala Hi!
You speak of Bitwarden Password Manager?
Hi @Nail1684
I’ve updated the post to reflect the category for the password manager.
1 Like
Welcome, @davidfiala to the community!
This is because passkeys do not necessarily have a user ID. It is perfectly possible to perform a passkey authentication for an account that has neither a username nor a password. Read up on Discoverable Credentials for more details.
You can. It is just that each vault entry is limited to one passkey, just as it is limited to one username/password/TOTP combination.
The design idea is that the vault entry corresponds to a credential. If a credential is used in more than one location, you can list all of the URIs where it is used within the one vault entry.
Along similar lines, if you have two accounts for one web site (Google being the common example), you need to create two vault entries and list the login URI in both entries.
Why allow both one passkey and one password then? Simple. It covers the common case where a single account has both authentication methods – a very common scenario, given that we are entering a transition period.
Exporting your vault in JSON format will reveal some of those details. Others, apparently can be viewed with Chrome’s devtools and with https://webauthn.io/ (as you mentioned).
Thanks for the reply. And thanks for the tip about verifying stored info via an export. Off topic is that it’s unfortunate I have to dump my whole vault to disk to inspect one entry, but nevertheless I ran a test and see everything I’d hope to see there. Thanks again.
Discoverage credentials or not (aka resident or not), bitwarden is storing the key as an entry. Within the exported entry I can indeed see that the username etc is stored alongside residency status, credential id, and more. (yay)
But: I think my opinion is that it’s hostile UX to not use the user ID as part of the passkey creation or passkey merger into existing bitwarden accounts. There’s two cases here at least:
-
I have no existing bitwarden account entry for foobar.com. I’m prompted to make a passkey. The server specified a username in the passkey creation request user object. Today: bitwarden omits username field regardless of discoverable credential state. Ideal: Bitwarden always populates the username field in the entry based on the user name of the passkey, regardless of discoverable credential. The user can later override the contents of the username by editing the entry, if they so choose.
-
I have a one or more accounts already stored with foobar.com, and it prompts me to make a passkey. Ideally: Use as a hint the passkey’s user ID to suggest which account you want to merge the passkey into. If the user simply selects “save passkey” button, then create a new account entry, with the user ID prepopulated.
I can think of zero cases where I wouldn’t want to have context on my passkeys and their associated user visually displayed and used as creation/merger hints.
Imagine the user makes a mistake in case #2. They merge the passkey to the wrong user. How would they ever resolve that without being able to see passkey details?
For case #1 even on sites that support passkeys, they also offer password sign in, and other sign in options. Imagine I’ve lost or forgotten my username on foobarcom and for some reason my passkey has been deleted from my account’s list of sign on credentials… Given only my bitwarden vault, how would I recover my account username/email for that site if bitwarden doesn’t show me what that passkey was attached to?
To cite windows 11 UX as an example: Regardless of whether the credential requests residency (discouraged/preferred/required), windows 11 built in passkey manager always stores and then shows you the attached username of keys it knows about. They could do better than just showing you the site and username, but they at least give you something.
Thanks for your time and consideration,
A large part of this probably is that Passkeys are “a work in progress” within Bitwarden. Just within the past few months have they implemented the ability to backup/restore passkeys. And this month’s release ceases playing loose about what User Verification means (some would argue the pendulum swung too far). And it is only recently that they began mentioning if an entry has an associated passkey and made it easy to delete.
Thanks for the info. I have updated the parent comment to reflect it.
1 Like
