
Face ID and Touch ID for the Web - gok
https://developer.apple.com/videos/play/wwdc2020/10670/
======
lifeisstillgood
So roughly speaking this is WebAuthn for a web site, with the iphone acting as
the dongle.

It's a really good idea. I can see there being a big demand for just
simplifying signin - I can easily see a time where it is worth not having the
hassle of managing multiple signin processes and just choosing webauth or
nothing.

Edit: to be clear this won't affect B2C sites whose monetisation is based on
getting as many people as possible. But imagine a saas business charging
upwards of 100 bucks a month - they have something valuable to protect, and
the security story just got a lot easier

~~~
monocasa
Webauthn actually fully supports this model as "platform authenticators", ie
hardware security modules built into the client system. You see this on the
windows side too where "Windows Hello" integrates with the TPM and acts as a
platform authenticator as well.

No need to speak roughly.

~~~
judge2020
* 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.

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

~~~
monocasa
[https://www.howtogeek.com/237232/what-is-a-tpm-and-why-
does-...](https://www.howtogeek.com/237232/what-is-a-tpm-and-why-does-windows-
need-one-for-disk-encryption/)

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.

------
jacobr1
This really is just bringing WebAuthn to Safari. I've been using it via chrome
w/ TouchID for our corporate okta SSO and it has been working great.

WebAuthn is really just a way to make public-key/private-key crypto scale. The
user never really knows about or interacts with the keys.

The website doesn't store a password, they store a public key.

The user doesn't know about the private key (paired to the public key) they
just know how to unlock the private key via the yubikey or biometric device.

The site sends some data to the user to sign, and they do so with the private
key, then the site verifies the data was signed by the private key, boom:
authenticated.

~~~
cactus2093
How does this work if you need to sign in to a site on a borrowed computer
while traveling or something? Is the private key derivable from a master
password or something?

~~~
sirn
Similar to how you would sign in on devices/browsers without WebAuthn support
or don't have physical token (Yubikey/etc.) with you: use a fallback method
provided by a website. This is usually TOTP or a scratch code. The website
need to implement it though.

One thing to keep in mind is this is not supposed to be the only factor
required to sign in. It should be used as a 2nd factor in the similar way to
TOTP (but with much better usability).

~~~
Skunkleton
With Okta (since gp mentioned it), you would sign in with a password, then
click the "yes its me" button on your phone, or you could use TOTP, or even a
yubikey.

~~~
sirn
Okta is more of a SAML/OpenID Connect thing with built-in multi factor
authentication than a replacement for WebAuthn, though. Okta could embrace
WebAuthn Platform Authenticator as one of their authenticating factor if user
is unwilling to install an app, but a website isn't expected to use Okta as a
second factor in their authentication flow.

~~~
jackson1442
OP is referring to how you already can sign in to Okta as a website, not as an
authentication mechanism. You can create a sign in flow that goes like so:

username -> password -> [ WebAuthn | Okta Verify Push ]

This approach can be used on any website, just with a regular TOTP code in
place of the proprietary Okta Verify Push.

~~~
sirn
Ah I didn't know you could do the Okta push without using their whole SSO
suite. Thank you! I guess in this scenario Okta acts more like Authy
proprietary OTP thing then.

------
noodlesUK
One of the reasons this is so important is that it makes it far harder to
phish people. The webauthn APIs include the web origin in the authentication
process, so it’s not possible to use something like modlishka to phish people.
If we use magic links or something similar like a QR code for adding new
devices, or more users also have roaming authenticators with PINs, webauthn
will massively massively reduce phishing success where it’s implemented, as
it’s pretty easy to make website that doesn’t have phishable credentials at
all.

------
zuhayeer
Interesting, Apple is letting you change your default web browser with this
new iOS version, but also adding Face ID and Touch ID to Safari.

Why would anyone want to build these features if they're so platform / browser
specific? Does anyone know if these auth features might work on other browsers
on iPhone?

~~~
aaomidi
There isn't a reason it wouldn't work - the browsers all use the same engine
anyway.

~~~
playpause
This isn't really true any more. Apple requires their competitors' browser
apps to use a 'webview' to display websites, and Safari does not use this. The
iOS webview may share a layout/paint engine with Safari, but it is heavily
restricted in other ways. Apps with webviews (like Chrome for iOS) can't have
extensions, for example. But the subtlest, cleverest restriction is that
webviews are forced to use an older and slower JavaScript engine. This ensures
that websites feel a little slower in Apple's competitors' browsers. Another
major upshot of this is non-Apple browsers can't offer the same modern
JavaScript APIs to websites as Safari can. For example, last time I checked,
'getUserMedia' was not available on iOS outside Safari, meaning non-Apple
browsers can't support web-based video conferencing tools like Jitsi. This
also implies that websites running in non-Apple browsers won't necessarily
have access to the APIs necessary request Face ID sign-in, unless Apple
decides it is in their interests to make this available to webviews.

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

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

