Bringing passkeys to Android and Chrome

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.

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.

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.

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

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.

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.

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

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.

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?

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.

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

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.

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.

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/

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.

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 ?

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.

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

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.

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.

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.

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.