Face ID and Touch ID for the Web • Hacker News Board

Re: Face ID and Touch ID for the Web

#281

Post by JohnTHaller » Tue, Oct 20, 2020, 2:38 AM UTC

lilyball wrote: post #217

gwillen wrote: post #203

Earlier quoted context omitted.

I'm curious -- do you host your own email, or use a lesser-known email provider? I am increasingly seeing failures where sites seem to be blackholing outgoing email, I suspect based on the destination domain, and unaware that they are even doing this / extremely insistent that they are not. I've gotten login-email failures like you describe from a couple of sites, and seemingly similar failures from those "email your…

I have a custom domain that uses Gmail as its mail provider (for legacy reasons related to the other users of this domain), and my Gmail account is configured to never mark anything as spam and to forward everything to Fastmail. This means that no matter what I do with my email, I can log into the gmail account and see every email I've received for years sitting in my inbox. I don't really recommend this setup, I'd r…

Gmail and most other providers will 5xx incoming mail they see as spam before it even gets to your spam settings. It's a "feature" on their end to outright block more blatant spam, but it often snags larger senders of legitimate email. Like Patreon.

Re: Face ID and Touch ID for the Web

#282

Post by tomc1985 » Tue, Oct 20, 2020, 2:39 AM UTC

ROARosen wrote: post #272

snowwrestler wrote: post #169

Earlier quoted context omitted.

It's pretty clear Epic set out to intentionally get their Apple developer account terminated so they would have standing to sue, so I would not draw too much inference from that. That said, it's generally true that any dependence on a platform is a form of risk. There are documented examples of Google kicking people out of their ecosystem unexpectedly too. Federated sign-in schemes may be a good idea if they help you…

>It's pretty clear Epic set out to intentionally get their Apple developer account terminated so they would have standing to sue, so I would not draw too much inference from that. Nevertheless, the suspension still clearly highlights the fealty you are expected to give to Apple being a dev on their platform, or else.

And neither is Epic the first nor last of the kind of people who want to pick this fight with Apple, even if they can't

Re: Face ID and Touch ID for the Web

#283

Post by RonanTheGrey » Tue, Oct 20, 2020, 2:41 AM UTC

coder543 wrote: post #72

JoeAltmaier wrote: post #55

Earlier quoted context omitted.

Biometrics fails every test for a password. 1) A password is secret 2) You don't leave copies of it lying around everywhere 3) You can change it periodically 4) If discovered, it can't be traced back to you No, biometrics can only be a username. It can never be an acceptable password.

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…

All that's well and good until companies start implementing their own FaceID then forcing you to use it [0] on the back of trusting Apple, even CALLING it the same thing.

This app linked above (my bank) contains NONE of the security you've mentioned above.

And, incidentally, for me, biometrics STILL fail every test that matters to me: If I am dead, a bad actor can still gain access to my accounts. With a password, they cannot.

[0] https://apps.apple.com/us/app/bbva-m%C3%A9xico-bancomer-m%C3...

Re: Face ID and Touch ID for the Web

#284

Post by guptaneil » Tue, Oct 20, 2020, 2:47 AM UTC

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

While there's always a risk anytime you build on top of someone else's platform, it's worth noting that it looks like Epic lied[0] about getting blocked from Sign in with Apple. There's no evidence they were going to lose access to it, even with a terminated developer account.

0: https://daringfireball.net/linked/2020/09/29/epic-games-unre...

Re: Face ID and Touch ID for the Web

#285

Post by klysm » Tue, Oct 20, 2020, 2:53 AM UTC

MobileVet wrote: post #265

drexlspivey wrote: post #129

This comes 3 days after a leak that alleged that iPhone 13 will bring back Touch ID via in-screen fingerprinting https://www.techradar.com/uk/news/move-over-iphone-12-apples...

Please please please be true. TouchID is objectively superior to FaceId, by a long shot. It is my soap box... but TouchID RARELY failed and could be activated BEFORE you had the phone in front of you. FaceID fails constantly and MUST be in view to start the unlock process. TouchID has a single failure mode (and a half) that isn't that common. Wet / dampness. Solution, dry your finger, try again. Gloves are the 'half'…

TouchID has another interesting failure mode for me that's probably quite rare: after I go climbing, my skin is so worn that it doesn't recognize any of my fingerprints.

Re: Face ID and Touch ID for the Web

