Live data from Hacker News

Passkeys now support external providers

developer.apple.com

171–180 of 185 posts

Re: Passkeys now support external providers

#171
post #4

There is only this blurb to go on at the moment: "Passkeys can now be synced using external providers..." so it's hard to say exactly what it will mean for user control and choice. Which external providers? Will users be able to access and store their own private keys in compatible apps of their choosing? If so, aren't we largely back to passwords?

Passkeys still involve storing a secret, which I think is fundamentally what all security/authentication is built around. Passkey eliminates a lot of the issues with passwords (transmitting the plain text to the app, password reuse, simple passwords).

If you've been using a password manager with randomly generated passwords you've already addressed some of these issues so the benefits of using passkeys over passwords is reduced.

Re: Passkeys now support external providers

#172
post #31

Earlier quoted context omitted.

I would argue that password managers are not a "in every sense a really bad, bad idea" for a lot of reasons. Let's look at password reuse for example. As soon as you have more than a few dozen logins, the possibilities are mostly either reusing one or few passwords, or writing them down. Reusing is objectively bad, and for writing them down, the password manager makes it easy to use a really long and random password,…

Password managers makes the user life easier, at a big price if the master password gets compromised, as all the passwords get compromised at same time, in an unified way that by other methods would require much more specialization and effort for to gather together. If that passwords are stored in internet even worst, one can take for sure those passw-managing servers are juicy targets, it is a countdown until the se…

I have hundreds of sites in my password database. Can you remember hundreds of random 32 character strings? I can't and I think there are very few humans who can

Re: Passkeys now support external providers

#173
post #164

Of all the recent publications with regards to passkeys, FIDO2, WebAuthn, etc., finally there's one with a simple and concise summary of the benefits: > Strong credentials. Every passkey is strong. They’re never guessable, reused, or weak. > Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. > Safe from phishing. Passkeys are intrinsically linked with the app…

We spent some time putting together a threat-model and taxonomy of attacks paths for Passkeys in case anybody is interested: https://www.slashid.dev/blog/passkeys-security-implementatio... Passkeys are definitely a leap forward in that we are shifting the bulk of the account takeover risk from the end users using weak passwords or clicking on phishing links to: 1) The server side implementation, including any mechani…

That is by far the best explanation I've seen of Passkey or FIDO for that matter. Thank you.

Re: Passkeys now support external providers

#174
post #11
post #5

Interesting, but can someone tell us what this implies wrt. authorities? If someone gets your iPhone and forces you to press your finger on the TouchID, he gets all your passwords no? While with a general master password you could just pretend to have forgotten it?

Whichever way you look at it, in every sense, password managers are a really bad, bad idea. Besides that, it is not needed to force you to press your finger; the delinquent needs only to have access to the device for to fool the sensor with a brute force, 2 hours in the worse of the cases with the simplest techniques. Although its easier to take your finger prints from a glass or something you used for to avoid the w…

> once your fingerprint gets public it gets compromised until the end of the times

I'll just respond to this, as the other commenters are doing a fine job of addressing your other claims.

Your passwords aren't encrypted with biometric data of any kind on Apple devices (and I suspect that's true of Android as well). Simplifying a bit here, but it's broadly accurate: your biometric doesn't unlock your entire password database, it unlocks the stored secrets needed to decrypt your password database. iOS (and, likely, Android) devices have a simple way to force a passcode/password to be entered rather than using biometric data to unlock the device.

On iOS, activating the Emergency SOS feature (without subsequently calling emergency services) and then locking the device as normal (with the power button) will require the first factor (your passcode/password) at the next unlock attempt. No amount of finger-cutting or face-slicing can get past it. It's been that way for six years now, and was famously referred to as "the cop button" when iOS 11 introduced the feature.

Re: Passkeys now support external providers

#175
post #157
post #120

Earlier quoted context omitted.

Same way as you recover a password stored in your password manager. It's pretty much the same thing.

The way I do that is I memorise my password manager master key. How do I do that with a passkey?

Same way, your password manager will hold the passkey token instead of password. Recovering passkey is done the same as you recover your random generated password.

Re: Passkeys now support external providers

#176

Earlier quoted context omitted.

> I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Or do I need an Android phone for that? Yes. In Chromium-based browsers, at least. Your browser will display a QR code which you scan with your phone. Your phone will display a list of accounts you can sign in with, you select one, authenticate, and you're logged in. Firefox support isn't here yet.

That's not what I mean by "sync". If I don't have the phone with me, I can't authenticate. Also, I use Firefox exclusively. This is precisely what I mean: common scenarios are not yet supported.

You’re somewhat missing the point of what passkeys are. Instead of the something you know part, i.e. a password, the authentication is done by something you have. Your common use case is only common to single factor password authentication. It’s not a situation that is allowed for in passkey’s security model.

Re: Passkeys now support external providers

#178
post #151

Earlier quoted context omitted.

This is just plain wrong. The server only ever stores your public key, private keys are stored on the clients. Everything else would defeat the entire purpose.

No, it is technically correct for nondiscoverable mode. Naturally, there should be low value in breaking the opacity of the stored key as it should be a private key only used with the server that holds it. (But it would still mean many sites requesting that you replace any token found to have such a defect.)

Not sure why reality is so controversial, here are references for anyone who wants to know how a (standard) unlimited fido hardware token works:

https://security.stackexchange.com/questions/237271/where-ar...

OTOH for resident keys they usually support 50-100.

Re: Passkeys now support external providers

#179

Earlier quoted context omitted.

> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers That’s not quite true, though. What is true is that the server does not have a plaintext copy of your private keys. That’s a crucial difference. The server has an encrypted copy of your private key, which your with token decrypts with its private key. That is how a usb key can store an unlimited number of U2…

The idea behind private keys is that they are private and never sent anywhere so I believe your assertion that the server knows anything about your private key is incorrect. Here's a link to Yubico with a visual diagram of how passkeys work: https://developers.yubico.com/Passkeys/How_passkeys_work.htm... But fundamentally it's very similar to how all public/private stuff works. You send people the public key and sign…

It's very similar to how TPMs work. Discoverable keys were originally called resident keys because regular keys were almost always encrypted in the key handle and sent to the RP.

If you don't trust a system to encrypt why would you trust it to generate keys with correct random or sign without leaking key data?

The encrypted private key isn't any more likely to be a weak link than the other things a token could do wrong.

Re: Passkeys now support external providers

#180
post #139

Earlier quoted context omitted.

> Password manager apps can save and offer passkeys on iOS, iPadOS, and macOS. No reason to believe this would work differently than the existing affordances for 3rd party apps to offer passwords, which works well today

So I will be able to copy-paste some string from my password manager to my browser in order to complete the passkey handshake? Or does this mean that my password manager must support my browser of choice on my platform of choice with some opaque plugin that cannot be disabled (eg, 1pw on macos today)?

On iOS for passwords, this is a systemwide system that allows any app to register as a password provider and any password field to receive those passwords via the system keyboard.

I would assume that the system passkey interface will handle the receiving app, and the sharing app will register with the system (NOT with the browser or app, although this doesn't preclude doing that as well) to vend passkeys.

Post reply on HN