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

Apple Passkey

developer.apple.com

Post reply on HN
Print view View original

101–110 of 421 posts

Re: Apple Passkey

#101

Post by drexlspivey »

kps wrote: post #90
judge2020 wrote: post #69

Earlier quoted context omitted.

> Also we still need ways of exporting keys and software (like 1password) needs to synchronize them, manage them securely. There's still a long ways to go on that front, which probably won't be handled until stuff like this has settled. That's the point of passkeys here: iCloud Keychain syncs them, and if you want to use your keys on a non-apple device you'll be able to scan a QR code, which initiates a new BLE conne…

I'm writing this on a non-Apple computer that doesn't have any radios. Now what?

What exactly is your point? You can just add a yubikey or any other device that uses WebAuthn to the service you want to authenticate with.

Re: Apple Passkey

#102

Post by jtcasper »

throwaway92394 wrote: post #89

Does anyone know how this/FIDO/Webauthn affect privacy? How well supported are alt accounts? Are they easy to tell they're from the same signer? I figure privacy is fine as long as the implementations allow you to select which account to login with. Is this currently a thing? From everything I read it seems like the current implementations are only meant to support one identity? EDIT: These are great responses, also…

FIDO2/WebAuthn don't have anything to do with user management from an application architecture perspective. They leave all the work of combining the attestation credentials and your application's concept of a "user" to the application.

This means you can (and should as a designer) have multiple sets of credentials for one "user", multiple distinct credentials that you (the user) can register to multiple separate "user"s in the application, etc.

I believe all FIDO2 authenticators (like hardware keys) should generate a new hardware / key ID for each request for pairing a new credential. I know that my key does that, when I was working on implementing WebAuthn for $DAYJOB.

https://developers.yubico.com/WebAuthn/ is a good jumping off point.

Re: Apple Passkey

#103

Post by neill »

atonse wrote: post #85

My wife signed up for calm.com using Sign in with Apple. Thanks to this, I am not able to occasionally use her login to listen to the wonderful music. There's just no way in hell I'm paying the $60 a year or whatever they're asking to listen to a couple songs every now and then. In a normal setting, she'd add her login to her 1password and I'd be able to use Calm.com, and who knows, I would've grown to love it, and g…

For a business, implementing FIDO in this case seems like a win. They get more lockout of password sharing, and have to explicitly work to enable shared logins (if that's something they want). Of course it's nice for an end user to be able to share credentials, but I think long term outlook will be towards businesses and applications pushing to improve their user management tooling.

Anecdotally, in the instance you described they net the same $60/yr regardless of wether you use your wife's login, so they're getting more stringent access controls (though you could always use the device in question, too) in line with their terms of service.

(Would also note that my response does not cover your latter points on helping users manage their accounts with their presence, but without their device presence, which I agree is a valid concern)

Re: Apple Passkey

#104

Post by psanford »

throwaway92394 wrote: post #89

Does anyone know how this/FIDO/Webauthn affect privacy? How well supported are alt accounts? Are they easy to tell they're from the same signer? I figure privacy is fine as long as the implementations allow you to select which account to login with. Is this currently a thing? From everything I read it seems like the current implementations are only meant to support one identity? EDIT: These are great responses, also…

FIDO2 resident keys (the thing people are now calling passkeys) allow for multiple credentials for a single site. If you have a device that supports resident keys you can try this for yourself on https://webauthn.io.

There is also no way for a site to know if two sets of credentials belong to the same physical hardware device or not. Sites can request the attestation certificate, but that is not unique per device (the spec says the attestation cert should be shared by at least 100,000 devices). If you want to see the attestation cert for a fido(2) device, I made a little tool that will show it to you: https://what-the-fido.sanford.io/

Re: Apple Passkey

#105

Post by gsibble »

zxcvgm wrote: post #46

This is based on the open standards WebAuthn and FIDO2, where the credentials (“passkeys”) are synced via iCloud Keychain. Currently you need remember to register at least 2 security keys, in case one is lost/misplaced. The syncing of passkeys in iCloud solves this backup problem. https://fidoalliance.org/apple-google-and-microsoft-commit-t...

How will this work on Linux?

Re: Apple Passkey

#106

Post by floatboth »

jml7c5 wrote: post #100
floatboth wrote: post #88

Earlier quoted context omitted.

Just add more authenticators to every RP (site you auth into). From the point of view of an RP, "your account in the Apple ecosystem" here is the exact same thing as "one of your Yubikeys", basically.

That seems like an enormous pain if you have dozens or hundreds of services. It could take hours to do this one at a time. (I'm assuming one minute per service, though that depends on how hard it is to find the "add another authenticator" page for each service.) It's possible I'm unaware that there is a simple protocol for this. Am I incorrect here?

Well, realistically not all services will support WebAuthn… spending an hour to handle a dozen important ones doesn't sound like a big deal to me.

Re: Apple Passkey

#107

Post by drexlspivey »

jml7c5 wrote: post #100
floatboth wrote: post #88

Earlier quoted context omitted.

Just add more authenticators to every RP (site you auth into). From the point of view of an RP, "your account in the Apple ecosystem" here is the exact same thing as "one of your Yubikeys", basically.

That seems like an enormous pain if you have dozens or hundreds of services. It could take hours to do this one at a time. (I'm assuming one minute per service, though that depends on how hard it is to find the "add another authenticator" page for each service.) It's possible I'm unaware that there is a simple protocol for this. Am I incorrect here?

You should always add at least two keys for every service in case you lose the first anyway. That was the case even before Apple passkey so just keep doing the same.

Re: Apple Passkey

#108

Post by [deleted] »

atonse wrote: post #85

My wife signed up for calm.com using Sign in with Apple. Thanks to this, I am not able to occasionally use her login to listen to the wonderful music. There's just no way in hell I'm paying the $60 a year or whatever they're asking to listen to a couple songs every now and then. In a normal setting, she'd add her login to her 1password and I'd be able to use Calm.com, and who knows, I would've grown to love it, and g…

[deleted]

Re: Apple Passkey

#109

Post by lsaferite »

neill wrote: post #103
atonse wrote: post #85

My wife signed up for calm.com using Sign in with Apple. Thanks to this, I am not able to occasionally use her login to listen to the wonderful music. There's just no way in hell I'm paying the $60 a year or whatever they're asking to listen to a couple songs every now and then. In a normal setting, she'd add her login to her 1password and I'd be able to use Calm.com, and who knows, I would've grown to love it, and g…

For a business, implementing FIDO in this case seems like a win. They get more lockout of password sharing, and have to explicitly work to enable shared logins (if that's something they want). Of course it's nice for an end user to be able to share credentials, but I think long term outlook will be towards businesses and applications pushing to improve their user management tooling. Anecdotally, in the instance you d…

You also ignored the point that perhaps they'd have gotten to like the service enough to get a subscription for themselves, but refusing out of spite now.
Post reply on HN