Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>While Ovid anticipated this problem, he didn’t foresee its best solution with biometrics. On Macs with Touch ID support and an appropriate keyboard, in many cases (but not yet for keychain passwords) you may first see the prompt for biometric authentication using your fingerprint.

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



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

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?


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


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…


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


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


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.


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

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)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: