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

Face ID and Touch ID for the Web

webkit.org

Post reply on HN
Print view View original

141–150 of 371 posts

Re: Face ID and Touch ID for the Web

#141

Post by ericpauley »

bjt2n3904 wrote: post #135

If passwords are the original sin, then Face ID and Touch ID are Sodom and Gomorrah. Authentication is something you KNOW. Strong authentication is something you KNOW, and something you HAVE. Something you ARE is great for identification, but terrible for authentication. Something you are cannot be changed like a password.

At least, in the case of biometric authentication on device, the ability to use biometrics expires automatically when the device is turned off (and other times), so biometric credential theft has a limited window of vulnerability. This contrasts with many fixed biometric authentication systems that aren't used as often as a cell phone.

Re: Face ID and Touch ID for the Web

#142

Post by jiveturkey »

dwaite wrote: post #96
jiveturkey wrote: post #34

Earlier quoted context omitted.

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…

> In that pre-announce video Apple dared to insinuate that attestation by current devices is de-anonymizing, when that isn't universally the case. Most hardware devices use batch attestation, where some group of (say, 100 000) keys all get the same private key. This does still provide some data for correlating users based on make + model + batch of their authenticators. ECDAA was meant to be an approach to solve this…

> There's no reason Apple needs to know either the specific piece of hardware

In order to revoke a specific device without cooperation of the device itself, which is one of their advantageous claims, they do.

Disregarding that property, Apple needs to know that the "CSR", ie attestation request, is coming from the secure enclave. That means that the "CSR" needs to be signed by some key. If the CSR signing key is unique per device, Apple receives device-specific information. This can't be an ephemeral key, as there wouldn't be a chain back to the secure element. If OTOH the CSR signing key is shared, it is probably exposed, or at least accessible for malicious signing, via the now known T2 compromise. There is much to be gained by such an exploit, so this isn't merely a thought exercise.

This complexity is all avoided by on-device attestation. EPID or EPID-like scheme could have been used, vs batch attestation.

Honestly, Apple is derelict in not describing this in more detail. Had they not made claims, it would be ok. But they are directly claiming to be better. I think we can be 100% certain they are aware of this depth of detail internally. Apple is not amateur hour.

Re: Face ID and Touch ID for the Web

#143

Post by acdha »

JoeAltmaier wrote: post #121
coder543 wrote: post #72

Earlier quoted context omitted.

You don't seem to be aware of what is under discussion here. You just raised a huge strawman. Websites are not receiving your biometrics in this context, and your biometrics would be meaningless to the website if captured and somehow provided. Your biometric signature is stored solely inside the Secure Enclave in the Apple device. If and only if the Secure Enclave recognizes you via your biometrics will the Enclave u…

That's sophistry. The fact is, the laptop is 'secured' by biometrics, which can be spoofed. Having a key-to-the-key is not safe if the biometrics are not safe.

That's you not understanding the security model, not sophistry. The application is granting access based on a public-key exchange, which the key stored in a hardware store which cannot be retrieved even in the event of a system-level compromise[1]. The remote application does not see the biometric data or even know that it was involved in the process.

It's also important to note that this does not mean anyone who grabs a laptop gets access to everything. The device still uses a password to unlock — you're forced to enter the password on boot before you can use biometrics later — and someone who stole an unlocked laptop could, for most users, have auto-fill supply the passwords _except_ on devices with biometrics which usually require that check every time (as iOS users have been reminded in this year of mask wearing).

So let's walk through some common threats:

1. Password re-use: a major source of compromises, blocked by this system 2. Phishing: a major source of compromises, completely blocked by this system 3. Compromised email: also popular, blocked by this system except for the services which allow email-based MFA resets, in which case it'd be the same as a password. 4. Local system compromise (user or root-level): passwords are vulnerable, biometrics present a barrier when the attacker can't just do something like reuse the credentials stored in your browser's cookie store. Biometric data and FIDO keys cannot be extracted. 5. Stolen device, locked: both are probably secure as long as you don't have your password taped on the keyboard 6. Stolen device, unlocked: passwords are vulnerable if you have a password manager which doesn't require e.g. FaceID checks (which is what Safari does on supported devices), FIDO MFA is not usable if Touch ID or Face ID is configured. Biometric data and FIDO keys cannot be extracted.

1. https://support.apple.com/guide/security/secure-enclave-over...

Re: Face ID and Touch ID for the Web

#145

Post by JoeAltmaier »

coder543 wrote: post #125
JoeAltmaier wrote: post #121

Earlier quoted context omitted.

That's sophistry. The fact is, the laptop is 'secured' by biometrics, which can be spoofed. Having a key-to-the-key is not safe if the biometrics are not safe.

It is not sophistry, and sophistry is not a word I've ever seen used in a genuine conversation, so I immediately doubt your sincerity in this conversation. If someone wants to fake biometrics on an iPhone, they have a very limited window of time to do so, and the user can lock out the biometrics in less than 3 seconds just by "squeezing" the phone. (power button + either volume key, 2 seconds later the biometrics are…

Sure it was - sophistry is pretended an issue is simple by (deliberately) ignoring alternatives.

If biometrics are fallible, it matters zero how secure the digital system behind it is. That's obvious, and a comment belaboring the digital security is beside the point.

As for how hard to spoof, just google it. There are dozens of folks with techniques and hacks right now. It'll only get worse.

