Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passkeys now support external providers

developer.apple.com

Post reply on HN
Print view View original

161–170 of 185 posts

Re: Passkeys now support external providers

#161

Post by bravetraveler »

vouaobrasil wrote: post #52

So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it. Thus, passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour. Although it has the benefit of making our existing…

It's a fair point, but I'm not that worried about more logins. We're already being pushed this way by Big Business wanting more and more users to mine/advertise towards.

I worry a little about normalizing on fingerprints, but not because tin-foil-hat thinking about tracking.

Those can certainly be ordered/forced by a judge, where passwords/codes are less well defined. I'm not up to anything shady, but I fear an authoritarian government.

Let's consider PINs, too. Those can be used instead. How many of these are people going to memorize? Many passphrases become one relatively easily guessed number on a device you can lose

Implementation details, surely - and I'm really green... but I worry about unintended consequences a lot

Re: Passkeys now support external providers

#162

Post by SahAssar »

theshrike79 wrote: post #64
jabbany wrote: post #53

Earlier quoted context omitted.

Are you saying they don't use any physical keys? That would be surprising to me... I've found it really easy to teach non-technical people how to use U2F tokens. Just tell them it's like a door key but instead of plugging it in and turning, you plug it in and touch. That's all there is. It's been much more intuitive* to my older family members than SMS codes (that sometimes get lost), authenticator apps (that have a…

The difference is that I can know with significant certainty that shoving my house key in a random lock won't copy the form of my key and send it to a 3D printer where a thief will get it and use it to access my house. How can I know that won't happen when I use my USB dongle on a random coffee shop public computer?

You are literally wrong on both cases: A normal key can be quite easily copied and a yubikey or similar security key cannot be copied.

Re: Passkeys now support external providers

#163

Post by Dylan16807 »

9dev wrote: post #151
labcomputer wrote: post #133

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…

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.

It would not defeat the entire purpose.

"non-discoverable" WebAuthn keys aren't part of "passkeys", apparently, but they locally encrypt the per-site data, including the private key, and then give that encrypted data to the server to store.

Re: Passkeys now support external providers

#164

Post by snagg »

ckastner wrote: post #10

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 mechanism for account recovery and support for multiple passkeys/auth factors

2) The browser enforcement checks (eg: this is what Chrome does: https://www.slashid.dev/blog/webauthn-antiphishing/)

3) The wallet/keychain/password manager holding the keys (there's a lot of variance here in terms of security guarantees, see recent password managers breaches. We wrote a bit about how Apple does it: https://www.slashid.dev/blog/passkeys-deepdive/#the-technica...)

4) The authenticator itself (again, lots of variance here)

All of which are harder to compromise vs the average end-user.

There are still scenarios where the end-user could be targeted/tricked but they are fewer and harder to pull off (to name some: malware stealing the private keys and account takeovers on the password manager).

Re: Passkeys now support external providers

#165

Post by r00fus »

ljlolel wrote: post #19
ckastner wrote: post #10

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…

The last one is a problem for a lot of use cases. Lots of sites have different domains (also for example when HBO max renamed to max). Plaid also relies on entering bank passwords on neobank sites and is widely used.

Intuit Mint is not much different. Mint was forced by some banks to not use customer credentials, and instead request an OAuth token from the customer to allow read-only access. So Plaid/Mint have the tech, they just don't do it because of adoption issues at other banks.

Re: Passkeys now support external providers

#166

Post by mistrial9 »

next headline -- Passkeys now require external providers

update this dev news announcement actually opens the setup a bit more, instead of close it down a bit more. However the whole Apple walled garden and always-on networking is not a happy thing from this desk

Re: Passkeys now support external providers

#167

Post by eep_social »

ezfe wrote: post #139
Ajedi32 wrote: post #95

Earlier quoted context omitted.

Yeah, this is awesome. The devil's in the details though, do we know anything about exactly how they plan to support external providers? I'm cautiously optimistic; at least on the surface this sounds like exactly what I was hoping for.

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

Re: Passkeys now support external providers

#168

Post by patmorgan23 »

ljlolel wrote: post #19
ckastner wrote: post #10

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…

The last one is a problem for a lot of use cases. Lots of sites have different domains (also for example when HBO max renamed to max). Plaid also relies on entering bank passwords on neobank sites and is widely used.

That just means the auth service needs to have a stable domain, not necessarily the whole app

Re: Passkeys now support external providers

#169

Post by patmorgan23 »

vouaobrasil wrote: post #52

So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it. Thus, passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour. Although it has the benefit of making our existing…

If a site requires you to create a login just to view some content, could you just create a new login each time you visit? Also that would probably kill their Google ranking.

Re: Passkeys now support external providers

#170

Post by patmorgan23 »

vouaobrasil wrote: post #70
RcouF1uZ4gsC wrote: post #60

Earlier quoted context omitted.

> So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it. Actually, this ease of use may be beneficial to privacy. Sites don’t need user generated/remembered passwords to require a login, they can just use the sign in with Google/Facebook/Apple buttons. Becaus…

You are ignoring the other side of the equation: more sites with logins.

Then just create a new login each visit if it's so trivial.
Post reply on HN