> provides organizations deploying FIDO Authentication with a centralized and trusted source of information about FIDO authenticators.

The aim of this centralized system is to allow revocation of hardware that doesn't meet their unchallengeable opinion of whether you've spent enough money on your device or not. They can similarly require that devices do biometric scanning[1], and be issued by your government, and require you to agree to lengthy (and self-updating) terms of use.

There are actually (at least) two different types of device attestation that FIDO support[2]. One uses a hardcoded on-device private key, that's common between 100,000 devices of the same model, which means that an attacker can brick 99,999 other people's devices just by extracting the key from their own device. The other method requires a certificate from a "trusted third-party Attestation CA", which presumably allows a malicious (perhaps government-mandated) CA to spy on (and filter) every login request you make.

This system is like a dystopian parody of the traditional model of web security, which had no need for "authenticators that have a Trusted Platform Module (TPM) onboard", and which only required CAs to be on a list that the user agent is in control of (and users can add their own CAs to). Instead, what FIDO are building is basically DRM for human identity, with all the corruption and failure modes that entails.

[0] https://fidoalliance.org/metadata/

[1] https://fidoalliance.org/specs/biometric/requirements/

[2] https://research.kudelskisecurity.com/2020/02/12/fido2-deep-...

Most services probably would not restrict you to just one model of authenticator, but it wouldn't surprise me at all to see a service require that the authenticator be backed by a secure element, in which case you could use a security key, a passkey, a TPM, et cetera, but not a password manager. I'd still take that over passwords, but I don't think everyone would.

Actually, I do — in fact the largest system I work on supports predominantly older people with disabilities. I would strongly suggest that you consider whether your assessment of the relative difficulty levels is skewed familiarity with the existing problems with password systems.

> No email identifier or thing to remember. How can I know log on at my other device? > With a QR code? What on earth is that?

You still use your email address. This replaces passwords, not SSO, and QR codes are only used in some cases for some implementations where you might have restrictions on things like network connectivity. Try the demo here:

https://www.passkeys.io

Here's the signup process:

1. Enter your email address 2. Select the option to use a token 3. Approve your device's prompt (on iOS, this is a system dialog which explains that it's stored on all of your devices using iCloud Keychain and the site owner doesn't get any of your PII)

Note what's not there: picking a secure password, setting up MFA, remembering that password, and entering it reliably every time. You also can't get phished, which seems like something a lot of people would like.

We're familiar with the friction around passwords but consider how many hours a day humanity spends creating passwords, resetting them, dealing with typos, etc. If you support older people or especially those with disabilities, that process is a lot harder. For example, entering a password over a screen reader which meets most site's complexity requirements is terrible. Most non-WebAuthn forms of MFA are pretty painful that way, too, because it requires someone to switch apps, copy/paste or remember a code, switch back, etc. before it times out.

This won't be perfect on day one, I'm sure, but it's already easier and faster to use and that's only going to continue because now the system can be improved by the browser vendor rather than needing every site to agree on improvements.

Phishing would also be back on the table: The phishers' narrative would just change to something like "Dear $user, we're upgrading our systems. For technical reasons, please change your sync target to $url, otherwise you will lose access to all your logins. Yours truly, Dropbox"

My understanding was that many of the advertised security properties of passwordless logins stem from the property that no one, not even the owner of the account has access to the key. This renders phishing impossible because the user cannot physically give away the key even if they wanted to.

But that solution is fundamentally incompatible with copying the key to anywhere else.

This is the same threat model as password managers, which are generally approved of on HN.

You believing $company is not as bad as Google definitely has nothing to do with marketing!

So if you get a mob of people all reacting the same way to something, who, upon examination, have arrived at their conclusion for a smattering of contradictory and inconsistent reasons, it can be a helpful point of information for diagnosing the irrational mob response.

Granted it's not always the case, people get to similar beliefs through different reasons.

But these are two phenomena that exist side by side and there are times when it's necessary and helpful to be able to diagnose the first.

It’s not as “you’re on your own” as some products I’ve owned.

Google's customers are mostly the people that get to show you ads. So they don't seem to care about even the paying users for their products. And it's sad that Apple seems to be going the way of trying to be an ad platform as well.

Google does not kill services. That does not happen. Google definitely does not deplatform people killing all their accounts and all their access. That also does not happen.

If you scroll back, they mention you have to protect everyone to be effective, i.e. high value target friends and family.

Syncthing [1] works very well. I personally do not trust my phone with my passwords, so barely do any serious things on my phone.

[1] https://syncthing.net/

It's a bit more complicated than that: if you enable synchronization, Google or Apple have stored encrypted blobs but they don't have access to the data. To decrypt it you still need access to one of your linked devices.

The other thing to remember is that the keys can be exposed only for the time it takes to install them: you get a new phone, it downloads the blob and has one of the other devices approve decryption, and that key is immediately re-encrypted locally. That makes it a lot harder to get a copy because the attacker has to compromise one of the registered devices enough to attack that process rather than simply getting access to an unlocked phone.

Finally, it's not as simple as one-key-to-rule-them-all: the WebAuthn handshake has both the synced key and a device key. That means that a high-security application could still do additional checks any time they see the synced key used with a previously-unseen device key.

> If a phone is in the wrong hands, it's much easier to gain access to the phone using fingerprints than it is using passwords: There is a good chance some usable fingerprints from you are still on the device cover itself. Sure, an attacker would need some resources to take the fingerprints and build something that can be used with the phone's sensor, but if enough people use fingerprints for auth, attackers will streamline this step quickly.

Again, I would suggest looking at the decades of prior art (or considering that it's moot for the majority of Apple users using infrared facial scans with liveness checks). It's actually pretty hard to get usable prints since they need to have some structure, not just a single flat image, and people don't commonly build phone cases out of things which record that kind of detail.

It's not impossible but the odds are already low even before you consider that the attacker only has a few tries and a time window to accomplish it in. Most people are not interesting enough to launch this type of attack against (think about what it's like trying to make money with that unlocked phone without leading the police to your door) and in a targeted attack looking for something like political dirt they're going to get that password by watching the user type it because not using more advanced systems means they're forced to do so frequently.

> That's bad enough if it grants "only" access to the phone itself, but now it would also grant the attacker access to each and every online account.

Kind of like what happens if they get full unrestricted access your phone without this and recover all of the saved passwords?

Remember that this is all optional geared at the vast majority of normal users. If you really think that the risk of someone recovering a fingerprint / facial scan is too high, you're free to continue using hardware WebAuthn tokens like you are hopefully doing right now. What this is solving is the friction around creating secure passwords and not losing them, and getting away from the idea that an email address is the real key to everything.

If you want more details about how it works, I would definitely listen to Adam Langley's interview here: https://www.buzzsprout.com/1822302/11122508-passkeys-feat-ad...

The various incarnations of their chat services is a better example. Gtalk used to have great XMPP support, even federation for a while. All remnants of that are gone now so I had to stop using it.

It would be ideal to set up backup auth before you need it, but you could also do it when you decide to move off Google.

So, not really a lock. It's a vulnerability, though, if you lose access to the Google account for some reason.

I have no idea what you mean by this. You do not need, and have never needed, to own an iPhone to use an Apple computer.

> I bought my wife a iWatch last week and briefly thought of getting myself one but you can't use it without an iPhone...

This, on the other hand, makes a little more sense. The Apple Watch is designed as a companion device to an iPhone. Much of its functionality relies upon the phone (e.g. displaying notifications from the phone, installing watch apps which pair with corresponding phone apps) -- it can't do much on its own.

Not disputing this, but it requires a “pro” account which is $10 a year.

No big deal to me, in fact I find it a great deal, but I think it’s fair to be clear about this as not to provide false expectations.

All I'm saying is that authentication is literally the keys to the castle, and inviting third party control of authentication has some scary implications in terms of privacy, monopoly control, and security.

We should at least be discussing this, but I don't really see that much discussion. People are just blindly adopting this stuff because it's convenient and not even thinking about what's under the hood or whether there is a way to back out or change provider.

I don't really see a safe way to do what fido was trying to do while letting keys flow about and using their cloud for the original setup with the security we were originally expecting wouldn't have the conveniences they are talking about.. So it seems like more phishing, now for getting an activated device/chrome session.

It's possible to store every key the device has registered, but most devices don't do it that way to keep the cost of the secure enclave low.

That’s part of the design though. That’s what completely eliminates the ability to do phishing-attacks.

If there were a common root to leak, that would just provide a new target for phishing attacks, and effectively risk reducing a persons entire online security down to 1 shared root-key.

While obviously better than having just 1 common shared password, why reintroduce this risk when you don’t have to?

