Passkeys now support external providers • Hacker News Board

Re: Passkeys now support external providers

#71

Post by Corrado » Tue, Jun 06, 2023, 12:17 PM UTC

Rygian wrote: post #40

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…

> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. It's still an attack scenario to keep in mind. If a server can be tricked into storing the wrong public key, authentication is defeated.

By the same token, if the server can be tricked into storing the wrong password, authentication is defeated. However, with passkeys, even downloading the entire database doesn't give the attacker any useful credential information. This is in contrast to today, where a database download gives you salted & encrypted passwords that are (generally) knowable (given enough time). I'll take passkeys over passwords any day.

Re: Passkeys now support external providers

#72

Post by cj » Tue, Jun 06, 2023, 12:17 PM UTC

arianvanp wrote: post #63

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…

How? you make claims that seem to have no substance. What extra vector does Passkeys add for tracking? I don't see any. Passkeys are an origin-bound login mechanism. Worst case is that somebody places a first-party cookie to keep you logged in after you authenticated with a passkey. which they and will already do today without your consent or without logging in. (First-party session cookies don't even need a cookie w…

With 3rd party cookies going away, companies now need your email address to effectively track you.

Tracking you via your email address is actually better than using cookies (for the advertiser) because it works cross-device and cross-browser.

Any mechanism that makes it easier to login to sites will promote the usage of email addresses for tracking purposes. Think retargeting and conversion tracking (no longer needing to be cookie-based).

Passkeys = quicker and faster to get a user's email address.

Email address = even better than "super cookies"

Re: Passkeys now support external providers

#73

Post by dan-robertson » Tue, Jun 06, 2023, 12:19 PM UTC

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…

I don’t think this makes sense.

Sites already desperately try to get people to log in. I don’t particularly see it as an advantage for Apple if eg the Reddit website or some random online shop makes you log in. If Apple are interested in selling ads, I think they should not want to make it easy to track people on websites through logins as that helps their competitors.

I generally model Apple as preferring that you use (and pay for/in) some app rather than a website, and logins are less necessary for apps where you can store information about your session and don’t need to regularly prompt the user for passwords. I think Apple would rather you don’t have some separate account you can log into on a website to eg pay for a service without in-app-purchases.

I mostly think of passkeys as a better version of the password manager: allowing users to do what they already want in a more secure way. If there is some subtle business advantage it is maybe that users would make new accounts rather than using sign-in with Google/Facebook, though I don’t know to what extent those features are valuable to Google/Facebook.

Re: Passkeys now support external providers

#74

Post by dan-robertson » Tue, Jun 06, 2023, 12:21 PM UTC

cj wrote: post #72

arianvanp wrote: post #63

Earlier quoted context omitted.

How? you make claims that seem to have no substance. What extra vector does Passkeys add for tracking? I don't see any. Passkeys are an origin-bound login mechanism. Worst case is that somebody places a first-party cookie to keep you logged in after you authenticated with a passkey. which they and will already do today without your consent or without logging in. (First-party session cookies don't even need a cookie w…