~~~
selykg
> 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?

------
GekkePrutser
Great to see Apple is focusing on Webauthn this time instead of rolling
something themselves that only works inside their walled garden.

Android is doing the same thing: Android phones are now also capable of being
a FIDO2 authenticator for Webauthn.

Now what we need is many more sites actually offering it :) I'm already using
it for Office 365 but that's really the only one so far that I use that offers
it.

------
_jal
Going to have to give serious thought to where I will and won't use this.

There are a lot of implications - no ability to automate and giving others
data on you were provably in front of some machine are two big ones.

~~~
thephyber
From the server side, isn't this just a WebAuth integration?

How does the server know for sure if the client is on an iOS Safari browser on
an iPhone with FaceID or a custom browser on any OS and any non-locked-down
hardware being run with Selenium?

~~~
blintz
Attestation. If a website requests it, the device will provide cryptographic
proof that you used a specific vendor’s device to store the resident
credential. The proof is a certificate signed with a vendor’s secret
attestation key.

~~~
Siira
Can't the key get stolen if it's on the client?

~~~
amluto
Yes, but it’s probably stored in the Secure Enclave, so it’ll be hard work.

~~~
bfulgham
Correct. The key material is stored in the Secure Enclave.

------
StavrosK
If anyone wants to deploy this server-side, I made a Django library that's
very easy to use:

