Face ID and Touch ID for the Web
developer.apple.com
developer.apple.com
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
No need to speak roughly.
Most sites should just not care, but it's an option if you've determined there's a specific reason it matters in your application.
Websites should not depend on JavaScript for something that should be able to be done declaratively.
(Amongst other things - we shouldn't need to use `fetch`/`XMLHttpRequest` when a <form> would work just-as-well - but if only <form> let us use more than just GET and POST, and supported more types of serialization, and supported asynchronous form submission - and bring back <keygen>!).
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.
[1]: https://www.w3.org/TR/webauthn/#platform-authenticators
General advice: If worried about losing a device, try to register more than one. Even iCloud Keychain requires other hardware for authentication... same problem applies.
Only way out is having a backup like taking ID to an Apple Store as a way to regain access... that varies right now by provider, but who knows. Maybe Login with Apple will go WebAuthn-compatible in future? (Haven’t watched this video yet.)
If you’re an enterprise and worried about key authenticity or varying WebAuthN standards, you can look for specific types of keys or even request specific serial numbers of FIDO2 dongles from the web browser, etc.
But for normal people, we do need to get more of the balance into the usability side I think. The thing with iCloud Keychain is it can comfortably be recovered without breaking the end-to-end encryption with only a single remaining device, and many Apple users have as many as 3-4 devices in the circle of trust
It seems ideally some kind of "roaming platform" additional option would be good in the webauthn standard
Typically deploying WebAuthn means that you have to put more thought into your account recovery flows - you don't want to deploy strong authentication to fall back to email or KBA-based recovery, for example. Then, this recovery may be used both to recover from a lost device as well as to just add a second device.
There are UX issues there that have to be solved yet. Also, while I haven't gotten my hands deep in what Apple has done yet I suspect this is a browser-level feature and not a platform-level feature, where say your phone would pop up a "do you want to authenticate" screen when held near another computer with BLE the same way you get "do you want to use Apple Pay" today.
Platform level support would allow me to use this directly within other applications and browsers, rather than just from Safari and the SFSafariViewController/ASWebAuthenticationSession Safari-managed views.
As I see it, data is stored in a secure enclave separate from the processor and OS. It only provides a match value based on the generated digital private key. So phones will create a separate pair for every site and send the public key with credentials so the server can verify it with the device.
Wouldn't apple have to open source their hardware as well?
Here, the iPhone functions as a platform authenticator, like a U2F usb/nfc key would. Why would they need to open source their hardware for this?
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.
If the certificate used to sign into Hacker News as "sneak" is also used to sign into PornHub then I can correlate that to discern that "sneak" on HN uses PornHub. Whereas you can't do that with WebAuthn credentials - a separate credential is spun up for every single registration, it's completely useless everywhere except the one site it was issued for and can't be correlated to other credentials except via a cryptographic attack on the underlying primitives (ie breaking WebAuthn itself).
Even if CA does sign client certificate, and website is expected to store its public key, it expose some privacy concerns since a public key is now Personally Identifiable. If a website must provide its own self-signed CA and require user to provide a CSR when registering for an account, then it becomes a huge overhead for both website and user to just login.
I work with enterprise and the requirement usually requires client certificate. I never had a good experience setting it up even with a limited number of parties.
This is precisely how WebAuthN works - but we figured out that we actually don’t need to go through the headache of getting CAs and signing involved at all. Just store a public key attached to a user after they’ve signed in via traditional means and let the browser/security token manage the keys.
Client certificates are also worse for privacy and phishing resistance: with a certificate, if I can convince you to click on a link I get your identity. From the site's perspective, I don't have any way to tell whether the person with the certificate is the same person I saw or the person who compromised their computer or convinced a CA to issue a cert for someone else. Requiring key storage to be on a hardware enclave significantly reduces that risk, allows for the stronger attestation requirements mentioned, and also means that you're changing things from “trust anyone who can get a CA certificate” to “trust anyone who can do signatures from a previously-registered hardware key”.
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).
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.
For my Okta account, they support push notification to their app on my phone as an alternative authentication measure.
Another approach is a bluetooth (or NFC) enabled device (like your phone) that actually caries the private key. When using a borrowed computer, the signed attestation data is shared with the borrowed system, but that can only be used once, since the private key is never transmitted.
So basically you can either have a side-channel to another MFA method, or a relay where you don't need to trust the intermediary beyond the current session.
If you need to sign in on a borrowed computer you visit the site, it'll ask you to insert the yubikey (if not already), you enter the PIN code and touch it, that's it.
I believe a yubikey with fingerprint instead of PIN (or additionally? Information is scarce on it) is also coming.
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?
How can Apple be a monopolist from such a small position, or have a "stranglehold" when they are outsold 4-8x by the competition?
[1] https://www.statista.com/statistics/216459/global-market-sha...
The poster I replied to compared Google and Apple using the terms "stranglehold" and "monopoly". These terms don't work because Apple don't have control of most of the smartphone market, so they can't be a monopoly. Through Android, Google do control most of the smartphone market, so they might have a monopoly effect on the smartphone market. Apple aren't in any position to strongarm things. Google are.
Therefore whatever Apple does with iOS can't be "worse" from this perspective. It could be worse for users, but it can't be "worse" monopolistically for Apple to affect 20% of the market in Apple's favour, than it is for Google to affect 80% of the market in Google's favour.
Google could strongarm Huawei and Sony and LG and all the other Android manufacturers. Apple couldn't. Google could strongarm 80% of smartphone users, Apple only 20%.
Apple has a 49-60% share in the USA. Their next biggest competitor is Samsung with less than 1/2 of that.
Google controls Android which Samsung use, and the terms on which they're allowed to use it if they still want to allow Google apps. That means it's not Samsung vs Apple, it's Google vs Apple, especially when my reply was to someone comparing Google to Apple, not Samsung to Apple.
Apple and Samsung are in direct competition. Apple has >50% of the smartphone market in the USA. Samsung has less then 25%, every one else has even less. Google has < 1%. That Samsung happens to use Android is irrelevant. FWIW Samsung has its own app store and plenty of distinguishing features from every other phone.
The rest of the world has its own markets. If the UK wants to sue Apple or Google for being a monopoly they only care about the UK market, not how it's selling in Indonesia. In other words it doesn't matter one wit if some company has a large market share in the world, monopolies are only enforced in a specific country for that country's market, not the world market. You quote iOS has only have 20%, but as that is a world wide number it's entirely irrelevant and pointless. If iOS had 100% market share in Singapore but only 5% marketshare in the world it would be Singapore suing because of the Singapore market. There is no one who can sue on behalf of the world.
And by reaching over multiple Android phone sellers, that has at least a similar, but likely much greater reach than anything Apple can do, doesn't it?
Whether a company can be sued for being a monopoly in a given jurisdiction isn't so interesting to me, as whether they can influence ~80% of the worldwide smartphone market; If they can do that but you can't sue them for being a monopoly in Tuvalu that has no bearing on anything interesting.
I’ve never noticed that criticism come up in the wild. The criticism I’ve seen of Android is that it’s primarily a surveillance device with a questionable security model.
AFAIK that hasn't been true for years. WKWebView (as opposed to the old UIWebView) lets you use the full speed JS engine.
Questioning this because you were just proven wrong once, do you have a source that confirms what you're saying?
Layout engine and even rendering etc. is quite distinct from the other browser features. What goes on in front of your eyes is fairly separate from networking, security all those other nice things.
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.
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.
also where he falsely alludes to other attestations being identifying? sure, they can be, but they generally aren't.
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?
Stealing a password is probably more easily done than stealing a private key that is never transmitted. The primary threat model is protecting the credentials of real users rather than protecting against fraudulent users (though some considerations have been made for that too).
https://gitlab.com/stavros/django-webauthin
You can see a demo login here: 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).
Would be nice to have Yubikey replace my password and then allow me to enroll FaceID so I can keep signing back in.
You just need an open standard, you could even embed the url of the validating api in the token, so anyone could create their own Face ID provider.
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.
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.
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.
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.
If my finger is rejected multiple times, I am asked for the password instead.
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.
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.
Because for most non technical user, my bank app asking my fingerprint to unlock the app is exactly that. They don't really get the difference.
E.g. anyone can take a picture of you in a crowd, or lift your fingerprints if they can get to somewhere you've been. But they can't do a surreptitious retinal scan on you.
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.
Otherwise I don't understand why iPhone doesn't support "guest" profile via FaceID. Or iPad doesn't allow multiple users(family) on the same device by simply "looking at it"
https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
User verification + resident keys were never implemented in Safari 13.
Seems they missed a step here with rolling it out, or are withholding the obvious. I'm assuming the latter.
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.
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?
If you change devices you just provision the new one for your account after signing in with a traditional username/password(/2nd-factor).
Though, I agree lost and stolen devices are a problem whose solution space needs more exploring than simply multiple auth devices.
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?
> 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.
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.
Looks like you use a separate device like this: https://www.ftsafe.com/Products/FIDO/Bio
That supports fido2, hooked to any tablet to make it work.
- 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.
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.
In WebAuthn the design is that a batch of (at least 1000 but usually far more) authenticator products should have such a document which Javascript can optionally request (together with proof they didn't just knock it off from another authenticator) when using the authenticator.
If you demand multi-factor and aren't willing to take my word (as the user) that I'm using it, you could insist upon seeing the attestation and reject authenticators unless you can see the attestation and you like it. For example maybe Great American Bank accepts Yubikeys, but rejects the Apple iPhone because they believe Steve Jobs was Satan.
Most sites should not use attestation at all. Firefox in particular can tell a site to fuck off when it asks for attestation. I'm happy to use high security WebAuthn but I don't want to have to tell you which products I use to do it. If your site does not require WebAuthn for every user then almost by definition it makes no sense to demand attestation from users who choose to enable it.
The use of "batches" is a privacy safeguard. If you permit attestation a site might know you have a Mattel Barbie Authenticator, but it won't know which one. If Mattel aren't selling many they probably put the same batch on the Buzz Lightyear Authenticator so a site can't even tell if you've got a Barbie or Buzz Lightyear.
According to this video apparently (?) Apple thought that wasn't safe enough and so it has decided to do something else weird instead, but not yet. Whatever, for almost all web sites you should refuse attestation if given the option. Maybe my bank needs to know I'm doing MFA with a high quality product but there's no reason Facebook or GMail or anybody like that should ask.
This is akin to a batch of identifiers the size of all Apple products, while still allowing the device owner (or Apple) to disavow a particular device if it is lost or stolen.
The implementation also ensures that the same device creating multiple identities for the same website will have no signing characteristics linking one account to the other.
There are already designs if you are quite sure you must have attestation and yet you don't want device identification. You can do blinded attestation and agl has written up a much fancier approach on his blog too.
But again, Don't Ask, Don't Tell. The video shows this silly demo "Shiny picture" site asking for attestation and that's a bad idea you should not replicate, write "none" instead of "direct" and then the problem goes away for your site.
The Safari team do move slowly.
This is making a friendly version of Yubikeys (using Apple devices) and password vaults for Apple users.
Competition and a free market has perils. May the best solution win.
Big fan of these feature being native client side. These are features, not products. We should all be a fan of improved security delivered to as many people as possible, with as little effort on their part.
Just a happy 1Password user, nut related to them in any way.
In this case TOTP acts more like an insecure one-time session key.
Having this available to every Apple user on the web is huge, especially when you look at the network benefits of the Apple feature pushing all of the slackers (hi, every large financial company!) to implement secure MFA.
Machinery to take that TOTP code and immediately plug it into the real bank (since it's time sensitive) exists already.
In contrast WebAuthn credentials are tied to the domain name of the site. Your iPhone doesn't have any credentials for https://fake-bank.example/ so it won't sign you in, and even if it did have credentials for fake-bank.example they'd be completely useless on the https://real-bank.example/ web site. There is no way to give real-bank credentials to fake-bank, it just can't work because the cryptographic material used is tied to the domain name.
Google deployed an earlier iteration of this same technology and reported zero phishing for accounts protected this way because it isn't possible to see how to phish it without some grave security bug somewhere. This is the penicillin of web user security, it's a night-and-day difference over what we had before.
Normal people would actually use it. And this is in fact not different. The phone IS the ring. You just unlock it using your biometrics (and of course, the data is NOT given to Apple)
Does google have a similar thing?
Because overnight we can finally stop sybil attacks! Right?
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...
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.
The public/private key gets generated by the phone upon first registration with the server.
Sounds vague and overly general. I don't think anyone can take this seriously without some more information.
Face ID defeated with glasses and tape https://appleinsider.com/articles/19/08/08/face-id-security-...
Touch ID defeated by lifted fingerprints
2013: https://arstechnica.com/information-technology/2013/09/defea...
2016: https://appleinsider.com/articles/13/09/22/apples-touch-id-a...
2019: https://www.forbes.com/sites/daveywinder/2019/11/02/smartpho...
Biometric "security" on phones is a gimmick.
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.
Based on this video we don't know exactly if Apple allows that to be done as well, but it seems within the realm of possibility based on how Apple Pay works (which AFAIK can use a passcode).
Either way discarding the entire protocol because of one implementation is silly. With Apple joining Google, Microsoft and many other companies supporting WebAuthn (a W3C standard) there's a lot of support for it to make logging in easier and more secure. SQRL never got any real traction.
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...
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.
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.
There have been some past complaints here about how Apple used to tie their fingerprint sensor into the secure element (third party folks couldn't substitute them). I actually liked that rule from a security standpoint, but obviously unpopular here. Same approach with faceid / touchID for the web.
https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...
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.
(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.)
So you are vulnerable to an active MITM, but they don't actually acquire any private secrets to be used to create their own sessions. MITM with passwords OTOH, gives the attacker your password.
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.
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.
I agree there are advantages to using public key crypto but the reality is that it's more difficult to get right (and therefore not implemented) compared to a simple hashing function for a password.
I'll stick to taping over my cameras, thanks.
You can't change your biometrics when they are inevitably hacked. If you even find out.
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.
That one they legally have to do when given a subpoena.
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.
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.
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.
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.
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.
But I recognize that not everyone is so paranoid. Though in the current political climate, where corporations are clearly choosing sides, you probably should be.
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.
It's a isolated smart-card-like KMS core within the SoC, that has most smart-card guarantees (e.g. no side-channel attacks; tamper-resistance.)
It's a pretty modified L4 (I want to say L4::Pistachio off the top of my head) that for some reason has had Mach-O support added and pretty much just acts as a keystore with a secure but upgradable boot sequence.
https://support.apple.com/guide/security/secure-enclave-over...
https://www.apple.com/lae/business/docs/site/iOS_Security_Gu...