Step 1. Sign in using your existing device

Step 2. Add your new device

Step 3. Remove your old device (or keep it for a backup)

And if you feel that's going to be a big issue for you, use a 3rd party software based tool like Bitwarden, 1Password, or other tools that have indicated they'll be supporting this. That info will sync between those software based tools and allow you to use whichever devices you wish, across multiple platforms with minimal effort.

It's built on the same technology as FIDO keys, so if you want to take control of it yourself, just use a hardware key.

Like this isn't particularly different from me backing up my (encrypted) disk which contains my (further encrypted) keys to the cloud somewhere.

Vendors trying to peddle a solution will always try to answer this question in a way that doesn't say "well in that case you're screwed" and any answer except "you're screwed" means there is some kind of potentially-vulnerable recovery process, and the description of how the process works usually gives you an idea of how secure it is (or at least a starting point to ask more questions).

You are correct that a Passkey ecosystem has an inherent risk of being locked out of cloud storage / sync, and that a third party escrow system is a mitigation against that. But it's not sufficient. You'd end up with keys that could, at best, only be imported into authenticators of the same ecosystem you were denied access from which, as Sync Fabrics are not interoperable. This is presumably not the outcome you're looking for.

I believe some sort of mechanism to assert credential strength at presentation time rather than generation time, and/or some sort of mechanism for TPMs/Secure Elements/Secure Enclaves to establish trust and import trusted credentials from a different authenticator vendor would be needed. This would allow vendors that don't control the hardware (i.e. are not Apple/Google/Microsoft) to build something like a "1Passkey" without having to implement their authenticators in software (i.e. a Virtual Authenticator), and you could keep your wrapped passkey store in escrow with any third party of your choosing.

You accept Google and Apple might deny you access but then you just blithely assume the US Federal Government (for example) would never do so, which shouldn't pass the laugh test.

I can imagine it being valuable if my government wants to help get me back in to, say, my bank accounts if I somehow lost all my credentials (e.g. my home burned down suddenly but I somehow escaped with nothing). But I don't feel like my GitHub, Gmail, Patreon, etc. make sense in this context. If my friends can lose a phone every year or two and make a new god-damn account, I think "My home burned down and I have nothing" is a good enough reason.

Gitlab's attitude of (for unpaid accounts): Too bad, just make another one - seems appropriate for almost everything. If tialaramex never wrote another HN comment, and instead tlrmx or tialaramex2 or whatever began posting, who would even care ?

I wouldn't want escrow of private keys, however. I'd rather the USPS just act as a certification authority that provides strong guarantees of identity verification.

In both cases your device has a private key that it needs to secure. In my scenario we remove the third party cloud service.

See Show HN post I wrote this morning https://news.ycombinator.com/item?id=33178285

But I'm not talking about incorrect or correct and I don't care about fairness in presuming whoever's intelligence either, because the thing I'm talking about is more important, which is risk.

Large companies taking on big tasks that you don't pay them for is undeniably risky for many reasons. One, they screw it up today. Two, they don't screw it up today but they change it tomorrow. We know this because many of these companies have done things like this before.

I'm curious about what you mean by this. Isn't it in part what PBKDFs are designed for?

Even that is not good enough, by a longshot. This is so much worse than even regular passwords.

It works for corporatiosn. Lost your key? Go to IT and generate a new one.

It does not work for individuals.

You have choices now, whereas before you had basically one.

Yubikey offers you a hardware device specifically for this purpose. It can't be copied and it really is the definition of something you know and something you have. It has pros and cons, one of those cons being that if you want to use them you are stuck having multiple devices, one for a backup.

Don't like that con? Well, play the game a little and you have additional options coming. Such as the solutions from password managers and platforms like Apple and iOS. Add your sites in a password manager and it'll sync between devices, you basically only have to add one single thing (your password manager) and as long as you have password manager access you can sign in to those sites anywhere that your password manager is available, and where it isn't you gain the QR code passkey option that is being added.

You can mix and match this to your hearts content. Want to use a Yubikey as a backup? Add the device to your sites, stash it away where necessary. Yes, the con of having to add it to each site is still there but it is an option. Want to use all of these? Sure can. Add your iOS device, your password manager, and your Yubikey.

Want to only use one? Just add that device. But you might be foot gunning yourself without backups depending on which you use.

Stop being difficult and just use your head a little.