Comment by mooreds | Hacker News Reader

Comment by mooreds | Hacker News Reader

Parent Full thread

My understanding of passkeys is that they are using WebAuthn under the hood (hence the nod to the w3c/FIDO at the end, and the fact that the passkey in the screenshot was associated with tribank.us).

They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created. This is a blessing and a curse.

It's a blessing because it eliminates a whole trove of phishing attacks. After all, if no one can get the private key, they can't steal or share it. Well, of course they could steal the actual device, but that's orders of magnitude harder than stealing online credentials (points to https://haveibeenpwned.com/ ). That's a good thing.

It's a curse because the same person logging in from their ipad, android phone, and desktop PC needs to set up WebAuthn three times. For each domain/website (broadly speaking). If they only set it up once and lose the device, well, they are either locked out or need to have another means of account recovery (username/password, calling a customer service rep).

This curse is what passkeys managed by Apple/Google are attempting to solve.

I believe the WebAuthn 3 draft is going to try to address some of this: https://www.w3.org/TR/webauthn-3/ but that's based on what a co-worker said. A quick scan didn't turn up anything.

If you want to know more about WebAuthn, I wrote a lot more here (my company is going to release an implementation Real Soon Now): https://fusionauth.io/learn/expert-advice/authentication/web...

> They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created.

To clarify I am not talking about the issue of syncing the device's private key. I am talking about the artificial problem these walled gardens are creating by having every single domain getting its own randomly generated private key. The only practical way to keep all of these randomly generated keys synced across multiple devices is to use the "cloud".

If instead the per site key was generated using a private key and the domain name, users would only need to transport that one private key to another device and would get syncing for free without the requirement of the "cloud".

> I am talking about the artificial problem these walled gardens are creating by having every single domain getting its own randomly generated private key.

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?

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

If the actual domain name is used to generate the key that would also completely eliminates the ability to do phishing-attacks. Paypal.com and PaypaI.com would generate two completely different keys.

It would mean that somewhere there is a common root, which if extracted, can derive all keys for all sites.

Why introduce such a risk when there’s no reason to do that?

If I can get access to your device to exfiltrate the private key that generates the domain specific keys, why wouldn't I also have access to the the randomly generated site keys? Your device needs access to the keys to use them.

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

I can register an authenticator multiple times, for instance to represent multiple different accounts of my own, or represent multiple people on a shared device.

If I delete a credential, the expectation is that registering a new credential is not going to correlate the authenticator (and thus the user).

If I want to have hygiene steps of rotating the cryptographic key a user uses to log in, I won't want registration to create the same key pair each registration.

And for the cloud sync:

The UX can present that web authentication is an option to log in. The user will be confused if that option is presented for sites which will not recognize the authenticator.

The site can store data alongside a credential to be returned to optimize the log in process, such as a site-specified identifier to look up the user credential in a database. That state needs to be synchronized.

Because then as a user you'd still have the ability to backup that key yourself and aren't at the mercy of $cloud_service_of_your_choice.

That's how hardware FIDO2 keys work now. There's no walled garden. You can remember a passphrase that generates a key that is used to derive every website's key in turn.

No cloud, no synching, nothing. You're fucked if your passphrase is stolen, but that's the tradeoff.

Every site is supposed to be keeping its randomly generated data to give back to you as an input to proving you have the device, but no one wants to give the relying parties open source "enterprise authentication" for free like in the days when Apache was king..

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.

In most implementations there's only a key or two on the device that you have to sync. The webauthn protocol requires a site that accepts it to store a small amount of arbitrary data for each registered device, which is then handed to any device that attempts auth. Most devices use that to store a copy of the site-specific private key encrypted with one of the device keys. (IIRC there's usually a symmetric key and an asymmetric keypair that are protected by the device, and the symmetric one is the more convenient to use for encrypting the site data.)

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.

> it's a curse because the same person logging in from their ipad, android phone, and desktop PC needs to set up WebAuthn three times.

Or just get some Yubikeys.

A Yubikey for a phone or an iPad seems pretty clunky. Outside of super high risk people and on-call devices, are there people actually using physical keys for their mobile devices ?

I actually do and it works pretty well. My Yubikeys are NFC compatible. I have my OTP generated on it and also use it for U2F / Webauth. I only need to tap my key to my phone for 2FAuthentification.

Rt

Reply on news.ycombinator.com