I worry passkeys might be the death of Firefox given the current lack of support.
Passkeys will come at a cost
261–270 of 600 posts
Re: Passkeys will come at a cost
#262Earlier quoted context omitted.
> how attestation is handled (and can be trivially abused to kill companies) What's this issue?
Hardware tokens (Yubikeys, etc) are signed by their vendor. They support attestation which allows q site to disallow vendors not in a white list. Some banks (Vanguard was/is one) actually enforce this preventing all but a handful of hardware keys from working with their 2FA.
From https://www.chromium.org/security-keys/:
> Chrome’s users have an interest in ensuring a healthy and interoperable ecosystem of Security Keys. To this end, public websites that restrict the set of allowed Security Keys should do so based on articulable, technical considerations. They should regularly update their set of trusted attestation roots that meet their policies (for example, from the FIDO Metadata Service) to ensure that new Security Keys that meet their requirements will function.
> ...
> If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites. If Chrome becomes aware that manufacturers are not maintaining their attestation metadata we may choose to disable attestation for those devices in order to ensure a healthy ecosystem.
e.g., it is acceptable for a bank or other public-facing site to say "we'll only accept authenticators which have been L2 certified via this independent program that maintains an up-to-date list".
It is not acceptable to say "we'll only accept this one vendor's products, and maybe another vendor after a 2 year audit if we feel a business need".
And Chrome has stated publicly that they will remove some or all of the WebAuthn API from your domain if you do so.
Re: Passkeys will come at a cost
#263Earlier quoted context omitted.
This is a terrible idea though. I had the misfortune of getting into a cycling accident which broke my phone display (completely lost display output and touch input), and it meant I lost access to all my OTP 2FAs for a couple of days (which is actually kind of scary). I was able to fix it myself by getting parts and going through an ifixit guide (right to repair anyone? ;-), after which I promptly exported my 2FA see…
That's indeed scary. Losing your 2nd factor shouldn't block you from accessing your accounts indefinitely . There should at least be one recovery path outside 2FA be it "printed recovery keys", "email recovery", "support channels", or even (despite being fully insecure) SMS maybe with a grace period (like 48 hours). Backing up your 2FA secrets isn't user-friendly at all, and it's even harder after you've started usin…
> Losing your 2nd factor shouldn't block you from accessing your accounts indefinitely.
You’re absolutely right and also you don’t have to worry. Everyone who operate auth of any sort will be forced on day one to have reasonable recovery. Nobody is gonna lock customers out because you lost their super-secret private key.
In practice, it goes back to email recovery for 98% of services. This will remain true with passkeys. Just like people forget passwords today, they’ll lose their passkeys tomorrow.
An average user can keep perhaps 5 decent-entropy passwords in their brain, at most. Thus, they can be useful for master passwords and your bank account. Other than that, it’s an elaborate dance of reusing existing passwords, using low entropy ones for low-value services, and for some of us, systematic usage of pw managers. But it’s still a dance, extra steps. And the UX is fragmented at best.
Passkeys has a chance to greatly improve both security and UX of happy-path auth. That’s not bad at all.
Personally, I’m more worried about spec bloat. It looks like tons of knobs and flags already, imagine where we are in 5 years.
I’m also a little worried about public computers, shared devices, borrowing etc. Not everyone has a personal $1000 phone. This whole “my own device” assumption is a first world bias, and the experts should know better.
Re: Passkeys will come at a cost
#264This is a bit unrelated to the harder crypto stuff but my mom called me freaking out she couldn’t get into her gmail. It turns out Google auto registered her new android phone with a passkey and made that the default Google login with a confusing passkey based interface (expecting her to know to click the second option to login via password or understand wtf a passkey is was too much IMO). It turns out when it said “…
Nit: Passkeys don't get sent to Android. Instead, the Gmail login would ask you to prove you possess the passkey on the Android by scanning a QR code displayed by the browser.
However I totally get your point. The UX is confusing. The terminology is confusing. Even if each step in the UX gives you an explanation of what it does, it's still useless because people are trained to skip the small print with explanation and click the biggest, most colorful button, especially when they are in a hurry. It's a genuinely hard problem for UX design.
Re: Passkeys will come at a cost
#265For context, we run a YC-backed passwordless company, and have rolled passwordless out at major organizations. While I think passkeys will definitely be the answer for consumer passwordless, I'm not sure this is quite reflected in the enterprise yet. Passkeys are wonderful for consumer use, because they're meant to enable your own ability to break glass, by backing up the credential to other devices. You can do this…
>Passkeys are wonderful for consumer use, because they're meant to enable your own ability to break glass, by backing up the credential to other devices. You can do this via iCloud (by default) or via things like Airdrop.
> Technically, the devices you share this credential to, cannot provide "attestation" - attestation is the "proof" that the keypair was created by a specific device (like a Yubikey, Apple Machine, etc). Manufacturers (like Yubico) ship a keypair / certificate onboard your key, that can't be extracted. There are no external methods to interface with this keypair - granting admins high confidence this is a real Yubikey.
Passkey is not a technical term, but an experience term. So it somewhat falls apart when you use it for technical arguments.
Apple supports passkeys. Android and Chrome support passkeys. Microsoft supports passkeys. Yubikeys supports passkeys.
But the authentication process for user verification and the capabilities/restrictions around things like cloneability may differ wildly.
A government agency may choose to support passkeys, but only when provided by a FIPS-certified authenticator which meets AAL2 requirements. Those won't come from Apple or Google, at least not today.
An enterprise may choose to support passkeys that are generated via software/configuration provided by their MDM management product. Apple announced beta support for this.
However, if you are doing government-to-citizen you may experience a lot of pain trying to mandate those particular hardware authenticators. It will be painful to convince citizens to spend $80+ USD on hardware. It will also be painful because web technologies are built around user choice, and WebAuthn API and user experience are unlikely to ever be optimized to help restrict user choice.
Re: Passkeys will come at a cost
#266Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. IMO physical security keys are better left…
Password managers have already made passwords obsolete. I literally don't know any of my passwords except my master one. Passkeys are an insanely overcomplicated solution we don't really need. Browsers just need a simple HATEOAS API for password managers to hook into, and web apps expose some HTML that triggers the browser. The password manager can then determine how to authenticate the user (however the user wants!)…
BTW, Apple have announced a Chrome extension for iCloud passwords.
https://chrome.google.com/webstore/detail/icloud-passwords/p...
Re: Passkeys will come at a cost
#267This is finally a great article demystifying non-resident keys! I got a FIDO yubikey a few months back, it came with no PIN set up, I was surprised that I could just use it like that, websites were not asking me to set it up explicitly.
I set it up via CLI. Then all websites started asking for the pin and storing the keys inside (resident keys).
Knowing that you only have limited slots, I tried deleting the pin by resetting yubikey to revert back to old behavior as there was no way of zeroizing the pin any other way (for the sake experimenting with the tech and understanding key management better, ofc pin or BIO auth is better).
And then suddenly found that I was unable to use the key to auth into my accounts I set up before. In hindsight now I know by resetting the hardware key I have reset the master key inside.
There really isn’t much well written introductions into how all of this works. Thank you for doing a great job demystifying the flow here!
Re: Passkeys will come at a cost
#268I'm not a security or crypto guy at all. I found this very difficult to follow, and I suspect others might too. My questions probably seem weird to someone with enough background context to understand the post, but I am getting wrapped around the axle every sentence or two. > It all comes down to one thing - resident keys. How/why? What's the connection to passkeys or HSMs? > we need to understand what a discoverable…
I believe the primary point is that WebAuthn is being pushed to use a "passkey" model where each site creates a credential that consumes storage. Displayable site and user account names, a user record handle, and the private key all take up storage, along with a few other items.
A mobile phone could store 10 thousand passkeys without breaking a sweat. Modern hardware keys might only be able to store 25 total in available flash.
The reason for wanting this storage is discoverability - the ability to hit say GitHub.com's new passkey support on the login page, and log in without having to even type in an account name. The browser provides a password manager-like experience. Just like passwords in a password manager, the passkey locally becomes a record of an account on a site.
However, WebAuthn also has quite a few other, non-passkey modes. Non-discoverable credentials expect you to provide a list of handles for a particular user account, which were provided by the keys as part of registration. Only credentials which match a handle are given as options during authentication. For hardware security keys, they leverage this to actually store the record needed for the future cryptography in the handle itself - this mode doesn't take up flash storage.
So the user would type their username, some API returns a list of handles, and this could be used against a security key to authenticate - without no storage limitations.
The problem with this argument IMHO is that a lot of sites take a policy of not revealing if an account exists or not. We've seen recovery processes that say "if this account exists, you should receive an email shortly". A login process that provides an API to detect if a username or email address has an associated account and how many credentials have been recorded against it may simply not be acceptable to the site.
It seems more likely that we eventually have security keys with 10x the available storage, rather than sites adopting this process widely enough to make an impact against the current hardware limits.
Re: Passkeys will come at a cost
#269Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them. IMO physical security keys are better left…
> Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them.
Hardware security keys that implement FIDO2 UAF can be protected by PINs/passwords or biometrics, the former being "something you know", and the latter "something you are", with the security key itself being "something you have".
Re: Passkeys will come at a cost
#270Earlier quoted context omitted.
Yes, that’s resident (or “discoverable”) keys the article author is talking about. You don’t have to do it this way. I configured my Yubikeys to be the second factor and not to use resident keys. It’s possible, although I don’t know if Microsoft allows users to roll back from “passwordless” and discoverable keys. I want to state it explicitly: FIDO as technology allows either. It’s particular platform choice to go wi…
> Yes, that’s resident (or “discoverable”) keys the article author is talking about. No, I said I'm using a Yubico Security Key. This is not a Yubikey. This key has no storage. How can it possibly store resident keys? The YubiKey Manager app can't even connect to this key. It's very basic, it has no TOTP slots, it has no configuration, it only does FIDO2. How would resident keys get in there in the first place? The a…
Sorry, but Yubico Security Keys support up to 25 resident keys (https://support.yubico.com/hc/en-us/articles/360013647720-Se...)