[wnevets]

Passkeys sound like another way for companies like Google and Apple to lock you into their walled garden. Having each walled garden randomly generating a key for every single domain instead of using the actual domain name as part of the key is a great way to lock regular people into their respective ecosystems.

[mooreds]

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...

[wnevets]

> 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".

[yakak]

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.

[scott00]

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.

[josteink]

> 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?

[wnevets]

> 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.

[stavros]

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.

[josteink]

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?

[wnevets]

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.

[xg15]

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.

[josteink]

> 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.

[makeitdouble]

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 ?

[rnotaro]

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.

[rnotaro]

Rt

[skybrian]

Seems like you wouldn't want to share passkeys for the same reasons you don't normally want to share passwords?

Instead, each website that accepts passkeys should allow you to register multiple devices and probably print out backup codes as well (for the especially important accounts).

If there's no reason to migrate anything then lock-in is irrelevant. Just add more login methods so that when you lose some, you have others.

[jjnoakes]

I have over 500 online accounts. Imagine if all of them used a login method where I had to have backup devices registered, instead of just me backing up the credentials (like I do today with a password manager).

With backup devices, whenever I upgrade or replace a device, I need to go to each of the 500+ online accounts and register the new device. This is much more work than a quick login to each site via my password manager (which can happen on-demand, only as I need to use the services).

[stavros]

WebAuthn credentials can be backed up, if you want. They can also be impossible to back up (and thus steal), if you want. It's up to you, which is more than I can say about passwords.

[jml7c5]

Do you know of any implementations that allow this? I've been looking around and even Yubikeys can't do it.

[pabs3]

See the virtual-fido project I posted elsewhere in the thread.

[jml7c5]

Thank you!

[skybrian]

Yeah, this is why I connect unimportant accounts to Google or GitHub, and use two step auth only for the important ones.

[dickhardt]

I founded Hellō to solve this problem. A neutral service where you get to choose how to login, and how you can recover your Hellō Wallet. Done.

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

[jml7c5]

I think you've pasted the wrong link.

[rohanharikr]

https://news.ycombinator.com/item?id=33177705

[dickhardt]

doh -- https://news.ycombinator.com/item?id=33177705

[throwaway41597]

The lock-in is very real and relevant.

Websites already have a hard time to get users to sign up, so requiring them to enroll backup authenticators (which they won't have) is not going to work. Printing or writing down backup codes is even worse from a UX point of view.

IIRC the spec has a flag to hint that the passkey is backed up (in iCloud or your Google account) so the relying party (website) knows whether backups are mandatory but that means the secret doesn't stay on your device and goes to the mothership. Then I don't see why the spec wouldn't standardize the transfer of secrets from one company to the other.

[skybrian]

That's a good point, but on the other hand, this "lock in" doesn't seem worse from how Chrome generates and saves passwords now?

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.

[throwaway41597]

Chrome allows you to export saved password in CSV (chrome://settings/passwords) So I'd say it is a regression in this regard. You won't be able to switch to an other browser easily, you'll have to go to each websites and change/add authentication methods as far as I know.

[api]

The entire third party auth push has turned into what may be one of the largest incumbent power grabs I have ever seen. Stuff like Google Amp or even App Store walled gardens pale in comparison.

What drives me nuts is how little discussion of this I've seen. People don't even seem aware of the implications of it. It's being pushed hard as a boon to security, which it is in some cases, but at a cost that nobody is even considering or talking about.

The implications are pretty profound: large companies having the power to lock you out of everything on a whim (even your own systems and unaffiliated third party services), levy taxes on the use of everything (e.g. Google starts charging you or sites to log in with Google), surveil literally everything (including logging into everything you have as you and sucking down data), and if a big identity provider gets seriously hacked it'll be an epic security apocalypse. Imagine someone stealing the master keys for a provider and pushing ransomware to millions of companies at once.

... and don't forget the obvious: "Oops I got locked out of Google and now I'm locked out of 50 SaaS services, my company's bank, my VPN, and my remote servers."

It just totally blows me away that these systems have no privacy protection at all, no portability provision for me to select or change my provider built into the protocol, no built-in support for third factor auth that I can control (e.g. FIDO2), no built in provision for recovery codes, and so on. These kinds of things didn't even seem like they were considered in the design of things like OpenID/OIDC. It's just a big "oh hey lets give god level access with no recourse to third parties and implement it so there's total lock-in... what could go wrong?"

Edit: yes some well-implemented systems offer their own built-in support for some of those things (recovery codes, changing your auth provider, reverting to password, etc.) but in my experience it's a minority and there is obviously nothing in the standard to encourage it or provide any guidance on how to do those things securely.

[stavros]

Man, every one of these comments has completely misunderstood the point. WebAuthn is an open standard. The provider is only there to sync your key. If you want, you can keep it yourself.

Why is everyone yelling about the sky falling down when this is the best thing to happen to authentication since ever?

[api]

If it syncs your keys, it has full access.

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.

[stavros]

> If it syncs your keys, it has full access.

It does, but it doesn't have to. You can use any provider you want, or self-host.

[r00fus]

Compare this with status quo for users like my parents. They constantly forget their passwords and quail at screwing up the 2nd factor all the time.

If they could just use their fingerprint/faceID to login (after initial registration on the device) they would be super happy.

Rest of us should be happy there will be less exploits where people give up the keys to their kingdom by clicking on a random email.

[jve]

Exactly what Google thinks: https://youtu.be/N7N4EC20-cM?t=15m36s

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

[dickhardt]

I founded Hellō to address your concerns. Check out the Show HN post I wrote this morning. https://news.ycombinator.com/item?id=33177705#33182379

[webmobdev]

This is also going to be a body blow for our privacy - if BigTech have access to your keys, so will the government and both can abuse it. The idea is to force you to "save password on device" (whether you want to or not) so that when a government authority gets your device they can also easily access all your internet accounts. US courts have already affirmed that it is legal for the police to force you to unlock your device if it is biometric protected (fingerprint or face scan etc.). Moreover, by forcing you to use your personal device for identity verification, BigTech is ensuring that identifying you and datamining your personal data becomes more easy for them. Don't be surprised if this is also extended in the future as a "super cookie" service to allow easy tracking.

[yupper32]

Why would this be different than any other password manager in that aspect?

[webmobdev]

Online service don't force me to use to use password managers.

[goalieca]

There will be services from 1password, yubikey, etc. This is actually great news!

[oezi]

I don't think this is possible. The browser doesn't allow other backends for key storage.

[goalieca]

https://www.yubico.com/blog/a-yubico-faq-about-passkeys/

[redandblack]

yeah. will be switching to this for all google apps, with firefox for general use