Bitwarden developer survey: Secrets, security and the future of passkeys
bitwarden.com
bitwarden.com
They certainly didn’t ask the HN crowd. I wonder who they surveyed.
Are they conflating fido2 hardware tokens with “google owns your credentials, and you can’t back them up” passkeys?
Edit: authentication -> attestation
> At least none of the existing implementations do.
So why isn't that in the spec?
Unless something has changed in the past month or so, the only reason why attestation for roaming keys is less of an issue is because Apple has voluntarily completely of its own volition decided to zero out information in its implementation. That's turned out not to be enough; it's trivial to find accounts online of people complaining that they've tried to register passkeys from alternate providers and have found out that websites are checking browser agents or using other measures to restrict which keys can be registered.
But ignoring that and only focusing on actual attestation using the mechanisms that FIDO has built into WebAuthn, why is an Open standard relying on Apple's goodwill for such an important decision? Why do we have a standard that specifies how to lock down devices through hardware attestation and that relies on providers optionally choosing to do the right thing and ignore that mechanism, but that thinks it would be overreaching for the Alliance to mandate ecosystem transfer or to block discrimination against providers/authenticators?
I knew this was going to happen but I thought they'd wait until there was more broad adoption before the screws started turning.
Passkeys are an open standard, not a Google SSO service. You can use it with Apple devices (where passkeys shipped well before they did on Google devices), 1Password, etc. without having a Google account at all.
The concern around backups is partially true (backups are possible, exchange between implementations is in progress) and I think that’s where the confusion is coming from: the whole point of passkeys is that your private key can’t easily be stolen and the first implementations did that only within specific services with known characteristics - for example, Apple’s iCloud Keychain robustly backs up the keys (even against complete loss of all devices) but only in that service, which is understandable given their audience and the exposure. All of the major vendors have committed to interoperable private key exchange as things mature and we’re already seeing that with e.g. 1Password and iCloud Keychain allowing you to share keys with other people.
This ignores the practical reality of every single implementation of Passkeys today. The fact is, call them Open all you want, the implementations are almost entirely proprietary. The official dev site says they don't work on Linux (https://passkeys.dev/device-support/) and in fact doesn't even list Linux as a target (only Ubuntu), and doesn't even list plans to support providers on Linux. Numerous people have said that exchange between implementations is in progress, but there's basically zero information about it (the spec process and design of exchange seems to be happening behind closed doors as far as I can tell, or at the very least I don't know where to search to find the meeting notes), and there's no timeline at all about when it will be supported, and in the meantime no major passkey provider from any ecosystem supports transfer.
But that hasn't stopped any of the major providers from launching passkeys to the general public and advocating that people start using them today.
So forgive me for being doubtful that the industry actually cares, because they clearly didn't care enough about this stuff for it to be a blocker in front of asking people today to commit to ecosystems that have zero transfer systems in place if anyone needs them. Vendor lock-in is not a theoretical future concern; every passkey system being advertised to users today is currently vendor lock-in. We are past the point of lock-in being a future concern, today passkeys as they are presented to most users are almost entirely walled gardens and the only silver lining is that we have vague promises that the existing problems that make passkeys user-hostile right now might be fixed in the future.
But that's apparently OK because ordinary users who can't be taught not to reuse passwords will just remember to make multiple keys across ecosystems for every website, and them needing to do that is apparently fine and nobody should complain about it or point out that it's not a reasonable thing to ask nontechnical users who can't wrap their heads around 2FA codes to do. /s
And I don't know, I don't think that people get to use "when the ecosystem matures" when Apple is telling its users to start using the ecosystem today. The ecosystem is mature, the industry has decided the ecosystem is mature enough to launch. The features that are still not implemented are features that the industry has decided were not essential parts of the standard. The industry and FIDO Alliance did not care enough to implement those features before launching passkeys and advertising them to regular users.
----
So passkeys are an industry standard, but I am increasingly doubtful that they are an Open standard in any of the ways that actually matter. Just because the docs are public, that doesn't change the fact that the major implementations are effectively closed silos today. I don't know if I'm being greedy or if I'm spoiled by web standards processes, but I would expect an Open standard to have Open reference implementations that work on every single OS. I think it's weird to have a bunch of proprietary implementations and a spec for providers that is theoretically possible to implement on Linux but matters so little to the FIDO Alliance that the official dev site doesn't even list Linux as a target. Imagine if Matrix didn't have an Open client or server reference implementation. Imagine if that entire process was happening behind closed doors and the only way to get news about what the Matrix devs were working on was to ask on Reddit or Mastodon or Twitter.
Would we call that an Open process?
----
> All of the major vendors have committed to interoperable private key exchange as things mature and we’re already seeing that with e.g. 1Password and iCloud Keychain allowing you to share keys with other people.
Genuinely, not as a joke or a gotcha but as a real request, I would love to see actual documentation about this, because maybe I'm bad at looking but I've gone through the official passkey sites and I search online about this regularly and I can't find official confirmation of this from most of the major vendors. Arguably Apple seems to have committed? But it's tricky to actually determine that because I'm never sure if they're talking about cross-device access or if they're actually talking about transfer.
I would love to see a section on the actual passkey.dev website committing to key exchange, that would make my day. I would love to see confirmation not on Twitter or a blog that companies are committed to this as more than a "nice to have whenever we get to it, but in the meantime just start using them, what's the problem." I would love to be wrong about this, please show me an official document from the FIDO Alliance itself saying that key exchange is going to be part of the standard and is going to be a required part of certification and giving even a semblance of a timeline about when it's going to exist.
1Password constantly gets brought up as evidence that interoperability and lock-in isn't going to be a problem, but 1Password does not support transfer between ecosystems and while they have said on Reddit that they are interested in avoiding vendor lock-in, I can't find official confirmation of that on the site and there is no timeline or details about how that's going to work. And again "it isn't going to be a problem" doesn't cut it anymore, people are recommending that users start adopting passkeys. It is a problem now. When a system gets launched and recommended to regular users and that system is missing critical infrastructure, that's not a future problem anymore; now it's a current problem.
> Are they conflating fido2 hardware tokens with “google owns your credentials, and you can’t back them up” passkeys?
Not sure why you say this, but perhaps you are conflating device-bound credentials (which aren't supposed to be moved between devices): https://passkeys.dev/docs/reference/terms/#device-bound-pass...
Here’s the “most popular” article according to a HN search for passkeys:
It even provides recommendations to work around this problem.
(Emphasis mine)
The thread is discussing the general sentiment on HN regarding passkeys (based on previous discussions), not the sentiment of the linked article.
I want bitwarden, or whatever password manager, to be the (cross-platform) provider, not the OS. It's coming, maybe/hopefully?
That this is not a required part of the spec and that it's possible for a website to go through certification and get an official endorsement of support without supporting multiple keys per-account is a complete failure of the FIDO Alliance.
One of the big issues with how passkeys are being developed is the painful naivety of the FIDO Alliance about actually standardizing good behavior.
Every response is, "but why would providers do X bad thing?" If we're expecting every provider to allow multiple keys, then require it in the spec. Otherwise, if it's important that the spec not mandate that, then don't tell me that every provider is going to allow multiple keys, because apparently there's use-case for only allowing a single key and we're expecting the spec to need to accommodate that behavior.
----
> I have my phone (Android), my laptop (Windows Hello) andnmy primary and backup Yubikeys enrolled. I'm not restricted to a specific platform.
That people are seriously suggesting this as a solution to cross-ecosystem recovery and backup makes me skeptical of the potential of passkeys to ever be simpler or more straightforward than passwords are. Normal users can't be taught not to reuse passwords, they can't be taught to do 2FA, and you think they're going to proactively enroll multiple keys in every website they sign up to?
That's not going to happen; what will happen is they're going to lose their Android phone and they won't be able to do cross-device authentication without it, and they won't have proactively done cross-device authentication on their Windows machine, and the only way to get access to those keys will be to buy another Android phone. "Register multiple devices ahead of time" is only a solution if you expect passkey usage to be restricted to niche technical groups.
https://files.catbox.moe/eowjba.png
I also have my Microsoft account enrolled as a Passkey, and Bitwarden is enrolled using WebAuthn.
There's precedent for only supporting certain walled gardens, too: Google MFA sign-in supports Yubikeys et al. only if used in Chrome; in Firefox for example you get the prompt and everything, it just stubbornly refuses to accept it on touch.
Ok you made me look because I was sure I had been doing this every morning; Myth busted - Logged in to Google using a Yubikey via Firefox (Windows 11) no problems at all.
You don't like that people will use the tool that's most convenient to them? I'm not sure I understand your argument.
Right now pretty much all people except us geeks either:
- Re-use the same password everywhere; or
- Use their OS's password manager; or
- Use their browser's password manager.
How is this any worse?
But! I would rather you take your time and do it well, than rush it.
Just looking forward to what you'll bring to the table with Passkeys.
I've also been waiting with bated breath; I simply won't adopt passkeys until I can use a cross platform tool that doesn't try to lock me into a single vendor's hardware or software. But once that's available, I'd be very happy to switch certain accounts to passkeys. It doesn't matter all that much to me since I use unique, long passphrases generated by bitwarden for every account + OTP when I can, but I would slightly prefer a passkey to a password since it's one less thing an auth provider can screw up.
1. You prove you have control of a key without telling the service the content of the key (like SSH keys, and any other PK setup) so: you cannot lose your password. The private part probably never leaves your device (probably - if you use Apple or Google's implementation there's magic/low security sync, you might also manually backup the private keys to a file)
2. A new keypair is generated per service. Don't reuse your password is baked in the spec, and by using individual keypairs the service can't profile you by the public key (privacy).
3. And possibly the most important. WebAuthn (of which Passkey is a popular marketing term) includes the asking identity during the registration/signup and login/proof stages, it doesn't rely on the user inspecting the url/webpage look/auth domain. Ie. You cannot be phished by examp1e.com when connecting to example.com (much like SSH's TOFU, but sorely missing from most web interactions).
So if you're a competent password manager user, only 1) matters. Passkeys really do seem like a bigger deal to your average user, since 2) and 3) implicitly incorporate password best practices.
Being able to authenticate a device and log in without ever transferring your authentication credentials to that device is cool. That enables some security setups that would otherwise be very difficult to build.
Some of the benefits are oversold (the privacy benefits seem overblown, there is nothing about passkeys that guarantees that your accounts won't still require email addresses, and there's nothing about passwords that forces sites to ask for email addresses, so nothing on that front is likely to change) -- but in general, the core idea is wonderful and passkeys would be a massive improvement over passwords if they were implemented well.
The problem is the implementation and the development process for the spec.
- Weak passwords
- Phishing
Passkeys are intended to protect the tech-incompetent masses against trivial attacks. They provide zero or negative value to the HN crowd who's already using a password manager and 2FA.
I suspected as much. Thanks for saying so, maybe I'm not that out of touch yet.