Re: Face ID and Touch ID for the Web

#146

Post by bjt2n3904 »

ericpauley wrote: post #141
bjt2n3904 wrote: post #135

If passwords are the original sin, then Face ID and Touch ID are Sodom and Gomorrah. Authentication is something you KNOW. Strong authentication is something you KNOW, and something you HAVE. Something you ARE is great for identification, but terrible for authentication. Something you are cannot be changed like a password.

At least, in the case of biometric authentication on device, the ability to use biometrics expires automatically when the device is turned off (and other times), so biometric credential theft has a limited window of vulnerability. This contrasts with many fixed biometric authentication systems that aren't used as often as a cell phone.

Maybe... but if I steal your fingerprint, I have it forever.

And the courts can't yet force you to reveal secrets from your mind. But you can be compelled to use your fingerprint to unlock things.

Re: Face ID and Touch ID for the Web

#147

Post by coder543 »

JoeAltmaier wrote: post #145
coder543 wrote: post #125

Earlier quoted context omitted.

It is not sophistry, and sophistry is not a word I've ever seen used in a genuine conversation, so I immediately doubt your sincerity in this conversation. If someone wants to fake biometrics on an iPhone, they have a very limited window of time to do so, and the user can lock out the biometrics in less than 3 seconds just by "squeezing" the phone. (power button + either volume key, 2 seconds later the biometrics are…

Sure it was - sophistry is pretended an issue is simple by (deliberately) ignoring alternatives. If biometrics are fallible, it matters zero how secure the digital system behind it is. That's obvious, and a comment belaboring the digital security is beside the point. As for how hard to spoof, just google it. There are dozens of folks with techniques and hacks right now. It'll only get worse.

You are the one using sophistry, if anyone is using it. You are completely (and willfully!) ignoring how vulnerable passwords are in any threat model that invalidates a FIDO2 implementation of Face ID. No threat model invalidates the security of Face ID for the Web without similarly invalidating passwords. At least, you have chosen not to present such a threat model, which would help my (apparent) failure of imagination.

You cannot protect your passwords from someone who would physically take your iPhone before you can lock it and who would have a life-size reconstruction of your face ready and waiting. Such a person could shoulder surf your passwords with far less effort, or compromise one of the dozens of websites the average user re-uses their passwords on. At a certain point, the person in this threat model will just pull out a wrench and beat you with it until you help them get into your account. https://xkcd.com/538/

If you can show how some random person on the other side of the internet having your fingerprint helps them get into a website using your account... that would be interesting discussion. As it is, they must have physical access to your device. Your biometrics are useless without physical access and rapid action, since the biometrics quickly become useless as the device falls into a state that requires the user's passcode.

You're completely ignoring everything I actually said in my comments, so I'm done here.

Re: Face ID and Touch ID for the Web

#148

Post by ezekg »

nomel wrote: post #106
ezekg wrote: post #58

Has anybody ever thought about how Face ID is pretty much a backdoor into your iPhone? Think back a few years to when Apple refused to open a felon's iPhone for the US government, because "they couldn't." If that happened now, they wouldn't even have to ask Apple, given the felon has Face ID enabled. Edit: I'm kind of surprised by the downvotes, given I thought HN was pretty big on personal privacy. Just thought I'd…

The fingerprint sensor found on most phones doesn't always require intent, either.

Interestingly, touch ID launched 1 year after Apple refused to unlock an iPhone for the FBI.

Re: Face ID and Touch ID for the Web

#149

Post by ryukafalz »

bjt2n3904 wrote: post #135

If passwords are the original sin, then Face ID and Touch ID are Sodom and Gomorrah. Authentication is something you KNOW. Strong authentication is something you KNOW, and something you HAVE. Something you ARE is great for identification, but terrible for authentication. Something you are cannot be changed like a password.

The “something you have” is the key stored in the secure enclave/yubikey/whatever. That’s the real authenticator in this scenario. That it’s (maybe) unlocked biometrically is nice, but secondary.

Re: Face ID and Touch ID for the Web

#150

Post by mooreds »

krtkush wrote: post #50
yegle wrote: post #33

Earlier quoted context omitted.

"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.)

> I would definitely stay away from any "Sign in with Apple". I would stay away from any "Sign in with.." service as a user and as a product owner. You're affectively giving away a major control of your users to a third party.

This is always a business decision, imo.

It's similar to publishing on medium (or Huffpost, from a few years ago) as opposed to your blog. You'll get more reach in the former case, but have much less control. For that matter, it's similar to serverless vs code everything and host it in a server on a rack somewhere.

Engineering is all about the tradeoffs.

So, how would I make that call? I'd think about how much it mattered to have control of the auth experience vs the easier onboarding of customers. I'd think about the risks of having the auth yanked out from under me (I'm not aware of any cases where this happened). I'd think about the value add of auth to my app; in most cases it's slim to none. I'd also look at what the auth provider allowed me to know about the user when they deliver an authenticated user to my application.

I think in general auth isn't a huge differentiator for most applications, and offloading it to a social provider, as long as a chunk or most of the target market has an account (github for devs, linkedin for sales folks, google for, well, people with an email address), is a good choice.

Don't forget, you can provide both; I've worked at companies with only social login, but don't think that's very common.

Disclosure, I now work for a company which provides auth software (link in my bio).

Post reply on HN