#286

Post by alexmingoia » Tue, Oct 20, 2020, 2:53 AM UTC

Razengan wrote: post #83

I was just thinking: Could we replace CAPTCHA with Touch ID/Face ID when browsing a website on Apple devices? That would be a pretty quick and painless way to verify that I am, indeed, a human, with no unpaid labor involved.

Potentially, yes. Authenticators can provide a public certificate, so servers can accept attestations created through whitelisted authenticators.

This would mean being forced to use proprietary hardware or closed-source authenticators, because that’s the only way to control authenticator certificates.

Re: Face ID and Touch ID for the Web

#287

Post by sitharus » Tue, Oct 20, 2020, 2:56 AM UTC

zxcvbn4038 wrote: post #279

Last I checked Apple only supported U2F and similar in Safari - the WebKit exposed for the other iOS browsers use can’t access those features. Did that change in iOS 14?

According to the article

> Like Face ID and Touch ID for the web, security key support is available in Safari, SFSafariViewController and ASWebAuthenticationSession.

Re: Face ID and Touch ID for the Web

#288

Post by manigandham » Tue, Oct 20, 2020, 2:58 AM UTC

KMnO4 wrote: post #71

krtkush wrote: post #50

Earlier quoted context omitted.

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

As a product owner, why wouldn't I want to piggyback on the millions of dollars of R&D + security that the big companies have put in? And as a user, why would I trust my password to the website that rolled their own authentication over the big companies?

It's true that oauth is very secure but I wouldn't assume major sites are rolling their own authentication. The standard password hashing methods and workflows are all well known and implemented.

Even if the local auth system was poor, an email/password combo is simpler and faster without leaking data to social providers. There's no reason to remember which provider you used, or login to them first, or worry about loose permissions especially with future changes. It also limits the blast radius in case your social account ever gets compromised, and it's useful for completely anonymous and disposable accounts.

Re: Face ID and Touch ID for the Web

#289

Post by ogre_codes » Tue, Oct 20, 2020, 3:00 AM UTC

variaga wrote: post #229

ogre_codes wrote: post #168

Earlier quoted context omitted.

> That may be true today, but their policies are a moving target. Who knows what they'll be like in a year's time? Likewise Google, Facebook, or any site/ API that a developer deals with on a daily basis. I wouldn’t bet my company on any sign in with _____ service. I just feel the trade-offs with Apple’s sign in versus Google/ Facebook to be less bad. With any of the services, I might do something that causes me issu…

This is why (as a customer) I always prefer "yet another web account" vs. "sign-in with ____" - yes, it's a hassle to manage a different account for every different thing I use (although not much of one with a decent password manager), but I get the advantage of not risking losing access to _everything_ because . Single-sign-on means single point of failure.

I suppose it depends entirely on what the account is securing.

My bank? Needs to be pretty independent of everything else.

Some random web store or something like Kickstarter? The only reason I care about those accounts is to track orders or for the convenience of not having to re-enter credit card info. The risk of losing my Apple account because ??? and dealing with recreating those accounts is negligible. In many cases I just use guest login for exactly that reason.

The convenience accounts are the ones I might use Sign in with Apple for. The bank? Not so much. But I won't trust Google or Facebook with even the convenience accounts.

I would also use something like this Touch ID on the web feature for 2FA, particularly if the only other options are SMS or email.

Re: Face ID and Touch ID for the Web

#290

Post by tialaramex » Tue, Oct 20, 2020, 3:04 AM UTC

Overall I'm hopeful that people will actually put the (relatively little) work in to actually deliver WebAuthn on more web sites because it has both better security and a nicer UX flow. Win win. But, as to this particular article:

The code snippet elides two really important values: userIdBuffer and challengeBuffer. I get why - they're complicated and not very exciting to the intended audience. But they're also vitally important, so I think it would have been worth putting it non-zero effort.

userIdBuffer needs to be some sort of unchanging unique identifier for the user. Probably pick suitably large random values in an indexed table or something. It might be tempting to stick the row ID from your user table or similar in here, but that's actually a bad idea you'll likely regret.

challengeBuffer needs to be actual random bytes. Hey, the Javascript interpreter has... No. The random bytes need to be chosen fresh by the backend server where you're authenticating users. And they must be actual cryptographic quality randomness, not a Mersenne Twister from your utility library.