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

Face ID and Touch ID for the Web

developer.apple.com

Post reply on HN
Print view View original

251–260 of 274 posts

Re: Face ID and Touch ID for the Web

#251

Post by monocasa »

modeless wrote: post #241
monocasa wrote: post #197

Earlier quoted context omitted.

That's not end to end encryption, the key is stored in a HSM in Google's data center in that case. They can be subpoenaed for it.

I don't think you understand what the HSM does. By design, the HSM's secret keys cannot be extracted. Not by the physical possessor of the HSM, nor the manufacturer, nor designer. That is the whole point of using an HSM for this. A subpoena cannot compel the impossible.

Nearly all HSMs that store an arbitrary number of keys can be compelled to dump those keys via a special firmware update from the manufacturer of the HSM, or at very least remove checks to allow it to be used as a decryption oracle.

Apple was able to say no, because they weren't in physical possession of the HSM, which meant that they couldn't be subpoenaed for information that wasn't actually in their possession, but a judge wouldn't look as highly on google's case.

Re: Face ID and Touch ID for the Web

#252

Post by navanchauhan »

macintux wrote: post #192
pram wrote: post #186

Earlier quoted context omitted.

The magical cross device copy and paste is one of my favorite unsung features.

Unfortunately it’s been a little finicky for me, but when it works, it’s a great tool.

It works 100% of the time when I have both WiFi and Bluetooth on, when do you face problems?

Re: Face ID and Touch ID for the Web

#253

Post by GoMonad »

bfulgham wrote: post #174
GoMonad wrote: post #171

Earlier quoted context omitted.

FIDO/WebAuthn has been designed to be first factor authentication (passwordless) as well as 2FA. Though, I agree lost and stolen devices are a problem whose solution space needs more exploring than simply multiple auth devices.

This is, of course, an active thread of discussion in the WebAuthentication working group.

Can you point me to that discussion? I'd love to read more about it.

Re: Face ID and Touch ID for the Web

#254

Post by monocasa »

threentaway wrote: post #225
judge2020 wrote: post #158

Earlier quoted context omitted.

* you don't need the TPM for Windows Hello to act as your security key. I can't enable BitLocker because there's no TPM yet I have Hello enrolled as a key for GH.

You can use BitLocker with just a password, not sure why you're implying you need a TPM.

https://www.howtogeek.com/237232/what-is-a-tpm-and-why-does-...

And yes, there is a way to use it without a TPM technically, but it's not accessible by the computer's management GUIs, and you need to create custom GPOs and apply them.

Re: Face ID and Touch ID for the Web

#255

Post by jammmety »

navanchauhan wrote: post #252
macintux wrote: post #192

Earlier quoted context omitted.

Unfortunately it’s been a little finicky for me, but when it works, it’s a great tool.

It works 100% of the time when I have both WiFi and Bluetooth on, when do you face problems?

It doesn't work if both devices are connected to different WiFi networks. But Airdrop works without being connected to any AP…

Re: Face ID and Touch ID for the Web

#256

Post by selykg »

playpause wrote: post #124
untog wrote: post #108

Earlier quoted context omitted.

> But the subtlest, cleverest restriction is that webviews are forced to use an older and slower JavaScript engine. AFAIK that hasn't been true for years. WKWebView (as opposed to the old UIWebView) lets you use the full speed JS engine.

Ah, just googled it, you're right, they did eventually make the Nitro engine available in webviews. But my main point is that it's not exactly the same, they restrict certain features, and so it should never be expected that modern functionality will work in webviews just because it works in Safari.

> they restrict certain features, and so it should never be expected that modern functionality will work in webviews just because it works in Safari.

Questioning this because you were just proven wrong once, do you have a source that confirms what you're saying?

Re: Face ID and Touch ID for the Web

#257

Post by [deleted] »

selykg wrote: post #256
playpause wrote: post #124

Earlier quoted context omitted.

