You reference something that makes me nervous about this still emerging solution: passkeys being held within walled gardens. As a consumer, I want to own my passkeys (access to all may accounts), for those passkeys to be controlled by me, which means me being able to take my passkeys with me (liberty). I think if this becomes a barrier, it hurts the Bitwarden’s of the world who need to be able to provide a value proposition to Google/Apple/M$ customers about why BW should hold their passkeys, instead. Can you imagine law enforcement serving Google or Apple to not only provide them access to that account (today’s reality), but to also provide them access to any information related to your passkeys, AND to prevent you from accessing your passkeys?
It isn’t that you don’t “own your passkeys”. You most certainly do. The thing I’m pointing out is that those “walled gardens” are being setup so that yeah, you can re-use the same passkey to access all of those “walled gardens”, which could be big ecosystems like Google, Apple, Microsoft, etc, but don’t have to be.
It is encouraging us to go back to the ‘one ring to rule them all’ and essentially re-use the same password on all of our sites. Just with a more secure password that we think only exists in our phones or the motherboard’s TPM or our Yubikeys. And arguably, for now, that’s true.
Imagine a world where all of the websites you have accounts/passwords with now are using passkeys. How many websites do you have to go back and re-enroll your new passkey when you lose your phone or more likely, your phone or computer was only designed to have a 2-year lifespan anyway? Those devices won’t be as secure in the future as they are now, when your carrier or manufacturer drops all support for it, especially security support when the new model or a new technology comes along.
That’s the unintended consequences, and I can guarantee you Google, Apple, Microsoft, Amazon, your banks, your doctors offices, all the places you shop, your utility companies, etc, are not thinking about whatever painful process you will have no choice but to endure to get your new credentials established … again. It will be like identity theft, but on steroids because it will all be digital, the compromise will be automated, and your passkey will be tied to all of those ecosystems you “decided” to link together onto one passkey.
Is it a better password? Absolutely. But I don’t think it is the magical authentication solution it is being presented to be, and there will be tradeoffs. The challenge to BW is to understand those and develop capabilities in their tool (I think of it as a “password wallet” - with the same consequences if you lose it or someone steals it) to smooth out the adoption and the tradeoffs in attempting to transfer using passwords and manual processes to sing the private key of a cryptographic keypair with automated processes.
That’s why I said it was more like a complete automation of the TOTP system, just automating prompting for a code and entering it in by eliminating the human processing and data entry steps. And just like we have separate, different TOTP secrets to track and bind to the different entries in our vaults, we should have the ability to have similarly separate, different passkeys to track and bind to the different entries in our vaults.
People have multiple “profiles” or access privileges tied to their identity. That requries multiple passkeys to represent those separate identities, whether or not those systems have any support for a single person representing two separate “users”. Just like today - we ask for multiple profile support in BW clients. How would that work when you only have one possible identity - your one and only passkey - and the system you are interacting with has no concept of multiple user “profiles”, only completely separate “users”? The reality is that almost all systems people will encounter today are of that type. Those that have “profile” capability are the exception rather than the rule.
Hmm… interesting. Thanks for this post. A comment and a question:
Comment: With Apple’s current live implementation of passkeys, you must use keychain (fair enough) and you can’t export that key to a service like Bitwarden. In fact, you can only currently use Air Drop to move it within Apple’s ecosystem. If that doesn’t change, we won’t own our passkeys.
Question: you are saying that we won’t have a vault of different passkeys - one per service. Instead, the conceptual model is that we will have one passkey tied to our identity which allows us to access all services. I had not understood this was the implementation. And, yes, I would agree that creates a significant new risk if there is a successful virtual identity theft.
This is how I understand it: Once a passkey is created in one ecosystem eg Apple you can use that to sign in from another ecosystem eg Windows by using the option sign in with other device. Then afterwards you will be able to create a passkey in windows, if you like to. Now you will have two passkeys for the same service.
From a tech point of view passkey is nothing else than asymmetric authentication, and the private key can not be shared out of an ecosystem.
Re Comment: I have the same understanding of you. I don’t have an Apple device, so I can’t speak to what they are actually doing or not. History tells me that Apple isn’t likely to change their stance, because it allows non-Apple devices to access the Apple eco-system.
Question: I don’t have any knowledge of what BW will or won’t do. Just noting the issues and complexity around generalizing use and expressing concern there will be a difference between what the big companies with vested interests in maintaining walled gardens think it provides to them, and what users think it provides to them, and the possible difference in interests and benefits. Easy for Google, Apple, Amazon, Meta/Facebook/Instagram, Walmart, PayPal, etc. to integrate and rely upon for how it serves their needs to let you login quickly and with a high confidence it really is you so that you can consume their services instead of their competitors. That may not be the same as easy for users to keep track of, or to deal with the inconvenience and possible risk to other parts of their lives outside of their relationship with Google, Apple, Amazon, etc. when they lose their phone, upgrade their phone to a new one (do the old passkeys get wiped? Who guarantees that or is it everyone is on their own, best of luck to you, pal?), or their laptop gets stolen.
The point is Google could care less if bad things happen to Apple customers if something goes wrong with the passkey that Apple is using to interact with the Apple ecosystem. But how do you feel if the IRS and your state driver’s license department uses the same passkey that is used to access your bank accounts and Gmail accounts? Are you comfortable with a search warrant using your “driver’s license passkey” that also just happens to be the same passkey used to search your phone text messages, email, and bank accounts? I am skeptical the US courts will see that “passkey” as your property, and instead perhaps see it as the government’s property, much like a landlord allows you to use the key to your apartment, but the landlord legally owns the apartment and the key that allows access to their property. And if they see “your” passkey as government property, then they are free to use their property as they see fit and have no obligation to notify you, especially if you are under investigation of anything.
Or compelling you to use your passkey (again, which is argued as an extension of state property) to access other services nullifying any 4A protections, whereas, they could not do so if there were separate keys where you could articulate a 4A right to exercise. This is also a critical security control called “separation of duties”, or separation of purpose in terms of encryption keys. There are important reasons you do not want to immutably couple access grants to separate resources/services, which is what a “one passkey to rule them all” does, although on a per-device basis. In practice, that means if you do have a need for separation of access by separate passkeys, you will have no choice but to require separate devices. That is why people have multiple Yubikeys today, and why each person has their own Yubikey in an organization using them instead of having “one Yubikey to rule them all” hanging on a hook by the break room to grab when whoever needs access needs to use it.
The point is the “big boys” may have no problem building a system that fails to protect your interests, freedoms, and rights because they are only concerned with protecting their own, and any role your interests play are merely secondary, and from a marketing and adoption perspective (as in “How do we get you to use this new thing we want you to start using?”), not from a protection of your interests perspective by offering compensation or accepting liability if it goes sideways. Hence all the weasel-words in licensing “contracts” that essentially claim what they are providing has no value in one hand (that you can sue them over the loss of that value) and having enormous value in the other (to constitute a “fair exchange of value” required for a contract to be legally binding for when they sue you).
I have been looking forward to a passkey world, assuming that:
- services like Bitwarden would be able to host them
- consumers would be able to port them (we own our own keys and can travel)
- each service in my vault would have a unique passkey associated with it, similar to TOTP keys
If it only ends up meeting 1 and 2, then I am much less enthused about passkeys for all the reasons you illustrate.
I have the same views. Having passkeys hosted in BW like TOTP seeds, or perhaps an additional entry type like “Device/Passkey ID” and we can map devices/passkeys to Vault entries.
I don’t know if BW will be able to inject/remove passkeys from a device on-demand, because the big tech wants to definitely push the passkey into a hardware SE (Secure Element) like in (current gen) mobile phones, TPM, and FIDO2/WebAuthn tokens. That’s likely what it would take for BW (or any credential manager) to pull off what you’ve described.
I don’t see them being interested in portable keys (think remove before crossing a border, loading just what you need on that device when you need it) because it breaks their chain of custody and provenance around all of the surveillance they’re collecting for themselves (and all of their valued partners, completely above board, as spelled out in that 200 page EULA and privacy policy fine print you “agreed” to, wink, wink).
I’m on the FIDO Alliance website looking at some of the documentation. It appears you will be able to use a Yubikey instead of Google/Apple/M$. Example: using passkeys on Linux devices. It then outlines that you can effectively ‘sync’ a passkey between devices and between platforms like Goo/App/MS.
While it isn’t explicit, you can see that you “create” (not “allow”) a passkey (FIDO keypair) for each service you sign into. You can then see a “list” of your passkeys. This suggests a unique passkey is associated with each service.
I’m just exploring now so above understanding may change.
You’re asking the right questions.
See this thread for more discussion.
You can test it out at passkeys.io but as the discussion points out, Apple and Google won’t allow passkey storage that isn’t managed by them.
Mindless2112
If you don’t like Google or Apple, use your favorite password manager.
Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.
martin_k 5
Unless the service you are trying to use requires that you use a particular model of authenticator, which the service provider can enforce via attestation.
Android’s implementation of passkeys currently does not support attestation.
https://groups.google.com/a/fidoalliance.org/g/fido-dev/c/nh…
Neither does Apple’s, I believe.
Mindless2112
Good to know! Hopefully this kills off unnecessary use of attestation.
oezi
Isn’t it even worse? Browser vendors don’t even offer any way to not use their baked-in authenticator? With WebAuthn they offered at least the options of using a security key via Bluetooth/NFC/Bluetooth as alternatives to the device authenticator. I don’t see that option with passkeys.
So, there seems no way to use a password manager with passkeys.
Good link above, thanks!
passkeys.dev notes that “passkeys are unique per service.” source: https://passkeys.dev/docs/intro/what-are-passkeys/
Here is a good podcast with some of the developers of the the solution. I have cued it to start at 28 minutes where they confirm that the solution does not permit access to all your sites if your passkey were compromised.
https://overcast.fm/+247w4u9Gs/27:57
They also acknowledge, immediately after that, that allowing passkeys to be transferred to other password managers like Bitwarden is unresolved because of the risk of all your passkeys being swiped in the transition. Currently, the way they are doing it, via the FIDO Alliance demo, is to attest on Windows you have the iOS passkey for the same site, which then allows Windows to serve you the option of creating a new, different passkey in Windows for the same site. You can see how this could work with password managers like Bitwarden. But, it’s not the same as exporting your vault.
Elsewhere, they note that the spec is designed to allow hardware keys like Yubikeys to store passkeys, like https://www.passkeys.io already allows, so they are not locked to Google/Apple/M$ (they acknowledge this is a driving fear), and that they expect that the use of hardware keys in secure environments will actually increase in a passkey world. The spec also has an additional and optional security feature of passkey + locked to device which is designed for enterprise, government, journalists, etc.
I will note that it’s concerning this solution is already live and usable with Google and Apple when the standard to allow players like Bitwarden to integrate isn’t even baked. This speaks to your valid concern that these big players are concerned with their interests and not the interests of their customers. I have confidence it will happen. I think they will just drag the puck so they can gobble up all the marketshare with first mover advantage, leaving the Bitwarden’s of the world to play catch up.
Personally, I will never adopt a solution where I do not own my own keys. For me, ownership includes being able to move my keys (travel) (I could live with “move” being defined as being able to recreate new keys for the same service and then erase original keys created by a vendor like Google/Apple), and store my keys (rest) with the vendor I wish (Bitwarden, Apple, Google, hardware security key, or only myself).
It’s a good episode, above. This is another good episode gleaned from your Hacker News link: https://www.buzzsprout.com/1822302/11122508-passkeys-feat-adam-langley
While I’m not a user of Dashlane I’d like to point out that product already has in-browser support for passkeys. More recently they’ve announced support for passkeys in conjunction with Android 14. FWIW, NordPass has also shipped passkey support.
Meanwhile we’ve still seen nothing concrete from Bitwarden in this area.
It’s on their roadmap, they have acquired passwordless.dev, and they are members of the FIDO Alliance. Thanks for posting the NordPass and Dashlane links. Both are planning mobile support on Android in August 2023 when Google permits it. I suspect all the services will get there at around the same time in slightly different ways. We’re close.
Will today’s Google announcement speed things up?
What are the blockers to implement this right now? Do no browsers/platforms offer APIs to solve webauthn requests through to a password manager? is that it?
How cool is that 
works as expected for my gmail account, but not for my workspace account yet.
For me, passkey support is the feature I anticipate the most from Bitwarden. I wonder what is the status of this? Has the work started, any schedule?
Passkey support is in development
No possible release date? 1Password is already showing a June availability:
Hey Michael, there are many different teams working on Passkey support this year with varying timelines, stay tuned!
Since Google just released Passkeys a lot of people will be looking for alternatives to having Google or Apple hold the passkey. It would be great to use BitWarden to create passkeys and sync them between devices.