you're right that using biometric data for authentication is bad, but that's not what's happening here. faceid/touchid stores a private key on your device, and uses your biometrics to unlock that private key. it's the same idea as using a yubikey or something where you have to press the button on the 2fa dongle to prove it's physically in your posession and unlock the private key stored within it, but it goes beyond just pressing a button by doing some biometric identification.
the concern isn't what if the biometric data is leaked, because the biometrics are only used to allow local access to your phone. the concern is what if the private keys stored in your phone are leaked. and the secure enclave makes that as close to impossible as any other existing solution.
I know very little about security. Could you please explain it in simpler way?
So, does my iPhone create a private key (which my Face ID data) on the phone itself, then the browser ask the phone to do something to authenticate the user? I am lost here.
You can think of a private key like a really long, complicated password. Like, thousands of characters. But you don't have to type it in every time, you just let your phone store it for you and fill it in for you in apps (and now, websites).
To log into a website, your iPhone checks to see if your face is your face, and if it is then unlocks your private key to send it to the website. If it can't identify your face, then it won't enter your password.
Sending your actual facial data to a website would be bad because you can't change your face, so if you give your face to one site, then that site could use it to log in as you to other sites. But by just using it to unlock a private key, you (or apple on your behalf) can still change or de-authorize your private key, and use a unique one for each sites. Basically all the good practices you're supposed to follow when you use a password, and they aren't giving any site any special data that they could use anywhere other than their own site.
Yes. In WebAuthn every single time you enroll on some web site with this system, a completely random new private key will be generated and the site will be given the corresponding public key and a fresh magic "cookie" identifier that serves no other purpose.
Your Apple device remembers the association between this particular web site, any user ID the site said is relevant (e.g. maybe the username mrwnmonm and friendly name "Shiny Steve") the cookie, and the private key.
On subsequent visits either of two things can happen:
1. You tap some sort of easy-one-touch login button. The Apple device says "Hey, sign in here as mrwnmonm / Shiny Steve?" and you use your touch ID to prove you are still you, this unlocks the private key, Safari uses the private key to create a proof that you still know that key, attaches the proof, and the cookie. The site recognises you must be Shiny Steve and you're in.
2. You sign in "normally" (e.g. with a username and password) but then as a Second Factor the site shows the Apple Device the cookie it remembers, your device recognises this cookie and prompts you for a touch to prove you are still Shiny Steve, whereupon it uses the private key to sign a proof and send it back to the site.
Because the keys are different on every site even if two web sites deliberately work together to try to figure out if a user on one site is the same person as a user on another site, WebAuthn doesn't help them do that at all.
Also unlike passwords or most other schemes, there's no risk from mass data loss because the web site is storing public information. If a "dump" of every Facebook WebAuthn public key was made, that's essentially useless to everybody except Facebook anyway, whereas obviously a password dump or a dump of all the TOTP secrets would be a huge security problem.
Yes, it’s a unique for each site which makes webauthn extremely phishing resistant. Even on look alike domains the origin doesn’t match and your phone has nothing to send.
Your phone holds the passwords for the websites but they passwords never get presented to the user. FaceID is just used to unlock the password store. You would have to steal a phone and trick faceid on the phone to gain access to someones account.
Sorry, I still don't see the improvement here, doesn't that already happen using chrome for example, or Touch ID with 1password? (I think IOS has that too)
That's correct, but 1Password stores a static secret (the password) and this may be re-used by less security-minded folks as you probably know. WebAuthn servers only store a public key which is useless in case the server gets compromised. WebAuthn also is phsihing proof by having browsers verify the domain the credentials are used for.
the concern isn't what if the biometric data is leaked, because the biometrics are only used to allow local access to your phone. the concern is what if the private keys stored in your phone are leaked. and the secure enclave makes that as close to impossible as any other existing solution.