The reason I’m not liking this news is because TouchID _sucks_. Passwords suck too, but at least I can use a password manager, and never worry about signing in (unless the password expires or is compromised in a leak, etc.). But biometrics are unreliable. I have to re-train my TouchID constantly—several times a week—or it forgets my fingers. I can see it degrading within hours, failing multiple attempts, and forcing me to go into Settings to tune it, tune it, tune it. Is it more secure? Maybe. But it requires so much babysitting and handholding and just _effort_ that I’d much rather be using a password any day!
I can’t be the only one who TouchID doesn’t work for. (FaceID is fine.)
Sounds like a device level hardware problem. You may want to have Apple take a look at your device.
What if I want to access my account on a device that doesn't belong to me? For instance, if I were a student at a school computer lab?
Then you'd need the username and password, or, as they may have shown during the keynote, you'll be able to use your Watch or iDevice to log into another device with NFC, BT, a QR code via a camera with ease.
Outside of wet fingers I haven't either, but there are clearly people who do. Apple is well aware of this and it's more prevalent for people who are older. Face ID fills the gap for many, but it also has limitations.
The reason I’m not liking this news is because TouchID _sucks_. Passwords suck too, but at least I can use a password manager, and never worry about signing in (unless the password expires or is compromised in a leak, etc.). But biometrics are unreliable. I have to re-train my TouchID constantly—several times a week—or it forgets my fingers. I can see it degrading within hours, failing multiple attempts, and forcing me to go into Settings to tune it, tune it, tune it. Is it more secure? Maybe. But it requires so much babysitting and handholding and just _effort_ that I’d much rather be using a password any day!
I can’t be the only one who TouchID doesn’t work for. (FaceID is fine.)
I have low thyroid as a result of an auto-immune disorder and part of that is dry skin that causes Apple Touch ID to not work well with my fingers. Face ID works fine.
The issue for me is trusting a dialog box on a website that’s asks for my Mac password. The Apple UI doesn’t make it clear that this info stays on my device and isn’t sent to the server as is normal. This paaswordless stuff will suffer the same issue and I will struggle to trust where my data goes.
The issue for me is trusting a dialog box on a website that’s asks for my Mac password. The Apple UI doesn’t make it clear that this info stays on my device and isn’t sent to the server as is normal. This paaswordless stuff will suffer the same issue and I will struggle to trust where my data goes.
This is an excellent point, and one I'm really surprised Apple hasn't addressed yet. But it's difficult - not technically, but in terms of training users how to behave.
So far the only entities I've seen addressing this issue are some banks, and not even most of them - I think they feel the ROI isn't worth it.
The obvious way to do it is to allow the user to select an image which is proof that the system is talking, and not the app. The image is protected and inaccessible to all apps. Then when you get a dialog asking for a password or other sensitive info, the system displays this image along with the request. The presence of the image authenticates the request.
There are other similar schemes (text or sound instead of an image). In general, you have to have a token signifying legitimacy (not a physical one, unless you intend to put a little LED on the phone just to signal "system interaction", and Apple would never do something so ugly). Implementing this is not in the least bit challenging.
The big problem is teaching users to pay attention and understand the significance of the token. People understand the idea of "password" - it means "way to prove I'm really me". They *don't* generally understand the concept of "way for the OS to prove it's really the OS (and not malware spoofing the OS)", and they have no simple word for that like "password". This won't be an easy battle to fight and I guess Apple isn't willing to take it on yet. :-(
The issue for me is trusting a dialog box on a website that’s asks for my Mac password. The Apple UI doesn’t make it clear that this info stays on my device and isn’t sent to the server as is normal. This paaswordless stuff will suffer the same issue and I will struggle to trust where my data goes.
This is an excellent point, and one I'm really surprised Apple hasn't addressed yet. But it's difficult - not technically, but in terms of training users how to behave.
So far the only entities I've seen addressing this issue are some banks, and not even most of them - I think they feel the ROI isn't worth it.
The obvious way to do it is to allow the user to select an image which is proof that the system is talking, and not the app. The image is protected and inaccessible to all apps. Then when you get a dialog asking for a password or other sensitive info, the system displays this image along with the request. The presence of the image authenticates the request.
There are other similar schemes (text or sound instead of an image). In general, you have to have a token signifying legitimacy (not a physical one, unless you intend to put a little LED on the phone just to signal "system interaction", and Apple would never do something so ugly). Implementing this is not in the least bit challenging.
The big problem is teaching users to pay attention and understand the significance of the token. People understand the idea of "password" - it means "way to prove I'm really me". They *don't* generally understand the concept of "way for the OS to prove it's really the OS (and not malware spoofing the OS)", and they have no simple word for that like "password". This won't be an easy battle to fight and I guess Apple isn't willing to take it on yet. :-(
On réflection i think Apple has already done this. Visit say iCloud.com and the modal dialog, that asks for my Mac password, disables the window’s close button. I have to use the awkward Cancel button to get the regular authentication that ironically I trust. I guess this is the ‘image’ you mention…
The issue for me is trusting a dialog box on a website that’s asks for my Mac password. The Apple UI doesn’t make it clear that this info stays on my device and isn’t sent to the server as is normal. This paaswordless stuff will suffer the same issue and I will struggle to trust where my data goes.
This is an excellent point, and one I'm really surprised Apple hasn't addressed yet. But it's difficult - not technically, but in terms of training users how to behave.
So far the only entities I've seen addressing this issue are some banks, and not even most of them - I think they feel the ROI isn't worth it.
The obvious way to do it is to allow the user to select an image which is proof that the system is talking, and not the app. The image is protected and inaccessible to all apps. Then when you get a dialog asking for a password or other sensitive info, the system displays this image along with the request. The presence of the image authenticates the request.
There are other similar schemes (text or sound instead of an image). In general, you have to have a token signifying legitimacy (not a physical one, unless you intend to put a little LED on the phone just to signal "system interaction", and Apple would never do something so ugly). Implementing this is not in the least bit challenging.
The big problem is teaching users to pay attention and understand the significance of the token. People understand the idea of "password" - it means "way to prove I'm really me". They *don't* generally understand the concept of "way for the OS to prove it's really the OS (and not malware spoofing the OS)", and they have no simple word for that like "password". This won't be an easy battle to fight and I guess Apple isn't willing to take it on yet. :-(
On réflection i think Apple has already done this. Visit say iCloud.com and the modal dialog, that asks for my Mac password, disables the window’s close button. I have to use the awkward Cancel button to get the regular authentication that ironically I trust. I guess this is the ‘image’ you mention…
Or any of the "Sign-On with Apple"-linked websites will give you an idea of how this may be linked to your Apple account without having to give any of your iCloud data over.
How does a user intuitively know what data is shared with the website?
However, the point was more that it's unclear if a website is spoofing the Sign in with Apple prompt asking for my local machine password. Surely a site could phish those details then download a script that has the password for my Mac...
The problem I see with something like this is when using cross-platform devices. My work laptop is a Windows machine, but at home I use Apple devices. For a while, I tried using the iCloud Key Manager add-in that Apple had for Edge, but it was a real pain. It would ask for a validation every time I used it, which meant that me directly typing in the password was simpler.
I am not sure it will be simple to solve it.
This has been in development since at least 2015, maybe earlier, beginning as Project Gnubby. When big techs need to partner up to push a technology forward the wheels can turn slooow. I'm confident they'll have this right at launch, or very shortly thereafter.
The issue for me is trusting a dialog box on a website that’s asks for my Mac password. The Apple UI doesn’t make it clear that this info stays on my device and isn’t sent to the server as is normal. This paaswordless stuff will suffer the same issue and I will struggle to trust where my data goes.
This is an excellent point, and one I'm really surprised Apple hasn't addressed yet. But it's difficult - not technically, but in terms of training users how to behave.
So far the only entities I've seen addressing this issue are some banks, and not even most of them - I think they feel the ROI isn't worth it.
The obvious way to do it is to allow the user to select an image which is proof that the system is talking, and not the app. The image is protected and inaccessible to all apps. Then when you get a dialog asking for a password or other sensitive info, the system displays this image along with the request. The presence of the image authenticates the request.
There are other similar schemes (text or sound instead of an image). In general, you have to have a token signifying legitimacy (not a physical one, unless you intend to put a little LED on the phone just to signal "system interaction", and Apple would never do something so ugly). Implementing this is not in the least bit challenging.
The big problem is teaching users to pay attention and understand the significance of the token. People understand the idea of "password" - it means "way to prove I'm really me". They *don't* generally understand the concept of "way for the OS to prove it's really the OS (and not malware spoofing the OS)", and they have no simple word for that like "password". This won't be an easy battle to fight and I guess Apple isn't willing to take it on yet. :-(
On réflection i think Apple has already done this. Visit say iCloud.com and the modal dialog, that asks for my Mac password, disables the window’s close button. I have to use the awkward Cancel button to get the regular authentication that ironically I trust. I guess this is the ‘image’ you mention…
No, not at all.
Your confusion (and that of a couple of other followups) unfortunately demonstrates my point - people don't really understand yet that real security demands *two-way* authentication. Any time you have to provide a password (or other authentication), the authenticator also needs to prove to *you* that it is the right thing to ask for authentication. And this authentication exists in multiple contexts.
First of all, there's you authenticating to your local system. With biometrics, authenticationg the system to you is implicit (which of course trains people not to think about this, unfortunately): If the biometric hardware is being accessed, you know the real system is doing it and that's enough authentication (at least in the context of an iPhone - other systems, that may not be true). However, if you're putting in a password, the problem remains: How do you know the thing asking for your password is the iphone OS, and not an evil app pretending to be the OS?
The only good answer to that, if you don't have another piece of hardware helping you out, is to have a secret that you know, and that the OS knows, but that the evil app can't know. Then if a password request offers you the secret, you can be confident that it's really from the OS and not from an evil app. That secret must be a pre-agreed-upon image, or sound, or text, that is carefully guarded so evil apps can never get at it. The icloud thing you mentioned above is nothing like that.
The second context is between you and an off-device server. The same fundamental idea applies - you need to know that the server is really the server, and not supply secrets to an impostor. But the threat environment and solutions are completely different. Once you have a secure local device, you can use zero-knowledge techniques to authenticate to a remote server without ever revealing your shared secret, if you have one, or (much better) use public-key crypto techniques, which by design never reveal any secrets and also don't share any secrets. Either way a local agent on your device, under control of the OS, can make the authentication happen - which then reduces the problem down to the case of local authentication, you to the agent. And then we're back to case #1, and we can use the same solution - a local shared secret, probably an image that's agreed upon by you and the OS when you set up your device.
AI should probably write an article about this. Or pay me to clean this all up and post that...
Yeah I get it @JustSomeGuy1, that was my point about two-way trust. In the password scenario the os doing something to a window that can never normally happen, proves you’re sharing your password with the local system not an interloper. However, It’s weak, too subtle and unexplained.
it’s harder with biometrics to know what’s going on, but the goal is that it just works.
Comments
However, the point was more that it's unclear if a website is spoofing the Sign in with Apple prompt asking for my local machine password. Surely a site could phish those details then download a script that has the password for my Mac...
http://fc16.ifca.ai/preproceedings/25_Lang.pdf
it’s harder with biometrics to know what’s going on, but the goal is that it just works.