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

41–50 of 371 posts

Re: Face ID and Touch ID for the Web

#41

Post by virtue3 »

dwaite wrote: post #36
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.)

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.

https://developer.apple.com/forums/thread/123774

Not the only ones that randomly gets their accounts terminated.

Based on how apple has -insane- fragmentation and security for different aspects of the company, I would doubt any employee that isn't directly tied into the store accounts would know the whole details. (Source: GF worked for the department that did art/design for the apple stores, no one had access to their room, and they had more secure rooms that only a few employees had access to).

FWIW google has the same issues.

Don't trust a company with an account that you can't get a human on the phone for to review shit.

Re: Face ID and Touch ID for the Web

#42

Post by mortenjorck »

The UI probably needs to be more explicit about what's going on.

I would imagine most non-technical users aren't well-versed in how Apple's Secure Enclave (or other competing solutions) manage authentication, and so I wouldn't be surprised if "allow example.com to use TouchID" would give many the impression that the website is asking to access their biometric data.

Ideally, the prompt should reflect the actual model, though I'm not sure how one might pose that in an accessible and succinct way.

Re: Face ID and Touch ID for the Web

#44

Post by dlivingston »

jjcm wrote: post #28

These all seem to be examples that use faceID/touchID as a password. That’s not what biometrics should be though, they should be the username. I hope that this is supported as a flow as well. Identify who you are with biometrics, and prove your access with a correlated password.

Maybe (probably) I’m just ignorant of the actual state of the industry, but it seems to me that biometrics have always been about providing full user authentication. I’m not personally aware of any instance where an alphanumeric password is still required as a secondary authenticator to biometrics.

Re: Face ID and Touch ID for the Web

#45

Post by Qahlel »

otterley wrote: post #38
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.)

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

unilateral agreements that one side can change on a whim is not something that one would call a fair agreement in the first place.

Re: Face ID and Touch ID for the Web

#46

Post by gumby »

jjcm wrote: post #28

These all seem to be examples that use faceID/touchID as a password. That’s not what biometrics should be though, they should be the username. I hope that this is supported as a flow as well. Identify who you are with biometrics, and prove your access with a correlated password.

But I like to use touchID to authenticate with multiple usernames on the same site. Using it as the username would reduce it to only working in a single case.

Re: Face ID and Touch ID for the Web

#47

Post by Symbiote »

otterley wrote: post #38
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.)

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

But we can still avoid Apple services in support of those Apple doesn't like, open standards and free competition.

Re: Face ID and Touch ID for the Web

#48

Post by dwaite »

ArchOversight wrote: post #32
fuzzy2 wrote: post #30

Earlier quoted context omitted.

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 go…

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

Attestation is a statement that the hardware and firmware are genuine, with the trust model being based on genuine hardware/software. You would not typically revoke anything - third party trust in that hardware/software combination would go away. That might be for example all iOS versions below 14.2, or all iPhones before the A14 chip.

If your service cares that much about key policy, you remember the attestations of each key so that you can change how they apply to security policy. That might be, for example, allowing someone to authenticate into a lower security level until they re-register the phone after upgrading their operating system.

In that sense, Yubico has a disadvantage in that their security policy does not allow firmware updates, so any firmware compromise will permanently tarnish those manufactured keys.

Re: Face ID and Touch ID for the Web

#49

Post by dustinmoris »

jjcm wrote: post #28

These all seem to be examples that use faceID/touchID as a password. That’s not what biometrics should be though, they should be the username. I hope that this is supported as a flow as well. Identify who you are with biometrics, and prove your access with a correlated password.

That doesn't make sense. Username + Password is a cumbersome workaround because (so far) machines couldn't use biometrics to authenticate a user. Now they can, so we can let go of that very problematic and often insecure model.

Think like this, when you go to visit your grandmother and knock on her door you don't have to provide a password. You don't have to provide anything, because the human brain is capable of determining your identity in less than a fraction of a second. This is why as soon as your grandmother opens the door she'll have a smile on her face and welcome you in. That IS biometrics. Now machines can do the same. It's the oldest and most secure form of authentication in human history.

Re: Face ID and Touch ID for the Web

#50

Post by krtkush »

yegle wrote: post #33
blintz wrote: post #13

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

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

Post reply on HN