Ovid's myths of macOS: password entry dialogs and the death of Semele(eclecticlight.co)
eclecticlight.co
Ovid's myths of macOS: password entry dialogs and the death of Semele
https://eclecticlight.co/2024/03/14/ovids-myths-of-macos-password-entry-dialogs-and-the-death-of-semele/
45 comments
> the password prompt dims the entire screen, and (more importantly) the secure attention sequence[1] is blocked.
As far as I know, the SAS is not actually blocked. At least it's not in Windows 11. However you can't do anything else until you have accepted or canceled the UAC prompt. So Ctrl-Alt-Del would basically just cancel UAC.
But UAC runs in something called a Secure Desktop, where other applications don't have a way to interact with the prompt dialog (e.g. malware could not "click" the button for you).
https://learn.microsoft.com/en-us/windows/security/applicati...
I know many people don't like UAC and even disable it, but it's actually not a bad system IMHO.
As far as I know, the SAS is not actually blocked. At least it's not in Windows 11. However you can't do anything else until you have accepted or canceled the UAC prompt. So Ctrl-Alt-Del would basically just cancel UAC.
But UAC runs in something called a Secure Desktop, where other applications don't have a way to interact with the prompt dialog (e.g. malware could not "click" the button for you).
https://learn.microsoft.com/en-us/windows/security/applicati...
I know many people don't like UAC and even disable it, but it's actually not a bad system IMHO.
>As far as I know, the SAS is not actually blocked. At least it's not in Windows 11. However you can't do anything else until you have accepted or canceled the UAC prompt. So Ctrl-Alt-Del would basically just cancel UAC.
Apparently it's buried behind another group policy:
https://www.tenforums.com/tutorials/112476-enable-ctrl-alt-d...
Apparently it's buried behind another group policy:
https://www.tenforums.com/tutorials/112476-enable-ctrl-alt-d...
I got in the habit of disabling it because it caused the entire system to lock up for several seconds. This was probably the correct behavior in those situations but still super annoying as a user. Maybe not a problem on higher end machines.
This is why they give you the option to just disable the background dimming part of UAC. I’ve had to do this before on slow systems and it fixes it.
> Can't malware spoof a "can't read fingerprint, please enter password" dialog?
I've wondered something similar about counterfeiting. If I were to start printing counterfeit dollars, surely I would forge a 1990's era bill instead of a 2024 bill with all the security features?
I've wondered something similar about counterfeiting. If I were to start printing counterfeit dollars, surely I would forge a 1990's era bill instead of a 2024 bill with all the security features?
"It's an older code sir, but it checks out"
It'll work at first, but eventually it'll be more and more suspicious as the older versions are removed from circulation. At some point it's going to attract so much suspicion that you might as well try faking the latest note.
It'll work at first, but eventually it'll be more and more suspicious as the older versions are removed from circulation. At some point it's going to attract so much suspicion that you might as well try faking the latest note.
Indeed. Nowadays I’d be suspicious of accepting a 1990s era $20 as the amount of legitimate ones in circulation is very small.
> touchid sometimes fail due to grubby fingers. Can't malware spoof a "can't read fingerprint, please enter password" dialog?
That would require the malware to be able to determine the timing of when your finger pressed the TouchID sensor, which I suspect is not accessible above the OS layer.
TouchID is a great solution for this. However, the root issue remains: social engineering the user to allow admin privileges when not necessary… there are still too many cases of requesting elevated privileges. Maybe signed software with entitlements can sufficiently solve that? But I’ve seen way too many users who “trust” email attachments or phishing emails…
That would require the malware to be able to determine the timing of when your finger pressed the TouchID sensor, which I suspect is not accessible above the OS layer.
TouchID is a great solution for this. However, the root issue remains: social engineering the user to allow admin privileges when not necessary… there are still too many cases of requesting elevated privileges. Maybe signed software with entitlements can sufficiently solve that? But I’ve seen way too many users who “trust” email attachments or phishing emails…
Yes, it could, but this would of course be quite suspicious for people who do not have grubby fingers.
How would the user know that SAS is blocked?
SAS is always active and can't be blocked by normal applications. Normally (ie. you're not in a UAC prompt) if you try to use the SAS, it brings up the windows security screen[1]. The UAC prompt is part of the operating system, and therefore it can block the SAS. Thus, if you see a password prompt, you do the SAS and the prompt is still there, then you can be sure the prompt is from the operating system. In fact there's a group policy[2] to force users to do this exact sequence to confirm whether they're entering passwords into a genuine OS dialog. Whether the policy actually works is questionable, because users are lazy/forgetful and an attacker can simply show a prompt that doesn't require the user to press the SAS, and the user would likely happily enter their password regardless.
[1] https://en.wikipedia.org/wiki/File:Windows_Security_screen_i...
[2] https://learn.microsoft.com/en-us/previous-versions/windows/...
[1] https://en.wikipedia.org/wiki/File:Windows_Security_screen_i...
[2] https://learn.microsoft.com/en-us/previous-versions/windows/...
> if you see a password prompt, you do the SAS and the prompt is still there, then you can be sure the prompt is from the operating system.
I think it's the other way round. SAS will cancel the UAC prompt, as UAC will prevent any action except to accept or cancel the UAC prompt.
The link you provided is for the logon screen, not UAC.
I think it's the other way round. SAS will cancel the UAC prompt, as UAC will prevent any action except to accept or cancel the UAC prompt.
The link you provided is for the logon screen, not UAC.
Yeah that was the wrong group policy, this should be the correct one: https://www.tenforums.com/tutorials/112476-enable-ctrl-alt-d...
Ah yes, this works (just tested on Win 11)
If I'm not missing something, not all users would know to press the Ctrl+Alt+Del key when working with UAC prompts, and having to press it all the time to verify if it is a legitimate password prompt would be infeasible.
My point isn't that this is convenient for the average user, only that it's something that actually works and is secure. On macs the biometric option might be "secure", but there's nothing preventing a downgrade attack back to password entry.
For the average user security is ensured by not requiring them to enter a password at all, and making it impossible to use a password to get admin access. By default the user is only asked to click yes/no to approve the action. The approval itself is done by the operating system and can't be spoofed. Moreover, the operating system is designed in such a way where even if you somehow were able to phish the user password, it can't be used to get admin access. There's no "sudo" command that you can pipe a password into and get a root shell, for instance.
For the average user security is ensured by not requiring them to enter a password at all, and making it impossible to use a password to get admin access. By default the user is only asked to click yes/no to approve the action. The approval itself is done by the operating system and can't be spoofed. Moreover, the operating system is designed in such a way where even if you somehow were able to phish the user password, it can't be used to get admin access. There's no "sudo" command that you can pipe a password into and get a root shell, for instance.
Ok, so the only way for the user to know is if it's required every time
By the way, can't attacker simply visually spoof SAS window on noticing SAS key press so the user would see the same image which might behave slightly different, but that would require more verification steps
By the way, can't attacker simply visually spoof SAS window on noticing SAS key press so the user would see the same image which might behave slightly different, but that would require more verification steps
>By the way, can't attacker simply visually spoof SAS window on noticing SAS key press so the user would see the same image which might behave slightly different, but that would require more verification steps
That doesn't work because the correct behavior for a genuine password prompt is that pressing the SAS causes nothing to happen. Having windows security popping up is an indicator that the prompt is fake. To summarize:
Genuine password prompt:
1. password prompt shows up
2. user presses the SAS
3. nothing happens, because the password prompt is from the OS and can block the SAS. Also all of this is displayed on a "secure desktop", so only the password prompt can be seen (the rest of the screen is dimmed and can't be interacted with), so a fake app can't place a fake password prompt next to a real one.
4. user is sure the password prompt is real and can enter in the password
Fake password prompt:
1. password prompt shows up
2. user presses the SAS
3. Windows security pops up. The app can't prevent this from happening, nor dismiss it programmatically. If the user sees this they know the prompt was fake.
That doesn't work because the correct behavior for a genuine password prompt is that pressing the SAS causes nothing to happen. Having windows security popping up is an indicator that the prompt is fake. To summarize:
Genuine password prompt:
1. password prompt shows up
2. user presses the SAS
3. nothing happens, because the password prompt is from the OS and can block the SAS. Also all of this is displayed on a "secure desktop", so only the password prompt can be seen (the rest of the screen is dimmed and can't be interacted with), so a fake app can't place a fake password prompt next to a real one.
4. user is sure the password prompt is real and can enter in the password
Fake password prompt:
1. password prompt shows up
2. user presses the SAS
3. Windows security pops up. The app can't prevent this from happening, nor dismiss it programmatically. If the user sees this they know the prompt was fake.
thanks for the clarification, got my prompts logic mixed up, indeed, it's the absence that is telling! (and also you can't intercept SAS key press, that's that whole point of it being unique to the system, not user)
This problem is why Windows started using ctrl-alt-del to login back with Windows NT:
https://serverfault.com/questions/2912/how-does-ctrl-alt-del...
https://serverfault.com/questions/2912/how-does-ctrl-alt-del...
Interesting read, but the conclusion doesn’t go into detail about the reasons WHY biometric authentication is better.
I assume the main reason is that if you’re using Touch ID then you’re not inputting your password so there’s no way to get tricked into putting your password into a malicious dialog.
I also assume it has something to do with how Touch ID is built into MacOS so that it doesn’t transmit that data outside some protected layer? Or else there’s theoretically the risk that an attacker can steal your fingerprint (unless I’m completely misunderstanding how Touch ID works).
Would this also apply to other forms of biometric authentication like FaceID on iOS and Windows, Android, and other OS biometric authentication?
I assume the main reason is that if you’re using Touch ID then you’re not inputting your password so there’s no way to get tricked into putting your password into a malicious dialog.
I also assume it has something to do with how Touch ID is built into MacOS so that it doesn’t transmit that data outside some protected layer? Or else there’s theoretically the risk that an attacker can steal your fingerprint (unless I’m completely misunderstanding how Touch ID works).
Would this also apply to other forms of biometric authentication like FaceID on iOS and Windows, Android, and other OS biometric authentication?
The biometric part is incidental. The thing that makes it more secure is that authentication is done by a separate trusted system: the secure enclave, which has its own separate processor, OS, and input device. The primary OS tells the secure enclave to start a security challenge, and then the secure enclave reports success if you scan your finger or nothing if you don't. Malware can't fake this response (at least not without having already pwned your system to an extent that it doesn't need your password), and popping up a fake TouchID dialog doesn't really achieve much of anything. Infecting the secure enclave with malware would let you break everything, but unlike the primary OS it's not designed to run third-party software, so that's significantly harder to do.
FaceID swaps out the fingerprint reader for facial recognition but the actual security features are the same. Yubikeys are the same high-level concept, although the implementation is quite different.
FaceID swaps out the fingerprint reader for facial recognition but the actual security features are the same. Yubikeys are the same high-level concept, although the implementation is quite different.
A yubikey can still be MITM’d with a fake OTP dialog. Anyone who has worked around them for long enough has seen a yubisneeze.
Because of how https://developer.apple.com/documentation/localauthenticatio... works, comparing touchID to yubikeys doesn’t make sense to me.
Because of how https://developer.apple.com/documentation/localauthenticatio... works, comparing touchID to yubikeys doesn’t make sense to me.
Are these dialogs always rendered on top? I can imagine it wouldn't be too hard to perform some malicious high-risk actions (elevating permissions, disabling protections) and hiding the permission prompt by overlaying something a copy with something that sounds more benign.
You're not leaking credentials there, but if you can get the user to give away the right permissions, you don't need to.
On Android, where apps have the ability to draw on top of other apps (used for things like pop-out players and night light apps) it used to be possible to trick the user into opening their phone's settings and guiding them through a bunch of security options by overlaying a game and letting the taps fall through to the underlying app. This makes me wonder how well-protected macOS is against that kind of attack.
You're not leaking credentials there, but if you can get the user to give away the right permissions, you don't need to.
On Android, where apps have the ability to draw on top of other apps (used for things like pop-out players and night light apps) it used to be possible to trick the user into opening their phone's settings and guiding them through a bunch of security options by overlaying a game and letting the taps fall through to the underlying app. This makes me wonder how well-protected macOS is against that kind of attack.
From what I remember, Apple’s biometrics are designed so that the biometric “fingerprint” never leaves a Secure Enclave processor. I don’t know how standard this is on other platforms, but it seems to me to be preferable because it even offers some degree of protection against rootkits or other forms of malware.
As far as I know, that’s correct. macOS never sees any of the fingerprint data, and thus it can’t be read or intercepted easily.
The Secure Enclave can also store various keys, which apps like Secretive[0] can use to store and gate access to things like SSH keys with. Feels a little nicer than letting them rattle around loose in ~/.ssh/ where any passerby can pick them up, is more convenient than an a USB key, and lets me know when something is trying to use it by way of unexpected Touch ID prompt. It’s a feature I miss when using my Windows/Linux laptop.
[0]: https://github.com/maxgoedjen/secretive
The Secure Enclave can also store various keys, which apps like Secretive[0] can use to store and gate access to things like SSH keys with. Feels a little nicer than letting them rattle around loose in ~/.ssh/ where any passerby can pick them up, is more convenient than an a USB key, and lets me know when something is trying to use it by way of unexpected Touch ID prompt. It’s a feature I miss when using my Windows/Linux laptop.
[0]: https://github.com/maxgoedjen/secretive
Does that mean that Bluetooth keyboards with Touch ID also have a Secure Enclave on them? I guess there’s some additional security that ensures you can’t spoof that keyboard’s response?
Correct!
I don't think so.
https://support.apple.com/en-in/guide/security/secf60513daa/...
From what I understand, the keyboard just acts as a sensor, but doesn't store anything - neither securely nor otherwise.
"The Magic Keyboard with Touch ID performs the role of the biometric sensor; it doesn’t store biometric templates, perform biometric matching or enforce security policies (for example, having to enter the password after 48 hours without an unlock). The Touch ID sensor in the Magic Keyboard with Touch ID must be securely paired to the Secure Enclave on the Mac before it can be used, and then the Secure Enclave performs the enrolment and matching operations and enforces security policies in the same way it would for a built-in Touch ID sensor."
https://support.apple.com/en-in/guide/security/secf60513daa/...
From what I understand, the keyboard just acts as a sensor, but doesn't store anything - neither securely nor otherwise.
"The Magic Keyboard with Touch ID performs the role of the biometric sensor; it doesn’t store biometric templates, perform biometric matching or enforce security policies (for example, having to enter the password after 48 hours without an unlock). The Touch ID sensor in the Magic Keyboard with Touch ID must be securely paired to the Secure Enclave on the Mac before it can be used, and then the Secure Enclave performs the enrolment and matching operations and enforces security policies in the same way it would for a built-in Touch ID sensor."
Wow! Things have come so far now that my keyboard is a whole secure computer with a radio as well as a keyboard!
This is why you want a trusted secure hardware boundary.
The Apple Pay payment flow on iOS/watchOS requires you to double press the power/side button to authorize a transaction, which userland apps can’t intercept.
Similarly the camera activity indicator on iOS appears somewhere on the screen that regular apps can’t display pixels to (the Dynamic Island, on most recent iPhones)
The Apple Pay payment flow on iOS/watchOS requires you to double press the power/side button to authorize a transaction, which userland apps can’t intercept.
Similarly the camera activity indicator on iOS appears somewhere on the screen that regular apps can’t display pixels to (the Dynamic Island, on most recent iPhones)
Technically you don't actually need an area that only the OS can exclusively access. If the OS is allowed to draw on top of everything you can still solve this problem, as Apple does on older iPhones. (Though you still need to be very careful, as markings displayed out-of-context can be made to be misleading. An orange dot disappears in an orange underlay, for example.)
A nontrivial amount of macOS software, even from large, well-known vendors, has some step during the installation process where it puts up its own dialog asking for your password (and, I strongly suspect, shells out to "sudo" when it gets it).
The line between the things you have to do to use your stuff to get things done, and the things you shouldn't do if you don't want to get scammed or hacked, has gotten blurrier and blurrier. Troy Hunt has written a few "indistinguishable from phishing" articles (e.g. https://www.troyhunt.com/when-bank-communication-is-indistin..., https://www.troyhunt.com/thanks-fedex-this-is-why-we-keep-ge...) and I see more and more of this kind of thing all the time.
The line between the things you have to do to use your stuff to get things done, and the things you shouldn't do if you don't want to get scammed or hacked, has gotten blurrier and blurrier. Troy Hunt has written a few "indistinguishable from phishing" articles (e.g. https://www.troyhunt.com/when-bank-communication-is-indistin..., https://www.troyhunt.com/thanks-fedex-this-is-why-we-keep-ge...) and I see more and more of this kind of thing all the time.
This is part of why I think it’s a good idea to pursue an OS design where for the majority of user-facing software, installation does not require administrator privileges.
This would enable the addition of a system where in order to get admin privileges, installers and software must request for the system to present UI informing the user of exactly what would be installed and asking the user to approve or deny. This also lets the OS keep a record of the installation to allow easy user removal.
This would enable the addition of a system where in order to get admin privileges, installers and software must request for the system to present UI informing the user of exactly what would be installed and asking the user to approve or deny. This also lets the OS keep a record of the installation to allow easy user removal.
My experience is that this is mostly developer tools that are doing things you want administrator access for anyways. And, for most Mac apps, there isn't an "installation process": download and drag to applications and you're ready to go.
Couldn't Apple display a little icon in the top bar, say next to the time? Somewhere no other app can use? A little padlock for example. You would just teach people to only enter their password if the padlock is displayed.
We did that for HTTPS, although that was terribly misunderstood (means "the connection is secure between you and X", not "X is actually your bank")
We did that for HTTPS, although that was terribly misunderstood (means "the connection is secure between you and X", not "X is actually your bank")
You can draw whatever you want onto the screen, you can not just prevent someone from drawing a little lock icon (maybe through copyright but malware authors wouldn’t care). Think of a video game, I can choose the color of any pixel on the screen. That’s the problem
What would stop the rogue app from drawing a fake menu bar with a padlock icon?
Apple should add a non-maskable, unforgeable out of band signal, like the green and orange “lights” that indicate the camera or microphone are on. This logic goes back to the Rainbow books.
Ideally it would be an LED separated from the screen that only the kernel could access.
Ideally it would be an LED separated from the screen that only the kernel could access.
Windows solved this problem in the 90s by capturing a magic keystroke that only it had access to and requesting that the user enter the keystroke before logging in.
The developers at Microsoft searched for a keystroke that absolutely no application would be interested in using itself, and then they stumbled across the perfect one: Ctrl+Alt+Del (soft reboot sequence in DOS). That's why you had to press Ctrl+Alt+Del in order to log in to Windows NT based operating systems for a long time.
The developers at Microsoft searched for a keystroke that absolutely no application would be interested in using itself, and then they stumbled across the perfect one: Ctrl+Alt+Del (soft reboot sequence in DOS). That's why you had to press Ctrl+Alt+Del in order to log in to Windows NT based operating systems for a long time.
Would have been nice to log in with the Touch ID on the iPhone before they added the reader to keyboards.
Eclectic Light is such a special and fascinating site. A true rabbit hole.
Useful article. I just tried to update an app to a paid version, and it popped up this dialog.
Of course, I refused to enter it, for the reasons herein.
Frustrating, as I did want to support the developer.
Do we have a current workaround?
Of course, I refused to enter it, for the reasons herein.
Frustrating, as I did want to support the developer.
Do we have a current workaround?
[deleted]
touchid sometimes fail due to grubby fingers. Can't malware spoof a "can't read fingerprint, please enter password" dialog?
I think window's UAC prompt actually solves this problem. In most cases you're just asked to click yes/no, but it also accepts password entry (if you're a limited user and need to log into a admin account). The way that you can tell the prompt is real is that the password prompt dims the entire screen, and (more importantly) the secure attention sequence[1] is blocked. If it's a fake prompt, it won't be able to block the secure attention sequence and the ruse will be exposed.
[1] https://en.wikipedia.org/wiki/Secure_attention_key