With 3rd party cookies going away, companies now need your email address to effectively track you. Tracking you via your email address is actually better than using cookies (for the advertiser) because it works cross-device and cross-browser. Any mechanism that makes it easier to login to sites will promote the usage of email addresses for tracking purposes. Think retargeting and conversion tracking (no longer needin…

But Apple offer this service where they make a fresh proxy email for you which is unique to the service. Why would they do that if they want to enable cross-service tracking via email address?

Re: Passkeys now support external providers

#75

Post by garganzol » Tue, Jun 06, 2023, 12:22 PM UTC

yomlica8 wrote: post #54

garganzol wrote: post #45

I'm totally in if passkeys come without middle men, especially like Google and Apple. Otherwise I'm totally out. No trust in these guys, they are as capricious as Roman emperors and will eventually do their usual stuff: lock in and collusion.

I've got a big problem with the attestation feature even existing in the spec. I know Apple plans to "zero it out" but if that changed sites could lock out non approved devices. I'd vastly prefer it wasn't part of the spec at all rather than relying upon the whims of a single megacorporation. If they ever drop that cover things will gradually become defacto locked to middlemen anyway.

Exactly. Middle men are not needed. Passkeys can and should be handled by an open specification. In this way, passkeys will be decentralized and can be supported by anyone and everywhere.

Users should decide by themselves where they want to store the authenticator: be it a separate device or a password manager running on their computer. Authenticator is just an algorithm that uses key material from elsewhere (biometrics, master password, whatever user prefers) to perform the authentication.

Tying the whole thing to a couple of corps is cringy and creepy at the same time. There must be an open standard where everyone can participate.

Re: Passkeys now support external providers

#76

Post by dan-robertson » Tue, Jun 06, 2023, 12:24 PM UTC

vouaobrasil wrote: post #68

arianvanp wrote: post #63

Earlier quoted context omitted.

How? you make claims that seem to have no substance. What extra vector does Passkeys add for tracking? I don't see any. Passkeys are an origin-bound login mechanism. Worst case is that somebody places a first-party cookie to keep you logged in after you authenticated with a passkey. which they and will already do today without your consent or without logging in. (First-party session cookies don't even need a cookie w…

If it is easier to do something, more websites will do it. Passkeys make it easier to make new logins, so more websites will do it. Just like seatbelts make people drive more dangerously. If more websites require logins, they can track you more easily, simple as that. It has nothing to do with the engineering aspects of passkeys, and everything to do with the fact that technology which makes logins easier will encour…

Doesn’t Apple Pay make it easier to not log in to websites (by getting rid of their desire to save payment details or addresses to get through later checkouts faster)? I just don’t really see some grand pro-login plan implied by Apple’s actions.

Re: Passkeys now support external providers

#77

Post by UncleMeat » Tue, Jun 06, 2023, 12:29 PM UTC

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…

"Authentication has to be messy and painful so it isn't adopted" is an odd take.

This also seems to be the polar opposite of most complaints about passkeys. The typical response is that they won't replace passwords because passwords are easy and accessible. Here you are saying that passkeys are easier. It can't be both.

Re: Passkeys now support external providers

#78

Post by tialaramex » Tue, Jun 06, 2023, 12:33 PM UTC

vladvasiliu wrote: post #39

tialaramex wrote: post #29

Earlier quoted context omitted.

> AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. In principle the fancier systems with a user interface could add a feature where you can change the DNS names assoc…

I may be wrong here, but since the yubikey and similar don't actually store anything site-specific, it means they just respond to a challenge, right? What they prove is that they own a specific private key. So if the website bundles its domain in the challenge, it can make sure that the client signed the challenge for itself, and the client can verify that it signs the challenge for the current domain. So now, if the…

Nope, but I can see why you'd expect that because the actual design is very clever and so it's not obvious how this could work.

What's inside the cheapest authenticators isn't a private key, after all they present a unique random public key for every single enrolment, so that couldn't work if they held a single private key. Instead it's a symmetric key (e.g. AES-256). Lets see how that's done:

When you enrol at a site, the authenticator mints a completely random new public/private key pair (with Elliptic curve crypto it's really easy to pick random key pairs because with a few bit ops any random bits become a random key) and after signing the enrolment step, the authenticator encrypts its new private key using that secret symmetric key and the DNS name in an authenticated encryption mode and provides that encrypted value too.

The browser, with the authenticator's help, puts together the final enrolment document, with a signature and it includes that encrypted private key as a Unique Identifier. All the Unique Identifiers in the protocol are huge random looking numbers, so the encrypted key blends right in with that.

For a web site, you need to store the public key (obviously) and this unique unique identifier value. You have to do that for everybody, anyway, it's mandatory. You can't decrypt the identifier even if you were sure it's encrypted, you don't know the key, so all you can do is play it back when you want a user to authenticate.

When it's played back, the authenticator takes the web site's DNS name, plus its own secret key, and decrypts the identifier to get back its private key, which it can now use to sign authentication messages. Of course if the DNS name is wrong, the decryption fails, which is exactly the same thing as happens if you try to use the wrong authenticator, or you're being phished, or a dozen other things - the authentication can't succeed.

Re: Passkeys now support external providers

#79

Post by UncleMeat » Tue, Jun 06, 2023, 12:33 PM UTC

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?

Okay.

How is that different from a password? How can you know that when you type your password into a random coffee shop public computer that the computer isn't running a keylogger and sending your credentials to criminals?

Re: Passkeys now support external providers

#80

Post by UncleMeat » Tue, Jun 06, 2023, 12:36 PM UTC

drtgh wrote: post #35

misnome wrote: post #17

Earlier quoted context omitted.

> Whichever way you look at it, in every sense, password managers are a really bad, bad idea. Okay, how about, the actual problem they solved: Reusing a single, simple password on every site, shared behind an email login. That doesn’t sound like a really, really bad idea.

At what point did password managers invent the idea of using a different password for each account? That is computing basics from the beginning. They didn't solve a problem, they just increased the lottery prize if the master password gets compromised. Every body can continue down-voting, but that fact is not going to change.

Password managers did not invent this idea, but we can observe people consistently reusing passwords when they don't have a password manager. It is just undeniable at this point that users cannot be expected to consistently create strong and unique passwords for each service.