How does this work on laptop/desktop computers?
Like the laptops that Apple has built with TouchID built-in?
Face ID and Touch ID for the Web
31–40 of 371 posts
Re: Face ID and Touch ID for the Web
#32I'm curious about "Apple Anonymous Attestation". Is Apple taking on any liability by providing this service or is this all done on hardware through private APIs?
Attestation is just a technical term in the WebAuthn API. Different authenticators can use different attestation data formats. Apple rolled their own, hence the name.
Apple didn't just roll their own though, they improved upon it by allowing them to easily revoke attestation for a particular implementation without affecting all other devices out there.
So if an attacker tampers with the physical device, they can revoke the key for that particular device so that it is no longer trusted (the way I am reading it) vs yubikey where if an attacker has messed with one key, there is no good way to revoke attestation for that one device.
Re: Face ID and Touch ID for the Web
#33So happy Apple decided to go with an open standard here rather than something proprietary. This is good news for the FIDO2 ecosystem and I hope this leads to far greater support for FIDO2 authenticators of all types. There is another world in which Apple just pushed 'Sign in with Apple' and created yet another federated identity provider rather than true, 'secure element'-based FIDO2 authentication.
"Sign in with Apple" requires a developer account with Apple.
Having saw Epic's developer account terminated by Apple, I would definitely stay away from any "Sign in with Apple".
(FWIW, the only 2fa with "Sign in with Apple", if you don't own any Apple hardware, is SMS.)
Re: Face ID and Touch ID for the Web
#34I'm curious about "Apple Anonymous Attestation". Is Apple taking on any liability by providing this service or is this all done on hardware through private APIs?
When this was pre-announced awhile back I highlighted the lack of anonymity, due to the Apple secure element (T2 on laptop/desktop; whatever the name is on mobile) lacking attestation capability. That comment was downvoted by folks that presumably don't understand the problem at hand.
In that pre-announce video Apple dared to insinuate that attestation by current devices is de-anonymizing, when that isn't universally the case. And that their flavor of such would be "actually" privacy preserving. At the time, I figured this (a remote service) would be how they would address it, as the secure hardware probably doesn't have the burned in capability. Largely due to Apple needing to do it their own way.
Now of course, like the "normal" U2F attestation, this is private between the client and the service. But in Apple's case, like DOH, it is not private between client and Apple. IOW, a decrease in privacy, but marketed as an increase! LOL, classic Apple!
They go even further in their blind denial by stating:
> this approach avoids the security pitfall of Basic Attestation that the compromising of a single device results in revoking certificates from all devices with the same attestation certificate.
without recognizing or acknowledging that there is still a single point of compromise, but now it's a cloud service which many engineers have access to and presumably isn't 100% impervious to outsider attack either. So yes, it may avoid the single device security pitfall (resulting in a largish group of devices requireing to be revoked), but it trades it for an even bigger pitfall of all devices everywhere needing to be revoked!
It's sad that the reality distortion field has to be extended to privacy and security. Apple could easily just present their take on it without confusing the issues for the sake of marketing.
Further, it's up to the site to decide whether to use an anonymous attestation or not. The user will not be informed either way. With "standard" attestation, it's up to the user in their decision of what token (security key) to buy, and is always in effect. That said, a non-attested enrollment, if done correctly on the client side, doesn't give up privacy; just security.
To answer your question, it depends what you mean by "taking on". Yes, Apple is assuming some risk. They are not taking on any liability in the legal sense.
Re: Face ID and Touch ID for the Web
#35Neither sync nor keychain is mentioned in this post or in the WWDC presentation, so I'd like to ask if the credentials are synced between devices whatsoever, or if they're transferrable. While it'd be more secure to run it through a device's T2, a syncing/keychain-backed key would save a lot of the re-enrollment hassle for users who end up transferring their data to a new phone or need to enroll each of their devices for all of the web services they use.
Re: Face ID and Touch ID for the Web
#36So happy Apple decided to go with an open standard here rather than something proprietary. This is good news for the FIDO2 ecosystem and I hope this leads to far greater support for FIDO2 authenticators of all types. There is another world in which Apple just pushed 'Sign in with Apple' and created yet another federated identity provider rather than true, 'secure element'-based FIDO2 authentication.
"Sign in with Apple" requires a developer account with Apple. Having saw Epic's developer account terminated by Apple, I would definitely stay away from any "Sign in with Apple". (FWIW, the only 2fa with "Sign in with Apple", if you don't own any Apple hardware, is SMS.)
Apple did not terminate Epic's SiwA account, and several journalists have sources within Apple that say that Apple never sent the message Epic claimed to receive that said access was going away.
Re: Face ID and Touch ID for the Web
#37I'm curious about "Apple Anonymous Attestation". Is Apple taking on any liability by providing this service or is this all done on hardware through private APIs?
It is only for Apple Devices, and all it does is allow them to easily disable attestation and thus (is this device used for auth secure) for a singular TouchID/FaceID. Instead of with Yubikey where if the attestation key is compromised, and it is blacklisted, they disable every single last device manufactured with said attestation key.
> easily disable attestation
all future attestations. U2F/webauthn doesn't actually provide a revocation mechanism.
> Instead of with Yubikey where if the attestation key is compromised, and it is blacklisted, they disable every single last device manufactured with said attestation key.
it is important to note that there is not a "the" attestation key. there are many. "disabling" one, to the extent that is even possible, disables only the group with that key.
Re: Face ID and Touch ID for the Web
#38So happy Apple decided to go with an open standard here rather than something proprietary. This is good news for the FIDO2 ecosystem and I hope this leads to far greater support for FIDO2 authenticators of all types. There is another world in which Apple just pushed 'Sign in with Apple' and created yet another federated identity provider rather than true, 'secure element'-based FIDO2 authentication.
"Sign in with Apple" requires a developer account with Apple. Having saw Epic's developer account terminated by Apple, I would definitely stay away from any "Sign in with Apple". (FWIW, the only 2fa with "Sign in with Apple", if you don't own any Apple hardware, is SMS.)
> Having saw Epic's developer account terminated by Apple, I would definitely stay away from any "Sign in with Apple".
If you don't renege on your agreements with Apple as part of a public pissing contest, and you aren't in the business of misleading customers and creating deceptive apps, it's unlikely they'll revoke your developer account.
Re: Face ID and Touch ID for the Web
#39Neither sync nor keychain is mentioned in this post or in the WWDC presentation, so I'd like to ask if the credentials are synced between devices whatsoever, or if they're transferrable. While it'd be more secure to run it through a device's T2, a syncing/keychain-backed key would save a lot of the re-enrollment hassle for users who end up transferring their data to a new phone or need to enroll each of their devices…
They are no synchronized between devices. This is generally considered to be a no-no with FIDO (although Apple has not publicly announced whether they intend to be FIDO certified)
Re: Face ID and Touch ID for the Web
#40So happy Apple decided to go with an open standard here rather than something proprietary. This is good news for the FIDO2 ecosystem and I hope this leads to far greater support for FIDO2 authenticators of all types. There is another world in which Apple just pushed 'Sign in with Apple' and created yet another federated identity provider rather than true, 'secure element'-based FIDO2 authentication.
"Sign in with Apple" requires a developer account with Apple. Having saw Epic's developer account terminated by Apple, I would definitely stay away from any "Sign in with Apple". (FWIW, the only 2fa with "Sign in with Apple", if you don't own any Apple hardware, is SMS.)
[deleted]