It's simple for users. No need to remember passwords anymore, no typing 6 digits numbers from your phone that you need to search in your house before tokens expire.
This comes with (some) additional complexity for implementing more complex auth flows for developers.
If you think that passwords are working "well enough" today you are clearly not educated on how most users (mis)use them. If you built a site and tried out the passwords people send to you on the logins for providers of the email addresses they send to you, there'd be a large fraction of people reusing their email account password for your service, allowing you to access their email.
The only real problem with passwords is that humans are extremely bad at those without an aid of a password manager (when they’re no longer words but turn into pre-shared tokens). There are more, of course, but not as important.
So people invented OpenID and OAuth and stuff, but all those things are fundamentally flawed because users were no longer a source of their “own” identifies. Their identities became provided by third parties - and this is notoriously bad.
WebAuthn (and FIDO stuff) is not centralized, on the contrary - users still own their credentials and are sources of their identities (though there are optional attestations). It doesn’t require cryptography knowledge to use it, but it does to implement it - thus the certification (though anyone can surely do it without certifying for anything).
>The only real problem with passwords is that humans are extremely bad at those without an aid of a password manager (when they’re no longer words but turn into pre-shared tokens)
Human are also bad at not losing/breaking their magical security totem. I need to know that I can easily backup codes to any of these hardware tokens for if/when one is lost. Ultimate security be damned.
It is implicitly centralized if the user doesn't have a means to control the secret key themselves. The minimally need to be able to import new keys into a device to keep control. Otherwise whoever owns those keys is really the one in control, which is really what the higher FIDO levels are about (as they are targeting enterprise customers that want central control).
L1 (software based) obviously fits this requirement. I think L2 also can because while it is a physical key it could allow for the user to import their own secret. L3 takes that away as it must come from the manufacture with a key that cannot be accessed. Not 100% on any of this, but it's what I get from their level doc... https://fidoalliance.org/certification/authenticator-certifi...
That's the trade-off between security for the masses and savvy individuals having more control. A person can't get phished for their credentials if they can't access the private key. Journalists have emailed their GPG private key when learning how to use it. Even TOTP can be beat with fake webpages or a social engineer who asks for the code.
I've had so many of my non-tech relatives get hacked. Folks who don't live/breath/shit tech just kind of suck at p/w management. This is a huge improvement for them.
BUT, I absolutely think we should continue to demand the right to interact with services on our own terms: Even accepting the compromise of "less security" (debatable if you know what you're doing).
I think the only way forward is a Free/Libre implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want. Even a fully-software one.
> implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want
At least as I understand it, in implementations like yubikey the FIDO2 secret is baked-in to the yubikey for security, which is good as it shouldn't be possible to remove the private key.
However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, which would be useful as you wouldnt need to enrol multiple secrets with each service.
> However the main issue I have is that the user cannot import their own secret into the yubikey
Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?
Secrets are easy to securely generate and it would allow importing, not exporting. If you allow importing then the user can generate the secret, store it somewhere safe and import it into the device. Then if they lose that device they can just write the saved secret to a new key.
Various strategies that trade off security vs. convenience. Most secure is probably something simple like printing it out and putting that in a fire-proof safe. But there are lots of options. For the non-tech parents or some such, a nice pass-phrase would probably work well as the secret.
How do you get this pass-phrase from paper onto the yubikey without an adversary getting hold of it?
I'm not trying to be pedantic here, I'm just failing to see how this can be realistically implemented without significantly lowing the overall security. But this is also not my domain, so I'd like to learn.
Importing keys into an HSM/key storage device is not an uncommon exercise.
If you're asking about the structure of the bits you'd need to move into the device in a verifiable way, there are standard APIs like PKCS #11 for interacting with HSMs.
You would then need a computer and a PKCS #11 client application. If you don't have a computer you can trust to pass keyboard inputs to a USB port without being intercepted, you've got problems that a yubikey will not solve.
It is possible under FIDO L1 certification, but Yubikey and most other players are focusing on L2 and L3 certification as that will be what enterprise customers want.
Wait: what about these higher certification? Is there going to be some kind of "master key", controlled by the FIDO alliance (?), that would somehow sign the keys produced by "complying" company X or Y? Making it impossible to come with a software implementation allowing to users to backup their keys? Or are you saying that a software implementation would be totally doable but just wouldn't be officially certified?
Unfortunately the easiest way to "export" is likely to rely on the RP, as if they effectively use the sign_counter they may flag such a key as cloned. They should ideally just let you register multiple (and that's an RFC 'SHOULD').
Not a shill by the way, just a happy solokey owner.
The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk."
In my experience, solutions balanced on this type of ratio always fail to solve the fundamental problem. Which is why we have to have commercials that tell people "medicare will _never_ call you. If anyone calls and says they're from medicare, hang up immediately!" So, I'm assuming we can now look forward to "no one will ever call and ask for information from your key, if they do, hang up!"
> The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk."
Eh, my non-tech savvy friends/relatives find themselves guessing at and then finally resetting their password surprisingly frequently. There's some room for "reward" there.
I guess it's possible that particularly vulnerable people might be persuaded to physically send the actual device to bad guys. I'd like to hope that existing advice to such people warns them not to send stuff to bad guys, we don't want them sending their credit cards, house keys, etc. to bad guys either.
Mailing keys away would only be economical for targeted attacks. Trojans are more scalable. Even that is a big improvement as malware distribution is harder than credential stuffing, email hijacking, or SIM swap attacks.
As long as it sticks with FIDO2 Authenticator L1, it doesn't require centralization of the auth information like levels L2 and L3 do. L1 is what you use if you want control. L2 and L3 are for companies who want tighter, centralized control. Like a FIDO key tied to your Okta account. Though I've yet to see the Levels discussed much nor have I seen any L1 software implementations used in the wild. Everyone seems focused on FIDO L2 and higher, presumably with a focus on getting enterprise adoption first as enterprises do want a central authority.
What's there to explain? We're presumably not teaching your parents to actually implement this for a web site (although I did it in a weekend once to learn) just to use it. Do your ageing parents still have car keys? House keys at least? The physical Security Keys are probably easiest to grok for older people, because of that familiarity.
Or apple's iCloud (see their passkey thing also currently on the front page)
EDIT: Yes you don't need to use a syncing service. But it will be important for it to be portable between syncing services, as that is what most consumers will be using.
> This means keys need to be transported between devices
Pure keys are on tokens that support Bluetooth/NFC/USB to talk to whatever devices you want. One can use a built in key on a device with a security enclave which means using one device to auth addition of another, but you might do that with alerts to authorize, etc.
Anyone who doesn't have a powned problem is using something like TOTP auth codes which has all of the downside of Fido and none of the convenience.
The problem with the FIDO "alliance" is who runs it, which is corporate America and megabanks if you check the site. They are basically trying to be the arbiters of online identity, gaining more power than they already have. Many of these companies are also in surveillance tech. That it may or may not be more secure than existing practices is merely a side effect. Don't be fooled by the term "alliance" because you are not part of the club.
They're just trying to replace the current system of password reset calls, SMS two factor, credential stuffing, password database breaches, and a general wild wild west feeling on the Internet.
Of course it'll take more than public key authentication itself. For example in a enterprise businesses employees aren't allowed to install software, and there are procedures (however bad) to vet individuals.
What is really great with FIDO is that, if you're using a proper device the device also tells the user that he's authenticating to a site he previously registered on. So the user cannot be tricked into registering his key to, say, g00gle (with two zeroes) when he thinks he's actually authenticating with an already onboarded key.
A friend has got a U2F device (forgot its name) which has six buttons that serves to enter a PIN and the PIN to authenticate and the PIN to register are different ones.
Or the Ledger Nano S hardware wallet (and probably the X too) have a U2F app (so the "older" standard only atm) but there it's even better: the device not only tells you if you're registering the key for the first time or authenticating but it also displays the name of the site you're authenticating to.
This is one notch above many other authenticating methods: it doesn't just protect the server versus malicious users, it also protects honest users logging into malicious servers/websites.
Yes, fido2 defeats allot of the attack vectors for phishing attacks and is great.
While physical devices probably will mostly be used for enterprises and us nerds, “platform Authenticators (e.g passkeys) offer much of the same security without the physical device
>FIDO requires an attestation private key, which must be shared between a batch of at least 100,000 security keys. Using a DIY or cli app solution (application running on the host) will likely mean you'll be generating that private key yourself, this makes you identifiable across registrations.
>Some sites (Cloudflare) may reject the use of attestation keys which are not found on the Fido Alliance Metadata Service. This precludes the use of any DIY solution.
Attestation is an option in the FIDO ecosystem, and it is up to each website whether or not attestation is needed. Attestation is often required in enterprise settings. While consumer adoption of WebAuthn is incredibly low, the introduction of passkeys and multi-device credentials looks poised to change that.
For consumer scenarios, attestation is often not a requirement. In that case, FIDO offers the "none" and "self" attestation modes. None conveys no attestation. Self attestation involves a per-website key pair. Either of these modes are privacy and DIY friendly.
Why are you so negative about this? It works pretty well as an authentication mechanism. Unlike passwords, it can't be leaked or phished.
As for Cloudflare use, it's an experimental hack. An option to avoid filling in a CAPTCHA in case you have a compatible hardware key. You don't have to have one, and you don't have to use it for this if you don't want to.
Please note that verifying Metadata is optional for a RP (site owner) and very few sites need it. Without metadata information the privacy is improved.
Disclosure: We built an open source library and an API that makes it easy to add WebAuthn/Fido to your existing web app. It’s available at for those who want to take a look. https://www.passwordless.dev/
There is also a more configurable demo page for the library where you can turn metadata on/off (the api is default off)
In Firefox you can, and I do, tell the browser to refuse Attestation. There's a prompt during the enrolment process.
There's no reason why you should provide Attestation for the Web generally. It could make sense (though I'd argue it does not) for some specialised applications but generally it's probably a waste of your time (collating the necessary data to make it work) and your users time (now some stuff they want doesn't work and needs explicit authorisation).
Chrome also allows you to say no to Attestation requests.
The only place I've seen a 'legitimate' use for requesting an attestation cert is to ensure that only specialized FIPS hardware is allowed to be registered when that is a business obligation.
> ... will likely mean you'll be generating that private key yourself, this makes you identifiable across registrations.
DIY/CLI apps have no reason to include a legitimate attestation - attestations are used to convey trust in the implementation, such as 'This is a Yubikey 5i'. The public key is usable to look up additional metadata, such as passing conformance and security implementation tests.
>Some sites (Cloudflare) may reject the use of attestation keys which are not found on the Fido Alliance Metadata Service. This precludes the use of any DIY solution.
The feature is meant for higher security environments (say workforce and government employee/contractor) to reject a home-grown implementation.
Cloudflare's (beta experiment) usage is a special case because they are using attestations to show that it is real hardware with a real financial cost. They are experimenting with using that as a replacement for captcha entering (while also experimenting with other technologies like privacypass to limit the number of times they ask for captchas).
The alternative to attestations in both of these use cases is that FIDO is not acceptable at all, not that a DIY implementation would become accepted.
Apple, Microsoft and Google together to improve how you login to sites without password. And they will store your "secret" so that you don't need to type it. And you'll be able to recover from any device that is already authenticated.
At the same time, every week we see a "Tell HN: how I lost all access to my email/site/account because of {reason}", where {reason} is some stupid thing that the AI flagged.
Seems that we'll able to lose access to the whole digital world if just one company makes some mistake. Yes, they will.
Unlike username/password you can register as many FIDO devices as you like in each service so if you lose one (because Apple disabled your Apple ID or whatever) you can still login.
Please check my reasoning; I don't want hardware keys doing FIDO or something because:
- would have to have 2 or 3, in case of loss
- would have to register each key separately to each account
- when traveling, probably would have just 1 key with me, so if I lose it, I'm totally locked out until I can get home and get to a backup key
- even at home, if I lose a key, backup key should be somewhere safe off-site, so getting it would be a bit of a pain/delay
A hardware key just typing passwords or displaying 6-digit TOTP would be different. But not as secure as FIDO.
So, I think I'd like to have software TOTP everywhere. Vulnerable to phishing, and not a "something you have" second factor. But seems a good tradeoff of security/convenience/resilience for me.
56 comments
[ 0.23 ms ] story [ 587 ms ] threadI keep hearing this is simpler and more secure, but I really doubt explaining this to my aging parents is going to be a fun afternoon.
Can we just leave well enough alone? Was never a fan of centralizing my identity in the first place.
This comes with (some) additional complexity for implementing more complex auth flows for developers.
If you think that passwords are working "well enough" today you are clearly not educated on how most users (mis)use them. If you built a site and tried out the passwords people send to you on the logins for providers of the email addresses they send to you, there'd be a large fraction of people reusing their email account password for your service, allowing you to access their email.
So people invented OpenID and OAuth and stuff, but all those things are fundamentally flawed because users were no longer a source of their “own” identifies. Their identities became provided by third parties - and this is notoriously bad.
WebAuthn (and FIDO stuff) is not centralized, on the contrary - users still own their credentials and are sources of their identities (though there are optional attestations). It doesn’t require cryptography knowledge to use it, but it does to implement it - thus the certification (though anyone can surely do it without certifying for anything).
Human are also bad at not losing/breaking their magical security totem. I need to know that I can easily backup codes to any of these hardware tokens for if/when one is lost. Ultimate security be damned.
I'd rather know that each token is unique and not wonder how many copies of the token exist.
L1 (software based) obviously fits this requirement. I think L2 also can because while it is a physical key it could allow for the user to import their own secret. L3 takes that away as it must come from the manufacture with a key that cannot be accessed. Not 100% on any of this, but it's what I get from their level doc... https://fidoalliance.org/certification/authenticator-certifi...
BUT, I absolutely think we should continue to demand the right to interact with services on our own terms: Even accepting the compromise of "less security" (debatable if you know what you're doing).
I think the only way forward is a Free/Libre implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want. Even a fully-software one.
Is this not possible with current designs?
However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, which would be useful as you wouldnt need to enrol multiple secrets with each service.
Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?
That's what I meant. How exactly would one safely store this secret? How would you prevent an adversary from extracting the secret from the storage?
I'm not trying to be pedantic here, I'm just failing to see how this can be realistically implemented without significantly lowing the overall security. But this is also not my domain, so I'd like to learn.
If you're asking about the structure of the bits you'd need to move into the device in a verifiable way, there are standard APIs like PKCS #11 for interacting with HSMs.
You would then need a computer and a PKCS #11 client application. If you don't have a computer you can trust to pass keyboard inputs to a USB port without being intercepted, you've got problems that a yubikey will not solve.
Thanks, that was the piece I was missing.
Unfortunately the easiest way to "export" is likely to rely on the RP, as if they effectively use the sign_counter they may flag such a key as cloned. They should ideally just let you register multiple (and that's an RFC 'SHOULD').
Not a shill by the way, just a happy solokey owner.
The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk."
In my experience, solutions balanced on this type of ratio always fail to solve the fundamental problem. Which is why we have to have commercials that tell people "medicare will _never_ call you. If anyone calls and says they're from medicare, hang up immediately!" So, I'm assuming we can now look forward to "no one will ever call and ask for information from your key, if they do, hang up!"
I also expect a similar outcome.
Eh, my non-tech savvy friends/relatives find themselves guessing at and then finally resetting their password surprisingly frequently. There's some room for "reward" there.
There's usually no way to take your key off your device, so don't worry about that :P
This means keys need to be transported between devices. Which means even tighter coupling to google and microsoft accounts.
EDIT: Yes you don't need to use a syncing service. But it will be important for it to be portable between syncing services, as that is what most consumers will be using.
Pure keys are on tokens that support Bluetooth/NFC/USB to talk to whatever devices you want. One can use a built in key on a device with a security enclave which means using one device to auth addition of another, but you might do that with alerts to authorize, etc.
Anyone who doesn't have a powned problem is using something like TOTP auth codes which has all of the downside of Fido and none of the convenience.
A site that doesn't want you to could try to use attestation certificates to force you to use a real vendor's keys which should never be extractable.
Of course it'll take more than public key authentication itself. For example in a enterprise businesses employees aren't allowed to install software, and there are procedures (however bad) to vet individuals.
A friend has got a U2F device (forgot its name) which has six buttons that serves to enter a PIN and the PIN to authenticate and the PIN to register are different ones.
Or the Ledger Nano S hardware wallet (and probably the X too) have a U2F app (so the "older" standard only atm) but there it's even better: the device not only tells you if you're registering the key for the first time or authenticating but it also displays the name of the site you're authenticating to.
This is one notch above many other authenticating methods: it doesn't just protect the server versus malicious users, it also protects honest users logging into malicious servers/websites.
While physical devices probably will mostly be used for enterprises and us nerds, “platform Authenticators (e.g passkeys) offer much of the same security without the physical device
>FIDO requires an attestation private key, which must be shared between a batch of at least 100,000 security keys. Using a DIY or cli app solution (application running on the host) will likely mean you'll be generating that private key yourself, this makes you identifiable across registrations.
>Some sites (Cloudflare) may reject the use of attestation keys which are not found on the Fido Alliance Metadata Service. This precludes the use of any DIY solution.
>https://fidoalliance.org/metadata/
>https://support.cloudflare.com/hc/en-us/articles/44068890480...
Taken from a previous Hacker News discussion: https://news.ycombinator.com/item?id=31294316#31295128
For consumer scenarios, attestation is often not a requirement. In that case, FIDO offers the "none" and "self" attestation modes. None conveys no attestation. Self attestation involves a per-website key pair. Either of these modes are privacy and DIY friendly.
We actually managed to invent something even worse than passwords. Incredible.
As for Cloudflare use, it's an experimental hack. An option to avoid filling in a CAPTCHA in case you have a compatible hardware key. You don't have to have one, and you don't have to use it for this if you don't want to.
Disclosure: We built an open source library and an API that makes it easy to add WebAuthn/Fido to your existing web app. It’s available at for those who want to take a look. https://www.passwordless.dev/
There is also a more configurable demo page for the library where you can turn metadata on/off (the api is default off)
There's no reason why you should provide Attestation for the Web generally. It could make sense (though I'd argue it does not) for some specialised applications but generally it's probably a waste of your time (collating the necessary data to make it work) and your users time (now some stuff they want doesn't work and needs explicit authorisation).
The only place I've seen a 'legitimate' use for requesting an attestation cert is to ensure that only specialized FIPS hardware is allowed to be registered when that is a business obligation.
[0]: https://github.com/github/SoftU2F/blob/master/SelfSignedCert...
DIY/CLI apps have no reason to include a legitimate attestation - attestations are used to convey trust in the implementation, such as 'This is a Yubikey 5i'. The public key is usable to look up additional metadata, such as passing conformance and security implementation tests.
>Some sites (Cloudflare) may reject the use of attestation keys which are not found on the Fido Alliance Metadata Service. This precludes the use of any DIY solution.
The feature is meant for higher security environments (say workforce and government employee/contractor) to reject a home-grown implementation.
Cloudflare's (beta experiment) usage is a special case because they are using attestations to show that it is real hardware with a real financial cost. They are experimenting with using that as a replacement for captcha entering (while also experimenting with other technologies like privacypass to limit the number of times they ask for captchas).
The alternative to attestations in both of these use cases is that FIDO is not acceptable at all, not that a DIY implementation would become accepted.
At the same time, every week we see a "Tell HN: how I lost all access to my email/site/account because of {reason}", where {reason} is some stupid thing that the AI flagged.
Seems that we'll able to lose access to the whole digital world if just one company makes some mistake. Yes, they will.
- would have to have 2 or 3, in case of loss
- would have to register each key separately to each account
- when traveling, probably would have just 1 key with me, so if I lose it, I'm totally locked out until I can get home and get to a backup key
- even at home, if I lose a key, backup key should be somewhere safe off-site, so getting it would be a bit of a pain/delay
A hardware key just typing passwords or displaying 6-digit TOTP would be different. But not as secure as FIDO.
So, I think I'd like to have software TOTP everywhere. Vulnerable to phishing, and not a "something you have" second factor. But seems a good tradeoff of security/convenience/resilience for me.