The title was correct but they appear to have changed the policy since the post was made, likely as a response to feedback.
Notice that in the archive from earlier today the "Who is excluded from this account email-based new device verification?" section did not have the new fifth bullet point about being able to opt-out:
Thought it was worth pointing this out since I've already seen people reply to old comments thinking people didn't read the article without realizing it was later changed.
Very unfortunate and caused me to cancel my subscription immediately. Any alternatives that people can recommend to someone who throughly enjoyed Kagi?
FWIW using WebAuthn to start a session, set up a cookie, and validating that cookie to get access seems like a pretty usable pattern. Not much more invasive than the "checking your connection" screen Cloudflare likes to throw.
You can use any passkey provider app. I work at Bitwarden and we’re building mobile passkeys for android right now. We can do the e2e sync, but if you want you can always self host Bitwarden server and just use our clients app.
The BitWarden passkey dialog irks me because it makes me click the passkey I want, even if I have exactly one. It would be better to have a feature where I could specify "always use this passkey and don't prompt", since that's what I need 99% of the time.
This has been annoying me as well: WebAuthN even provides metadata that lets authenticators know which credentials they're willing to accept, so at least in that case (usually the flows where you have to enter a username), auto-selection should be possible.
With discoverable credentials (which Passkeys by definition are), i.e. the flows where you don't even enter a username and the website learns it from the selected passkey, I don't think there's a way around a key selection process, but the UI can definitely be improved to distinguish the two.
Maybe something like "website XYZ is trying to verify your account 'username' – is that ok?" vs. "website XYZ wants to authenticate you – which passkey do you want to present to them (if any)"?
I'm already seeing Bitwarden as an option for Passkey authentication on iOS! Apparently the app already exposes itself to iOS as a WebAuthN backend (or the API is the same as that used for password managers).
Unfortunately that API doesn't seem to be wired to anything in the app yet, so selecting it inevitably fails.
You make a valid point about “non-resident” WebAuthn 2FA being great 2FA. However, passkeys are also great, and they depend on your context…. Most people are in the passkey context.
For people who are not knee-deep I think we can explain it a bit better, why passkeys replaces passwords:
With non-resident (2FA keys) you need to identify your account first. Since you don’t want to have account enumeration, this means doing a primary authentication, e.g. passwords.
With passkeys, the website can just ask your browser) to sign in with any of the accounts it has passkeys for; which result in a one click sign in.
While hardware backed Security Keys for 2FA is great 2FA, there’s a tangible cost, both in UX and $ that leaves many users left out (not everyone can afford $20 for a security key)
Source: I work at Bitwarden building our Passkey API for developers. We support both 2FA and passkeys, both in the API service and in our password manager. Feel free to ask my anything related.
You don't need a password to prevent account enumeration; you can send people who choose a nonexistent account a bogus credential that the token won't accept.
You have to display the password prompt for invalid accounts to avoid enumeration without webauthn too...
> Since you don’t want to have account enumeration, this means doing a primary authentication, e.g. passwords.
Nothing prevents site from sending a blob of random data when real key is not found.
> While hardware backed Security Keys for 2FA is great 2FA, there’s a tangible cost, both in UX and $ that leaves many users left out (not everyone can afford $20 for a security key)
Both major desktop operating systems come with WebAuthn support - Windows via Windows Hello and macOS with Secure Enclave backed key store. That not a problem at all in corp environment. Buying a Yubikey (or two) for each employee in the company is minimal cost comparing to laptop, desk, chair, software licenses
We use WebAuthn as the first factor, and we love it because it completely eliminated password brute force problem. Password attacks (brute force and stuffing) is a much bigger problem, than account enumeration, especially in corp environments where usernames follow a name-based pattern and everybody is on LinkedIn.
BTW, we are paid Bitwarden customer, and our Helpdesk was not too happy when Bitwarden update resulted unexpected prompt interrupting WebAuthn authentication flow for users. )
A bit of a tangent but do you have a view on prices for hardware security keys like YubiKey? For private use they're a pricey option, especially if you get a few backup keys. Could a big actor like Google, if they wanted, scale up production, sell at cost and get prices down to say $2 each? Or is the components and manufacturing inherently more costly? Is there anything on the horizon that likely will bring much lower prices?
This is why they're pushing passkeys in phones' secure element with cloud account sync: getting people to keep a separate set of hardware keys is nigh impossible at scale.
Sure, but why not preserve the option for people to use hardware keys?
Unfortunately, both the FIDO and WebAuthN working groups seem to be dead-set on making the hardware authenticator use case as painful as possible [1] [2] [3].
I just don't get it. Why even try to pretend that WebAuthN is a single API for both use cases when all stakeholders in charge seem to have given up on one of them?
Most modern smartphones support contactless smartcards (a.k.a. "NFC"), which can be used as FIDO credentials. It should be possible to produce these for around $2 at scale.
They wouldn't work at computers, unfortunately (not even with an adapter, since desktop browsers and OSes don't expect to speak FIDO-over-ISO-7816-over-CTAP-over-USB), but with QR-based cross-platform flows now part of the specs, phones could pretty straightforwardly serve as readers for other devices.
If large issuers of ISO-based smart cards (e.g. banks or government authorities for biometric ID cards and passports) could be convinced to just throw a FIDO implementation on there (there's open-source ones available!), people could even use the cards they already own.
Yubikey used to sell a simple Webauthn-only key for $10-$15. USB-only, no NFC or anything. It was blue instead of the standard black. That one was essentially killed when Passkeys became popular, because it didn't support resident keys. I believe some companies (Google? Github?) were giving them away for free.
Its replacement is $25, which is expensive enough to be an issue for poor people.
Thanks, I'll look into that product. Less costly, but still far from the $2 scenario. If hardware keys got to a super low price point, or even handed out for free or bundled with new phones or PCs, I image lots of people would prefer them over passkeys.
I am a yubikey user, but they are a terrible option for a normal person. Losing a hardware key means being locked out from all your accounts for real, and if cryptography taught me one thing it's that people are not responsible enough to manage their own keys (keep a backup key up to date, print recovery codes, etc)
I'm not trying to do callout posts or anything here, I know that the people involved are genuinely trying to do their best. I'm grateful that Bitwarden is involved with passkeys. But, for all of that gratitude, I still have to say: Bitwarden got a huge amount of attention for being the Open Source implementation of this, and Bitwarden and 1Password were both used as examples that shut down criticisms about portability, and lack of communication and clarity is a big part of how Bitwarden/1Password got used to spread what I would genuinely consider to be misinformation about the current state of the passkey ecosystem.
It's not just that export wasn't supported, it's that this giant limitation that was in many ways the reason why people were so excited about Open implementations in the first place was quietly left unsaid.
I really genuinely do appreciate the work everyone is doing. But at no point when Bitwarden was writing posts and releases about passkey support did anyone writing that stuff think, "people will think this means export is supported, we should clarify that."?
It's so hard not to look at this communication and not feel that these kinds of details were deliberately omitted. I'm sure they weren't! I know that my emotions are incorrect and that everyone involved means the best. But crud, that is how it feels.
How many people who got excited about Bitwarden's implementation even know that they still can't export and import their passkeys? Maybe that'll be a fun surprise for them next time they try to do an import into a new account. Bitwarden's announcements didn't mention this limitation, and as a result no press coverage of Bitwarden mentioned this, and any casual observer who didn't know to go read the documentation and deliberately ask about it would come away from this coverage thinking that export was supported -- and in fact I would argue people did. People think the portability problem is solved because Bitwarden and 1Password exist.
Needing to double-check this kind of stuff, not having transparency or open conversations about any of it is part of the regular frustration of trying to learn about the passkey ecosystem. Very often when I talk to people in industry about passkeys, I will get answers that really sound like they are addressing people's concerns. And then you dig into them, and... they don't. But that's never communicated unless you do the research. So much of the advocacy is saying stuff that is technically true, but has huge unmentioned caveats or that doesn't actually when you dig into it address the concerns that people have or is using some weird definition that isn't what most people would use.
"Passkeys are portable now!"
"So I can export them?"
"Well, that depends on what your definition of portable is."
Bitwarden never technically said that it supported export, but I'm going to go out on a limb and say that a lot of casual observers reading about portability and sync and OS-independence think that Bitwarden does support export, and Bitwarden really isn't going out of its way to avoid that impression. I mean, props for having it in the user docs, that is better than 1Password. +1 for Open Source being more transparent than proprietary software, genuinely I appreciate it. But the only reason I know that Bitwarden doesn't currently support export... is because I knew that I couldn't assume it and I knew that I needed to check the docs. It's not something that's communicated in the announcement, it's not something that's communicated in the FAQ, it's not something that's communicated in any press coverage, it's not something that's communicated unless you know what to Google search.
I'm excited and eager for more of the actual work to be public and open, but I also kind of have to frank about how low the bar is right now. Nothing is communicated. It is work even just to find out what is and isn't supported right now. Would you argue that Bitwarden's current FAQ on passkeys (https://bitwarden.com/resources/passkeys-faq/) communicates the difference between in-ecosystem sync and cross-ecosystem sync clearly enough that an ordinary user would understand the difference?
----
> The best place to argue this “in the open” is by raising issues in the w3c/webauthn repo, or meetings, which is open.
What am I missing here? I apologize if there's some thread that I just haven't been able to find, but... if this is an open process, where is the conversation happening? I don't want to be a jerk about this; should I be showing up at w3c meetings and complaining about other meetings that aren't happening there? That doesn't seem helpful to anyone, I don't see how that would be productive. But if this is genuinely happening as part of the w3c/webauthn space, then where in that space are the conversations about portability and export? What issues should I be following?
Is the problem that nobody has raised an issue in that space? Because that's a very weird thing if true; I've been told for nearly a year that work is ongoing on migration/export. In all that time, none of that conversation ended up on the webauthn repo, the ostensibly official place for the spec to be discussed?
This just feels like a dismissal; if the webauthn repository is where these conversation should be happening, then why aren't they happening there? This isn't Bitwarden's fault, I'm speaking broadly to anyone involved in this process -- this is a multi-company process that has been happening for months and months and months and I would love to know where those industry-spanning conversations actually exist, so that I can stay up to date on what's going on without needing to search for crumbs of developer updates on Reddit, Mastodon, and Twitter.
Main difference is:
- Escalation level management is super easy: drag & drop. No cumbersome management.
- All Quiet tries to empower teams trying to strengthen thier self-organization. I believe that great teams have an inert motivation to take responsibilit yon their software.
- All Quiet focuses on an App Only notification approach by design
reply