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

181–190 of 371 posts

Re: Face ID and Touch ID for the Web

#181

Post by dkonofalski »

the_arun wrote: post #160
yegle wrote: post #60

Earlier quoted context omitted.

I think "Sign in with Apple" is unique that Apple allows the users to hide their email address https://support.apple.com/en-us/HT210425 which makes it extremely hard to migrate away, unlike other federated login system where you can at least get users' email addresses, allowing you to create a proper email+password login later on.

I think it is very private. The third party app cannot sell the attached email address to others. But I agree if you sign up with the third party using your apple id, they will not know you which may end up in creating second account. If they don't have account linking feature, it will be messy.

Apple announced an account linking feature as a requirement at WWDC this year.

Re: Face ID and Touch ID for the Web

#182

Post by dwaite »

jiveturkey wrote: post #142
dwaite wrote: post #96

Earlier quoted context omitted.

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

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

My understanding is that there are methods to revoke a particular group key under DAA, which would prevent that device from being able to retrieve attestations in the future.

That said, revoking individual devices is somewhat nonsense from a security point of view. There's nothing (other than the difficulty of the hack itself) that prevents a compromise of one phone from being replicated across the entire production line, which impacts the security reputation of the entire line.

Also, it is hard to imagine the use case for identifying and revoking the attestation for a single user's devices that isn't troubling.

Re: Face ID and Touch ID for the Web

#183

Post by znpy »

I've come to appreciate DigitalOcean's approach on the matter.

Until you configure a 2FA device (TOPT in my case) they'll send you a temporary code to your email address.

So password alone is worthless, and mailbox ownership is verified on every login.

Also, I made a point never to use the "login with X" feature, no matter what X is.

I always sign up with my own email.

Re: Face ID and Touch ID for the Web

#184

Post by beached_whale »

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

Epic asked them to terminate the account though.

Re: Face ID and Touch ID for the Web

#185

Post by dwaite »

jiveturkey wrote: post #142
dwaite wrote: post #96

Earlier quoted context omitted.

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

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

EPID is a DAA scheme. _If_ Apple is using a DAA scheme to their attestation service, then you would use that to protect the equivalent of a CSR (which really should only need the public point and hash of the creation request).

The intermediate service exists to hide the choice of DAA scheme (and needs to potentially require things like BN curve cryptography to handle it), and to do other value add logic. For example, the attestation format is extremely similar to DeviceCheck attestations, which assert hardware/os/application authenticity for a third-party remote service call.

Re: Face ID and Touch ID for the Web

#186

Post by madeofpalk »

wlesieutre wrote: post #177
madeofpalk wrote: post #155

Earlier quoted context omitted.

For what it's worth, it's been said (by anonymous sources, no one on the record) that Apple did not threaten to terminate Epic's "Sign in with Apple" accounts/features, and they spent extra effort to maintain their access to that after their account was terminated. I do not know if other terminated accounts get this "luxury".

Epic did say it was going to be terminated, presumably as part of the overall account termination. They then updated that it would continue to work. https://www.theverge.com/2020/9/10/21431396/epic-sign-in-wit... Apple commented they weren’t doing anything to stop Sign In with Apple working, but I have to wonder if there’s a lie of omission in there. Like “We aren’t doing anything deliberate to stop it, but it’s goin…

unnamed sources have said that Epic was outright lying https://daringfireball.net/linked/2020/09/29/epic-games-unre...

> multiple sources at Apple told me Epic’s claims were simply false. There was never a September 11 deadline for their SIWA support to stop working, and in fact, Apple’s SIWA team performed work to make sure SIWA continued working for Fortnite users despite the fact that Epic Games’s developer account had been revoked.

Re: Face ID and Touch ID for the Web

#187

Post by enos_feedler »

simonw wrote: post #137
ogre_codes wrote: post #109

Earlier quoted context omitted.

As a user I would prefer no account in most cases. As a distant second, I would prefer the convenience, security, and privacy of Sign in with Apple over Google, Facebook, or the headache of managing yet another web account . As a developer, I use my preferences as a user to steer my choices, but recognize that the world doesn't revolve around Apple so would allow other options. > Having saw Epic's developer account t…