[https://gitlab.com/stavros/django-
webauthin](https://gitlab.com/stavros/django-webauthin)

You can see a demo login here:
[https://www.pastery.net/](https://www.pastery.net/)

It allows the user to log in without a username or a password (untested on any
Apple device as I don't have any, please file bugs if it doesn't work).

~~~
zhoujianfu
Hmm, on an iPhone it asked me to hold my authentication device near the top of
the phone, it didn’t use faceid at all... :/

~~~
aeontech
Are you on the new OS seed build?

~~~
kalleboo
I get the same thing, and I'm on the iOS 14 beta

------
nimbius
I dont see a problem with this as part of MFA, but here in the US our fifth
amendment protections are pretty lax, and only cover passwords (sometimes). If
the police wanted to force your fingerprint or face ID to log into a website
(say, maybe a protest message board), they can do it just the same as they can
force your blood draw during a DUI with a warrant from a judge.

~~~
nojito
The only way they can do that is with a warrant and if you own the website.

------
echeese
I got a Yubikey earlier this year and was disappointed by Apple's
implementation of WebAuthn it (doesn't work if there's a PIN on the device)
but it looks like they're fixing that as well in iOS 14

~~~
0xCMP
I'm hoping it works with NFC and not just the lightning one.

Would be nice to have Yubikey replace my password and then allow me to enroll
FaceID so I can keep signing back in.

~~~
echeese
The current Yubikey works with NFC on iOS, it just doesn't work if you add a
PIN to it (which Windows Hello requires). They mention that they added PIN
support in the changelog

------
theboat
If the web migrates to biometric sensors for authentication, I hope this won't
suffer from vendor lock-in. When every new device ships with facial
recognition and/or a fingerprint reader, it will be nice to login using my
face/fingerprint irrespective of the device I'm on.

~~~
Spivak
I don't see how this could ever be something not vendor-specific because
without this being tied to "Log in with Apple" you're just saying "trust the
client."

Maybe that's fine if all you want is to "lock" a sensitive page to people who
aren't the device owner but that's pretty limited compared to FaceID to
actually log in.

~~~
tialaramex
It has no relationship to "Log in with Apple". It's a WebAuthn authenticator.

Almost all web sites should just implement WebAuthn. On a suitable iPhone or
Mac users will be able to sign in by touching the sensor or looking at the
camera, while on my Pixel phone I touch the fingerprint sensor, on this Linux
desktop I touch a Yubico Security Key.

 _If_ your site is paranoid that some crazy user will choose a bad WebAuthn
authenticator, or deliberately sabotage their own security for some reason,
then you can use WebAuthn Attestation to obtain a signed document from the
authenticator (yes, over the Web) which proves that it is, for example, an
Apple iPhone 25 Super Mega Plus. I don't think you should bother doing that,
but you can.

------
supernova87a
So for the non-developer, is this basically as if any participating website
could send an 2FA request to your iPhone (like the role of the SMS code but
more secure), have the iPhone verify you by face/touch, and then confirm back
to the website and let you in? (also like Google does with their app?). Or
even take the place of a password?

~~~
tialaramex
Done the way Apple describes it this (optionally) replaces the entire login
sequence. Username, password, second factor, all replaced by tapping one
button.

When you register for this feature, your Apple device gives the site an ID (a
really huge random-looking number) and a public key. The site associates this
ID and key with your user.

On subsequent visits you do something (e.g. press "Face Sign In" button on the
site) and then your device authenticates you (with Face ID/ Touch ID) and if
you pass it sends the same ID, and some signed stuff about this
authentication. The site matches the ID, finds your user, checks the signed
stuff is OK with the public key is stored before, and you're in - no other
steps and very secure.

WebAuthn can do simpler journeys that only replace the second factor or as a
single factor but with the user still needing to provide their username first,
but Apple is pushing developers to have this lovely journey that suits the
Face ID/ Touch ID experience on an Apple product.

------
hubert1234
Sometimes it feels like I'm the only one that doesn't trust biometric sensors.
I mean it's basically magic. If for any reason the face detection algorithm
doesnt match your face anymore you have the equivalent problem of losing the
master password to your entire password store.

~~~
Cogito
It's a little different, I think.

You _could_ have it set up where your face is the one-and-only thing that
identifies you, but that doesn't seem to be the case in practice.

Instead, we have the multipart authentication used in many places today:
something you know (password), something you are (biometric fingerprint/face),
and something you have (your physical device, your email account, your phone
number).

Any one of these has downsides (stolen password, biometric misidentification
or duplication, redirected phone number) but in combination with the others
makes it much harder to circumvent authentication.

Almost all systems have some kind of fallback that rely on a 'something you
know' like a master password, and can optionally only be changed if you have
other authentication methods (like physically having the device in your
hands).

Having multipart authentication allows for a better user experience (look at
your phone and it unlocks) with an acceptable amount of risk (you have to have
your phone and be you in order to unlock it), with systems to fallback to if
something fails (get the super secret password off that slip of paper you hid
in your mother-in-laws garden shed behind the loose brick in the wall). The
typcial authentication flows are both more secure and more convenient, and the
user is responsible for the security of the backup.

------
motohagiography
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 cryptographic verification
requires deterministic inputs. They are apples/oranges and that's what made
this hard, so you need a connector for them. The attack on such a scheme means
spoofing the biometric authenticator's validation message to the cryptographic
authenticator, which, if this all occurs between applets on the same secure
element, raises the bar for attacks.

~~~
someguyorother
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](https://en.wikipedia.org/wiki/Fuzzy_extractor).

~~~
motohagiography
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](http://people.csail.mit.edu/madhu/papers/2002/ari-journ.pdf)

------
aarongray
A fingerprint can be a personal password or it can be a government ID, but it
can’t be both. Since the U.S. government already has something like 200
million fingerprints on file, and many foreign governments collect
fingerprints whenever you travel, these fingerprints are sometimes leaked en
masse
([https://en.wikipedia.org/wiki/Office_of_Personnel_Management...](https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach#Theft_of_fingerprints)),
and because they can never be changed, biometrics aren't my personal choice
for a secure method of authentication.

~~~
hn_throwaway_99
But I think you missed the point about the second factor, because there are
really 2 factors here:

1\. Something you have (e.g. your phone, in this case the Secure Enclave that
stores the private key).

2\. Something you 'know', e.g. your fingerprint.

Just having the fingerprint itself is not sufficient.

~~~
aarongray
That's a good point that it is more nuanced. The issue I think is that
organized crime and unscrupulous governments are getting better at connecting
these things so they are not as cleanly separated as they have been in the
past. Just look at China. Essentially spyware and viruses are installed at
checkpoints on people's phones and biometric tracking is becoming very
commonplace. I don't think it will be long before organized crime begins to
get better at this too. As such, being able to change that "something you
know" is a very powerful countermeasure.

------
sytelus
FaceID is one of the most important technology invented. Imagine if Apple
somehow was open to license it and make it universal like Bill Gates wanted to
make PCs universal. It can make driver licenses, passports, credit cards,
student IDs, insurance IDs - all of these can be things of past. You go to
grocery store and simply pay using your face. You want to pay online? Simply
look at FaceID device that is now standard with all new computers sold. This
is 100s of billions worth of business to make so much legacy gone. Security
and identity is now (hopefully) solved but unfortunately still all behind
walled garden.

~~~
jsf01
Why did fingerprinting never catch on in that way? That tech has existed for
ages. Way cheaper to implement as well. Seems like it would also be less prone
to false positives compared to facial recognition, but that’s just speculation
on my part.

~~~
searchableguy
Touch ID has been hacked multiple times. It's not reliable.

0] _The probability that a random person in the population could look at your
iPhone or iPad Pro and unlock it using Face ID is approximately 1 in 1,000,000
with a single enrolled appearance. As an additional protection, Face ID allows
only five unsuccessful match attempts before a passcode is required. The
statistical probability is different for twins and siblings that look like you
and among children under the age of 13, because their distinct facial features
may not have fully developed. If you 're concerned about this, we recommend
using a passcode to authenticate._

For comparison, touch ID has a probability of 1 in 50,000.

0] [https://support.apple.com/en-in/HT208108](https://support.apple.com/en-
in/HT208108)

------
theogravity
I wonder what part of the Web Auth APIs does iOS Safari support since MDN says
most of the APIs are not supported.

[https://developer.mozilla.org/en-
US/docs/Web/API/Web_Authent...](https://developer.mozilla.org/en-
US/docs/Web/API/Web_Authentication_API)

~~~
jedieaston
I think that this is coming in the next release of Safari, so MDN is correct,
it's not currently supported.

~~~
alanwaketan
WebAuthn API is supported in WebKit starting from Safari 13 and iOS 13. The
MDN chart needs to be properly updated.

~~~
madjam002
Hardly, it only supports basic MFA scenarios with a cross platform
Authenticator.

User verification + resident keys were never implemented in Safari 13.

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

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

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

------
ixtli
Anonymous attestation is really interesting because, afaict, there really
isn't a way to do this right now if my application wants to authenticate a
"normal" user with a "normal" phone.

------
gorgoiler
Isn’t this a classic example of the fragility of biometrics?

If I move to a new device, iOS should be required to give up whatever secret
key my face translates to, so I can log into websites.

Simplistically, if iOS silently turned my face into the web password
“g0rG0il3r”, when I eventually migrate from iOS to something new, I’ll have to
be able take my face password with me, thus exposing that my face was only
ever equivalent to a password in the first place?

~~~
snuxoll
WebAuthN is not supposed to be the only way you log into a service. The
credentials are permanently tied to your Authenticator of choice, which can be
lost or stolen at any time.

If you change devices you just provision the new one for your account after
signing in with a traditional username/password(/2nd-factor).

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

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

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

------
irrational
My company recently started using Okta. This is the first time I've heard of
webAuthn. Is there any relationship between Okta and WebAuthn?

~~~
lukeramsden
Not as far as I'm aware, WebAuthn is a standard, and Okta is an authn
provider. You can use WebAuthn with many other things, like the Yubikey.

------
jiveturkey
This has been a very long time coming. Apple finally joined FIDO in Feb of
this year, so we knew it was right around the corner.

------
xvector
I think it's pretty ridiculous that Apple pours time and effort into stuff
like this but apps have been able to steal from your clipboard for years.

It reminds me of the phenomenon when researchers and engineers don't work on
something that's useful for everyday users, instead prioritizing what they
find exciting and cool. The security team is so busy dealing with absurd edge
cases like nation-states attacking your enclave that they don't seem to care
to address egregious and obvious holes in the security model like this.

It's not that WebAuthn and passwordless isn't exciting or useful, it's just
that there are much bigger fish to fry (clipboard paste, terrible permissions
management, non-shitty VPN support, trackers in apps) that Apple seems
completely uninterested in addressing.

There really is no excuse, at least not when you're tooting the
privacy/security horn so loudly, but let stuff like this pass by.

Edit: have y'all thought of an actual counterargument instead of just
downvoting? Is it really too much to ask security engineers at Apple to focus
on actual major privacy holes in their OS than things like this?

~~~
_fzslm
i don't want to focus too much on why i think you're being downvoted but i
would say it's probably because your message came across as quite reductive.

> engineers don't work on something that's useful for everyday users, instead
> prioritizing what they find exciting and cool

i get this, to some extent. i really do. but i don't think WebAuthn, sign in
with apple, ios 14's recent microphone and camera usage indicators, etc. are
not huge steps forward in terms of mobile privacy & security. (rough double
negative. you get me.)

i am pretty sure Apple knows about everything you stated, and would wager they
are developing, or at least R&D'ing, effective, polished, "Apple" solutions to
these problems.

clipboard is a bit of an obscure one, but is absolutely a problem and must be
addressed. but Apple is in the business of juggling user experience and
privacy. it's quite difficult, because you don't want to get in the way of the
user's intents and make things way hard to do. but you also don't want to make
things so easy that bad actors can get away with bloody murder.

granted, they still can, if they really want, but it's way harder. and slowly
apple is killing the mice. it's a cat and mouse game. i think they're doing
exactly what they should be.

could they be doing more? hell yes. they should -always- strive to do more.
but right now, this is better than last year, and the year before that, and
the year... yknow.

~~~
xvector
> i don't think WebAuthn, sign in with apple, ios 14's recent microphone and
> camera usage indicators, etc. are not huge steps forward in terms of mobile
> privacy & security.

For sure, but they are far less needed than the described issues. You see, the
problem is that these holes have existed in iOS for a long time and affect the
practical security of the everyday users.

WebAuthn is definitely the future of the web, but why can't we fix the giant
holes in the ground before building upon it?

This goes back to the problem of researchers focusing on things that are
exciting and will be the future, but not focusing on the needs of the everyday
customer. This was the downfall of RCA back in the day.

> Apple is in the business of juggling user experience and privacy. it's quite
> difficult, because you don't want to get in the way of the user's intents

I understand this struggle. Still, most users are horrified when they learn
that everything they've ever copied has been shared with the apps they are
using. Even the layperson would gladly give up some trivial auto-paste feature
if they knew this.

I would understand Apple's slowness to respond if this was a recent issue, a
newly-discovered hole in privacy. But this is a big thing. It's been around
for years. And many others have too.

Apple has engineers, they have PMs, and those engineers and PMs are working in
the same problem space with these holes. But new features that won't matter
for years are being prioritized over major issues that have existed for years,
and that's not cool, not when you are yelling that you care about privacy from
a mountaintop.

------
tectec
Does anyone know if iOS devices support multiple users/bio metrics per device
and could log a specific user in when they are using a shared device? I'm
wondering if this could be used for a shared iPad on a factory floor to log
users into their own account on our web app.

~~~
jacobr1
Since we are really talking about WebAuthn and not just the iOS
implementation, You probably could use alternative hardware (maybe android
based) that supports the multiple-user biometric use-case. From the
server/web-app side it still would just be WebAuthn.

Looks like you use a separate device like this:
[https://www.ftsafe.com/Products/FIDO/Bio](https://www.ftsafe.com/Products/FIDO/Bio)

That supports fido2, hooked to any tablet to make it work.

------
EGreg
What exactly does attestation do vs not having it? Can someone here explain
clearly?

~~~
jacobr1
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 be intercepted \- the
password is transmitted over the network, possibly to unintended recipients
(like a phishing site) and thus is intercepted.

One alternative is employing public-key/private-key crypto. The server sends
some random data to the user. The user signs that data with their private key
(this is the attestation part). Only the signed data, which is generated for
this single authentication attempt is transmitted. And during registration
only the public key is transmitted. The public key is used by the service to
verify the attested data. The private key remains secret the entire time.
Likely it remains secret even to the user's machine because it lives in
separate hardware, such as a yubikey or secure-enclave. The key is also
something that isn't going to be guessed because we are using modern algos
with large bit-sizes.

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

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

------
tonyhb
Called it, but it took longer than expected:
[https://news.ycombinator.com/item?id=18141918](https://news.ycombinator.com/item?id=18141918)

The Safari team do move slowly.

------
apl002
I miss touch id. Face ID is one of my least favorite things apple has done

------
elwell
1Password users can already have effectively the same experience.

~~~
toomuchtodo
Apple users will get this natively without having to acquire 1Password. If
you’ve bought into the Apple ecosystem and don’t have needs outside of it
(Windows, Linux), you can eliminate the need for a separate password manager.
Similar to how iCloud Files is moving towards (but likely won’t meet, while
not needing to) Dropbox parity.

This is making a friendly version of Yubikeys (using Apple devices) and
password vaults for Apple users.

~~~
WA
For interested readers: 1Password does a few more things. For example, you can
add 2FA to 1Password logins, so that 1Password replaces Google Authenticator
with the immense advantage that you don’t have to setup 2FA again if you get a
new device.

Just a happy 1Password user, nut related to them in any way.

~~~
sygma
Is it really 2FA if your password and your token are on the same device?

~~~
sirn
One could argue that authenticating via 1Password is already multi factor in
itself e.g. Master Password is Something You Know as the first factor and
access to a 1Password Vault is Something You Have as a second factor (since
you cannot login to 1Password with just username and password, but also
requires a Secret Key that can only be acquired from a device that already
logged in).

In this case TOTP acts more like an insecure one-time session key.

------
erickhill
Unfortunately Face ID has become much less useful since many of us began using
face masks. I wish I had touch ID back on my iPhone.

------
gmantg
There's surprising support here for the faceid stuff, despite it's clearly
made to normalize using biometric data for everything and make one step
towards the survelliance state. But let's pretend we are more concerned with
security of this approach: how is it better than a ring with a chip you'd wear
and use for auth? If this identity is compromised, you could just get another
ring. And you wouldn't need to give your real identity to apple.

~~~
threentaway
All biometric processing happens locally. You aren't sending your fingerprint
or face, they simply unlock the private key in the enclave.

~~~
gmantg
Sure, at this point Apple's solution likely works this way: they care about
their reputation. But even a secure faceid opens the Pandora box: today it's
just iPhone users, 5 years later it's everywhere, including in solutions from
Huawei and 10 years later it's the law. Afaik, Delta airlines already trying
to use faceid. And once faceid is required to buy gas and groceries, your
complete and nuanced dossier will be available for sale on all these data
exchange brokerages. In this beautiful future, faceid is needed to unlock any
car and it would play you ads for 3 mins while it's starting.

------
EGreg
Can a person have more than one account?

Does google have a similar thing?

Because overnight we can finally stop sybil attacks! Right?

------
buoyantair
I wonder how these face detection algorithms work for transgender folks...

~~~
fiblye
Unless they're getting extensive facial surgery, their phones will acknowledge
them.

------
zaroth
Apple is considering this to be multi-factor authentication all in one click,
the something you have (the phone) and the something you are (FaceID or
TouchID). For the site perspective, if you ask for attestation then you will
have cryptographic evidence of this. No more SMS 2FA!

Apple is promising to do something extra with their attestation process which
they call "Apple Anonymous Attestation" to mitigate the issue where
attestation allows tracking the same device across different websites even if
they are using different usernames. Not included in the current release, but
"coming soon".

The process of enrolling an authenticator is presented as a "one and done"
event, but of course the devil is in the details. Shared accounts would need
multiple authenticators, and what happens when you upgrade your phone or lose
your phone? I guess this gets handled like a password reset. You probably will
want users to be able to add/remove authenticators, which means also having to
name them.

The enrollment process in this video highlights the upgrade path from a
password login to a FaceID/TouchID login, but doesn't give us the UI flow of a
new login. It seems like sites would need to implement a standard registration
page and then perhaps swap out the password field with a Next button which
would prompt for the FaceID/TouchID enrollment. Makes me wonder how does this
compete with or tie into the 'Signin with Apple' if a site wants to offer one-
click registration?

Will my Mac and iOS devices automatically and securely sync the private keys
between their respective Secure Enclaves so that I can signin from any of my
devices after enrolling on just one?

Lastly, how about the case when returning to a site where the user is on their
enrolled device, but there isn't a cookie present. It looks like the site can
detect that the device supports Webauthn, but I'm not sure if it can
automatically detect that the device already has an account enrolled with the
site?

The call to 'credentials.get' includes the 'credentialIdBuffer' which is a
value provided by the platform authenticator and saved during registration.
But in the video they make it sound like 'credentialIdBuffer' is actually
optional? It's not even clear to me in the official WebAuthn spec [1] if this
value is required, or if the authenticator will just use the RP domain to
present the user a list of available credentials? Ultimately I'm wondering if
a user without a cookie will still have to type in their username before the
site can prompt them for FaceID/TouchID authentication.

[1] - [https://w3c.github.io/webauthn/#dom-
publickeycredentialreque...](https://w3c.github.io/webauthn/#dom-
publickeycredentialrequestoptions-allowcredentials)

~~~
tialaramex
The value is not required, that's why it says "OPTIONAL" in capital letters at
the link you gave.

WebAuthn has two scenarios. For something like an iPhone or a Windows laptop
we can choose to have the device store a heap of credentials mapped to domain
names. So your Safari sees this is cat-videos.example and the iPhone knows
credentials for cat-videos.example so .get() fetches those credentials without
needing IDs and the site doesn't (if it does things this way) need to ask for
a username first. This is called "resident key" because the device remembers
which keys it has and you can have your site say during registration that you
prefer this outcome, or even that you _insist_ upon it by setting it as
"required".

The other scenario is older and very clever, it is used for things like a
cheap FIDO USB dongle. It stores nothing, the device doesn't know who you are.
This means it cannot provide that seamless "no need to enter your username"
UX, however it does work well as a second factor and can be used as a sole
factor if you want. How can it work if the device doesn't remember
credentials? Well the WebAuthn ID is deliberately big enough to "hide"
encrypted keys inside it. Instead of remembering your credentials after
registration like this Safari feature, a cheap FIDO dongle encrypts the
private key it'll need and then gives that to the web site to store as an ID,
alongside the public key. When you give the site your username, it fishes out
the IDs associated with your user and hands those to get() in that buffer you
spotted. The user's web browser shows these IDs to any FIDO dongles and if one
of them made that ID it can decrypt it successfully and authenticate you.

So the overall answer to your question is: It depends.

The cheapest simplest WebAuthn setup uses it only as a second factor and would
need a username every time.

A very nice UX focused on being as seamless as possible for Apple users
wouldn't need a username unless you're using a device you haven't authorised
this way before. The video shows such a UX because that's what Apple wants you
to do for their users.

------
paxys
Happy to see Apple following an established standard for once.

------
coronadisaster
Face or finger data is akin a login name... What is the password in that case?
Because if you cant change your password, that could be a problem

~~~
EtienneK
The biometric data never leaves your device. Your biometric is only used to
unlock a private key stored in the secure enclave of your phone. This private
key is then used to sign a server-sent challenge. The phone sends this signed
challenge back to the server, where the server can validate it using the
public key.

The public/private key gets generated by the phone upon first registration
with the server.

~~~
coronadisaster
So if someone has your phone and your face, not only can they unlock your
phone but also the services that you are using?

------
exabrial
Face Id is a terrible idea in the age of westerners wearing masks or south
Asian countries

------
LockAndLol
The last I read, if you wanted security then Face ID and Touch ID definitely
weren't the way to go. I'd rather see Apple pick up something like SQRL[0]
than continue down this path of pseudo-security. They work, but it's like
having a half-blind doorman who can't tell if you're wearing a mask or if it's
your real face.

0: [https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

~~~
jmull
> The last I read, if you wanted security then Face ID and Touch ID definitely
> weren't the way to go.

Sounds vague and overly general. I don't think anyone can take this seriously
without some more information.

~~~
LockAndLol
You are but a duck-search away

Face ID defeated with glasses and tape
[https://appleinsider.com/articles/19/08/08/face-id-
security-...](https://appleinsider.com/articles/19/08/08/face-id-security-
defeated-with-glasses-and-tape)

Touch ID defeated by lifted fingerprints

2013: [https://arstechnica.com/information-
technology/2013/09/defea...](https://arstechnica.com/information-
technology/2013/09/defeating-apples-touch-id-its-easier-than-you-may-think/)

2016: [https://appleinsider.com/articles/13/09/22/apples-touch-
id-a...](https://appleinsider.com/articles/13/09/22/apples-touch-id-already-
bypassed-with-established-fake-finger-technique)

2019:
[https://www.forbes.com/sites/daveywinder/2019/11/02/smartpho...](https://www.forbes.com/sites/daveywinder/2019/11/02/smartphone-
security-alert-as-hackers-claim-any-fingerprint-lock-broken-in-20-minutes/)

Biometric "security" on phones is a gimmick.

~~~
jmull
These demos are useful to help understand the limitations of these security
measures, but hardly invalidate them.

E.g. from the first article you linked:

> the attack is only really useful against unconscious victims, requiring both
> physical access and the tricky move of placing glasses on their face without
> waking them up.

All authentication mechanisms have limitations, BTW.

------
EGreg
Just to state the obvious...

Biometric data must always stay on your personal device in order to be secure
from replay attacks, not to mention finding out more about you.

[https://amp.theguardian.com/world/2019/sep/04/smile-to-
pay-c...](https://amp.theguardian.com/world/2019/sep/04/smile-to-pay-chinese-
shoppers-turn-to-facial-payment-technology)

Of course, in Apple’s implementation, the data never leaves the device. Which
is far better than, say, how facial recognition is used in China for payment
where the merchant is the one operating the machine which scans your face.

~~~
marinhero
The video mentions the data never leaves the device and that the transaction
is performed in the secure enclave of the phone.

------
BiteCode_dev
Giving my finger and face prints to the browser, the software with the biggest
attack surface in the world, connected to internet no less, feels off to me.

~~~
brandonhorst
All of that is managed by the Secure Enclave in exactly the same way that it
is for all over auth on Apple devices. The browser doesn't touch it at all.

~~~
thowawaymom
Oh the almighty Secure Enclave, bow down to the Enclave...

Do you even know what the heck an enclave is and how does it work? It's nuts
that when a figure of authority uses a fancy shiny new word to describe some
magic black box and the masses follow with no questions asked.

~~~
orf
Do _you_ know how it works?

~~~
thowawaymom
That's the _point_ , not many do

~~~
sosborn
This might help: [https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-
De...](https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-
The-Secure-Enclave-Processor.pdf)

------
barbegal
This isn't that revolutionary: LastPass already allows you to use biometric ID
to authenticate and it works without any changes to the website.

~~~
jrockway
It also doesn't add any security. Your password can still be guessed or
phished. When authenticating with a cryptographic token (U2F/WebAuthn), that
vector goes away. (Even OTP can be phished... the phishing site can just ask
you for the code.)

Password managers do make it more difficult to get phished, since they will
not know what password to autofill on phishing.example.com... but on the other
hand, password manager users are used to having to force-fill a password. I
have to take my password out of LastPass to log into Battle.net or Fusion 360,
and websites like the Wall Street Journal create your account on dowjones.com
but require you to log in on wsj.com (or maybe it's the opposite, I forget).

With WebAuthn, more care is required for both the site operator and the user
(have more than one way of logging in in case you lose your phone, make sure
the enrollment and login origins are the same), but you are then open to fewer
attacks.

~~~
amluto
WebAuthn is less phishing resistant than it should be. The original intent was
that WebAuthn + token binding would ensure that, even if an attacker obtained
a fraudulent certificate for a victim site and had an MITM position on the
network, the attacker still couldn’t steal a WebAuthn protected session. Alas,
Chrome removes its token binding implementation, and WebAuthn no longer has
this property. If you authenticate with WebAuthn, and there is a MITM, the
MITM gets your session.

(Conventional phishing is still prevented. If you go to, say, g00gle.com, the
owner of g00gle.com can’t reuse your authentication to authenticate to
google.com. But this relies on your browser actually knowing what domain it’s
looking at, which relies on the CA system.)

~~~
tialaramex
The WebAuthn specification still explains how you could get token binding if
it's present, it's just that it isn't present on any major implementations
today.

I'm not sure I believe that real bad guys can successfully attack the Web PKI
yet would be foiled by a site using token binding. I think crooks
sophisticated enough to burn an exploit to get themselves a fraudulent
certificate and put themselves on path for the main attack probably just break
into the actual target web server and dispense with everything else entirely.
I'd welcome token binding as an option, but I expect I'd never use it in my
software.

~~~
amluto
If you include attackers who control an organizational MITM CA in your threat
model, then this could be a big deal. If I were, say, a bank, I would like
WebAuthn to protect me against compromise of an organization’s MITM box. Token
binding can do this to some extent.

~~~
tialaramex
Surely in most MITM box scenarios the token binding just isn't possible?

The only correct MITM box design for TLS is back-to-back client and server,
and with that structure there are two TLS channels instead of the one you
expected so you can't bind anything to "the" channel between your client and
the destination server as there are in fact two channels.

Hacks to try to do something else invariably break and make everything worse.
The resulting wreckage for TLS 1.3 took a year of engineering plus an extra
year of whining MITM box owners reluctant to stop doing broken crap. We
certainly don't want to encourage more of that.

------
mtgp1000
No way this biometric data could possibly be abused, right?

I'll stick to taping over my cameras, thanks.

~~~
empath75
it never leaves your phone.

~~~
mtgp1000
Yeah, and my personal data never left Equifax's servers either.

You can't change your biometrics when they are inevitably hacked. If you even
find out.

~~~
monocasa
For all Apple's faults, they're pretty open about how their Secure Enclave
works. I think they consider privacy to be a key differentiator, particularly
when compared to Android and Windows. you can see this in how they didn't open
a phone even given an FBI request.

~~~
kohtatsu
They didn't develop the capability to backdoor phones at the FBI's request.

They are generally happy to hand over iCloud backups, which they did in that
case and the FBI "lost" them IIRC.

It was also an iPhone 5c, the last iPhone without a Secure Enclave, I believe
they were able to get in with GrayKey.

~~~
monocasa
> They are generally happy to hand over iCloud backups

That one they legally have to do when given a subpoena.

~~~
Dahoon
They could encrypt everything and not have the keys. So not really.

~~~
monocasa
The whole point of the backup is that you'll be able to access it even if you
your device and it's keystore are destroyed.

~~~
modeless
And end-to-end encryption doesn't have to break that:
[https://security.googleblog.com/2018/10/google-and-
android-h...](https://security.googleblog.com/2018/10/google-and-android-have-
your-back-by.html)

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

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

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

~~~
modeless
The firmware on these chips erases the keys before applying firmware updates.
I encourage you to read the detailed information available rather than just
making assumptions about it, or even just the short blog post I linked which
states this explicitly.

In the San Bernadino case the FBI had physical possession of the HSM, so Apple
could have attacked it physically. That's not related to the reasons why the
FBI gave up on that case.

~~~
monocasa
> The firmware on these chips erases the keys before firmware updates. I
> encourage you to read the detailed information available rather than just
> making assumptions about it, or even just the short blog post I linked which
> states this explicitly.

I read the blog post _and_ the third party security audit. The audit only
documents that rogue actors within Google would leave a attestation trail if
they tried to push malicious firmware and be noticed by Google proper. My
concern isn't rogue actors but Google itself. Additionally the Titan chip in
my pixel has received firmware updates without wiping it's storage.

> In the San Bernadino case the FBI had physical possession of the HSM, so
> Apple could have attacked it physically. That's not related to the reasons
> why the FBI gave up on that case.

Right, so the legal distinction between "we want a piece of information in
your possession that you have decided to lock from yourself" versus "we want
your help receiving information that we have in our possession but can't
access" is a very very big difference from a warrant perspective.

~~~
modeless
The audit report does not explicitly state that the keys are erased on
firmware update, but malicious firmware updates were specifically in scope for
the audit, and this specific attack was not raised as an issue, and the blog
post explains why. The Titan chip in your Pixel is not running the mentioned
_custom_ firmware that erases the keys on update (and malicious firmware
updates to the HSM in the phone were _not_ in scope for the audit).

It is not at all clear that the FBI would have lost if they had continued to
pursue Apple in the San Bernadino case. The distinction you are drawing is not
as clear cut as you think it is.

~~~
monocasa
When a core piece of their security model isn't backed up by the third party
audit that they literally are presenting as "don't trust us, we have a audit
covering this" (and the auditors did look at how google protects against
malicious firmware updates, hence their attestation comments), _and_ when that
would leave them being unable to update these modules without wiping
everyone's backups, _and_ the auditors found security bugs that required a
firmware update, _and_ literally the same chips are updated without wiping
when against a threat model that has a better argument for wipes on update,
I'm sorry I just don't believe the blog post.

Bringing this back to the original point though, just using an HSM doesn't
automatically mean that the manufacturer of the HSM can't access the keys.

------
thowawaymom
Oh the almighty Secure Enclave, bow down to the Enclave...

I see so many comments mentioning Secure Enclave to any security objection as
if it's a panacea. Do you even know what the heck an enclave is and how does
it work? It's nuts that when a figure of authority uses a fancy shiny new word
to describe some magic black box and the masses follow with no questions
asked.

~~~
acdha
Please don't spam the same comment

~~~
thowawaymom
I literally mentioned it one other time as a reply to a comment, that's hardly
spam (the m stands for mass, fyi)

