Why Passkeys Will Be Simpler and More Secure Than Passwords – TidBITS | Hacker News Reader

Why Passkeys Will Be Simpler and More Secure Than Passwords – TidBITS

tidbits.com

> But imagine a world in which you can securely log in to websites using any current browser on any device running any modern operating system, without having to create, remember, type, and protect passwords. It’s relaxing just to think about.

This is such a weird thing to say... it really isn't all that relaxing tbh, like why not just use a password manager separately or through browser? What's relaxing about handing all your logins over to big company or big company's operating system? That seems like the opposite of relaxing

And also what happens if the public private key pair is compromised? How will they implement device syncing of passkeys or the bluetooth technique mentioned in the article without creating new vulnerabilities? Why not just do 2FA and not put all of your eggs in one basket?

They criticize 2FA as flawed in the article, but how common are the SMS vulnerabilities that they talk about? Based off of this article, it seems like passkeys are 100% better and the solution to all of our authentication needs. Reads like a sales pitch

> Passkeys are synchronized and backed up. If you get a new Android phone or iPhone, Google and Apple can restore your passkeys. With end-to-end encryption, Google and Apple can't see or alter the passkeys.

Hate to say it, but I personally don't feel comfortable storing all of my logins on Apple or Google's servers. Sorry, not for me.

>This is such a weird thing to say... it really isn't all that relaxing tbh, like why not just use a password manager separately or through browser? What's relaxing about handing all your logins over to big company or big company's operating system? That seems like the opposite of relaxing

It's not so much about handing over credentials but authenticating a physical device. Less a password and more like a list of allowed keys.

>And also what happens if the public private key pair is compromised?

The keys are generated separately for each provider and login. Hell, even if they get the server's stored public key they can't actually do anything with it. That's the whole point of a public key.

>How will they implement device syncing of passkeys or the bluetooth technique mentioned in the article without creating new vulnerabilities? Why not just do 2FA and not put all of your eggs in one basket?

The Bluetooth authentication technique mentioned in the article doesn't ever have a private key exchanged over Bluetooth. The authenticating device grabs the public key of the new device, authenticates the user on a device inside the user's account's circle of trust using the device's security (passcode/biometrics), then the already authorized device tells the server to add the new public key of the new device to the server's list of valid keys.

Airdrop transfers private keys but you don't have to use it if you're not comfortable.

>They criticize 2FA as flawed in the article, but how common are the SMS vulnerabilities that they talk about? Based off of this article, it seems like passkeys are 100% better and the solution to all of our authentication needs. Reads like a sales pitch

Fairly frequently. Providers are improving their security but there's still giant holes in it. Do you really trust your phone provider not to balls it up? Passkeys are 100% better. That's why we use them all the time for SSH instead of password/2FA.

>Hate to say it, but I personally don't feel comfortable storing all of my logins on Apple or Google's servers. Sorry, not for me.

You don't have to. At no point do their servers have to get involved. You'll still be able to login by bootstrapping devices into the circle of trust. You can run your own keychain software that you write and can use your CPU's inbuilt TPM or a hardware security module if you want. You just won't be able to restore private keys automatically if you lose a device and have to bootstrap the replacement device back into the circle of trust.

Apple's video is pretty helpful; jump to the 25:16 mark to get into the nitty gritty [1].

[1]: https://developer.apple.com/wwdc22/10092

Hate to say it, but I personally don't feel comfortable storing all of my logins on Apple or Google's servers. Sorry, not for me.

If you have multiple Apple devices, for example, you don't have to use iCloud Keychain for passkeys if you're that paranoid, regardless of how convenient it is. All I can say is Keychain is pretty badass; I have no qualms about using it [1].

If you're on a cruise and you accidentally drop your iPhone into the ocean, you could buy a new one at the next port—or when you get back home—and do Apple's restore process and you're back in business in 10 minutes. All of your logins, credentials, certificates, etc. are encrypted with a key Apple doesn't have, so they can't access or give it to anyone else even if they were presented with a search warrant by law enforcement [2].

And also what happens if the public private key pair is compromised?

It's called a public key for a reason; it can't be compromised, right? The public key replaces your username when logging in; both are public information.

The private key never leaves your device, so there's no opportunity for a sketchy website or fishing attack to get it. And it certainly can't be intercepted like SMS codes can be.

You know how people get fooled into logging into a fake site who's domain is one character different than the authentic domain? A password manager doesn't help you with that but passkeys are cryptographically attached to a domain, so it can't be used on a site masquerading as your bank's website.

They criticize 2FA as flawed in the article, but how common are the SMS vulnerabilities that they talk about?

You're kidding, right? These are the first 3 hits on google: [3] [4] [5]

[1]: https://support.apple.com/guide/security/keychain-data-prote...

[2]: https://support.apple.com/guide/security/secure-icloud-keych...

[3]: "Why Using SMS Authentication for 2FA Is Not Secure"—https://securityboulevard.com/2021/12/why-using-sms-authenti...

[4]: "Why 2FA SMS is a Bad Idea"—https://blog.sucuri.net/2020/01/why-2fa-sms-is-a-bad-idea.ht...

[5]: "Can We Stop Pretending SMS Is Secure Now?"—https://krebsonsecurity.com/2021/03/can-we-stop-pretending-s...

> You know how people get fooled into logging into a fake site who's domain is one character different than the authentic domain? A password manager doesn't help you with that

It does though, since it will refuse to auto fill.

But I get it. Still not as robust.

I've decided I'm just not doing this. I'm opting out. It's a PITA.

I agree. Not just a pain; it also feels like I'm ceding control of my credentials to somebody else.

I’d use this when 1password rolls it out.

My concern was about how it works if you switch/upgrade devices, and overall it seems like the keys are stored in the keychain (probably as certs?) which means they can be backed up outside iCloud.

Exactly my sentimonies. I have an iPhone, and this seems nice, but it if makes logins a PITA on my Linux machines, I’m out.

Passkeys are such a great idea that is for sure going to be ruined by implementers clinging stupidly hard to their “secure enclaves” making them a huge PITA to actually use.

It should be as simple as storing your private keys in your password manager, browser keychain, in a folder, or USB stick, Yubikey, or anywhere the user damn well pleases.

You should be able to easily export presigned tickets for recovery, support CA style auth for advanced users, and support passcode challenges (ie site gives you a short code you type in and your vault spits out a code) for cases where getting the two devices to talk directly is hard.

That's not really how they're meant to be used. Want multiple keys? Register multiple devices. Copying the same key around willy nilly just means you can't revoke access selectively. Not being able to export keys and mishandle them is kind of a design goal rather than a limitation.

That's because WebAuthn in general is a poor match to most lower-stakes uses of passwords. Not everything is a bank account. Many things are appropriately authenticated using "just" a password manager. WebAuthn refuses to acknowledge that, because it's a standard born of corporate security officers serving their own ends. It's still appropriate for some things an average human or techie human does, but not everything, and its promoters need to stop acting like it is the only game in town.

So every time I sign up somewhere I need to dig out all devices (including possible off-site backups if I was really thorough?) and sign them all up, too? If yes, then that doesn't sound particularly enticing…

As the tidbits article says, only the client is proprietary. I am sure that eventually a fully open-source Linux version of this is going to be developed and integrated into Seahorse.

Reply on news.ycombinator.com