Ah, just googled it, you're right, they did eventually make the Nitro engine available in webviews. But my main point is that it's not exactly the same, they restrict certain features, and so it should never be expected that modern functionality will work in webviews just because it works in Safari.

> they restrict certain features, and so it should never be expected that modern functionality will work in webviews just because it works in Safari. Questioning this because you were just proven wrong once, do you have a source that confirms what you're saying?

[deleted]

Re: Face ID and Touch ID for the Web

#258

Post by goalieca »

JimDabell wrote: post #38
adamleithp wrote: post #14

The keynote a few days ago failed to mention FaceID used to opening your mac... and this video shows/mentions FaceID on a macOS11 website? Seems they missed a step here with rolling it out, or are withholding the obvious. I'm assuming the latter.

This video shows Touch ID being used with a laptop, not Face ID. The interface is generic, so it should use Face ID on devices that have Face ID hardware, and Touch ID on devices that have Touch ID hardware.

FaceID requires special cameras and infrared lighting system. Perhaps they would add that to the mbp one day but that would be a crazy leak if they showed off that capability now.

Re: Face ID and Touch ID for the Web

#259

Post by motohagiography »

someguyorother wrote: post #239
motohagiography wrote: post #73

Linking biometrics to cryptographic authentication is difficult. When I worked on this problem about 5-6 years ago somewhere else, it came down to adding a separate applet for the biometric verification to the secure element, which then authenticated itself to the user authN applet, which was then authorized to generate the user authentication cryptogram. Biometrics are probabilistic samples of data, where cryptograp…

There are ways to use error-correcting codes to turn probabilistic samples into deterministic ones and mix them with a key. These are constructed so that you gain no information if you only know the key, or only know the biometric. See https://en.wikipedia.org/wiki/Fuzzy_extractor .

Great papers linked from that. At the time, it seemed the sensor APIs didn't provide a key with sufficient entropy to be considered a cryptographic verification for the tokens we were using. We didn't take it further because the entropy of the biometric sample was going to be diminished by using it to generate a static key, even though the papers linked show you can compose a key with error correcting codes, and intuitively, you could use some kind of probabilistic filter to verify a set of bits in the sample via shamir secret sharing to provide a threshold for a key. It still relies on separate security domains between the biometric sample collection and the cryptographic verifier, and we'd be deep in to the engineering over the differences, but these papers are really useful for getting into the details. One of the early ones was a good intro to it: http://people.csail.mit.edu/madhu/papers/2002/ari-journ.pdf

Re: Face ID and Touch ID for the Web

#260

Post by jacobr1 »

EGreg wrote: post #130
jacobr1 wrote: post #123

Earlier quoted context omitted.

With passwords, the "proof" or "attestation" is that nobody knows my secret password. In practice this tends to be weak. Some reasons this is so includes: - the password is low-entropy/complexity, so it is guessable or brute-forcible. - the password is typed into the system, so keyloggers might observe it - the password might be stored insecurity by the server - the password is transmitted over the network and might…

Sure but how is that different from JUST logging in with touchID or faceID? Without attestation?

There is no mechanism for that. The biometric hardware is local to your machine. I suppose the hardware could emit a "biometric fingerprint" that is transmitted to the server. And if anyone acquired your fingerprint they could unlock any site. Ok, so you could add some site specific salt to the process before sending the data. This is pretty close to just having a local password manager where the master key is biometric rather than a password.

But touch/faceID aren't implemented that way. They intentionally don't expose the biometric profile, that is kept local to the secure enclave. They instead just give you access to the secure enclaves keystore. Rather than signing data you could just use uniquely generated public keys like a password, or do something like signing a websites name with a private key to generate a password.

However, these approaches don't really make sense. The advantage of public-key cryptography is that you prove who you are WITHOUT SHARING the private/secret key. This is much more secure, because it prevents threat actors that don't have access to the private key from replicating the "proof" or signing process. This is what attestation is about. You can design alternative attestation schemes, but webauthn is pretty simple.

Post reply on HN