> Since I have zero need to deliberately violate Apple's App Story policy, I don't worry about this overmuch. That may be true today, but their policies are a moving target. Who knows what they'll be like in a year's time?

It isn’t productive to establish defense against an arbitrary future that turns on you. Spend those brain cycles focusing on your user and building a great product. Choosing Sign in with Apple is great for Apple users.

Re: Face ID and Touch ID for the Web

#188

Post by BHSPitMonkey »

dzhiurgis wrote: post #130
anuila wrote: post #114

Earlier quoted context omitted.

I don’t know what I’m talking about, but isn’t the Secure Enclave already a solution to this? Fido cards just sound like an external solution that all iPhones and new MacBooks already have integrated (T2)

Sure works when you have only one computer in your life (aka almost nobody). It’s especially bad with Apple with 3 different usb standards. Contactless is the future.

What's stopping you from linking more than just one physical FIDO-enabled device to a particular site/service? Most MFA implementations I've seen already allow this, and it seems especially important if you want to minimize the pain of losing/damaging that one sacred card.

Re: Face ID and Touch ID for the Web

#189

Post by lilyball »

znpy wrote: post #183

I've come to appreciate DigitalOcean's approach on the matter. Until you configure a 2FA device (TOPT in my case) they'll send you a temporary code to your email address. So password alone is worthless, and mailbox ownership is verified on every login. Also, I made a point never to use the "login with X" feature, no matter what X is. I always sign up with my own email.

I really hate the "we're going to send a code to your email" approach because it so often breaks.

Case in point, I tried to log into Patreon earlier today, they insisted on sending a code, and it never arrived. I tried several times, no email. I have a record of every email sent to my address for the past several years regardless of spam status so I can be 100% positive they simply never sent it.

In the end I had to give up. I can't log into Patreon today, because of their insistence on sending me an email even though I'm logging in from a computer I've used many times before.

Re: Face ID and Touch ID for the Web

#190

Post by otterley »

danShumway wrote: post #173
otterley wrote: post #167

Earlier quoted context omitted.

> Apple gets to decide what they mean. (IAAL, this is not legal advice.) That's not how contract law works. There's a whole body of law around how to construe language in contracts, and it's subject to litigation and dispute if the definition isn't made clear in the contract itself. > no court of law is going to rule that they don't have the right to block Then you don't know courts very well. Such clauses are still…

> But yeah, if you use someone's services and then publicly talk trash about them? Why should they be forced to continue to do business with you? Do you really not see how saying, "businesses should be allowed to sever ties with people who say mean things" is different from saying, "the courts will decide whether or not you committed libel"? > For example, no competent court is going to allow anyone to use an escape…

> Do you really not see how saying, "businesses should be allowed to sever ties with people who say mean things" is different from saying, "the courts will decide whether or not you committed libel"?

Of course I see that. Contract law and defamation law (tort) are separate domains. A court does not have to conclude that a party to a contract committed libel in order to determine that they are in breach for making disparaging remarks about the counterparty. The layperson might (understandably) believe that the analysis would be identical, but it is not. A finding of libel under tort law requires a multi-part test which I won't elaborate on here, and there are lots of defenses, too.

> Companies with contract language like this have broad leverage to wield their power in whatever way they see fit -- because for the most part courts have not ruled that escape clauses boiling down to "we can decide to ban you at any time for any reason" are illegal or unenforceable.

I think we're in violent agreement for the most part -- I'm just saying that your characterization is overbroad since obviously "any reason" is not quite "any reason." As engineers, we should strive to be as accurate as possible in our analyses and avoid hasty overgeneralizations.

At bottom, courts aren't generally inclined to force parties to do business with each other if one of them is no longer interested, there are no promises left to be fulfilled, and there's nothing binding them to an infinite term (which courts also don't like to enforce). Apple is not a common carrier or the government, and so they're treated just like anyone else for the purpose of contract law.

Post reply on HN