Ctrl-Alt-Delete on windows is a privileged hotkey that goes directly to the kernel. A phishing program can't intercept it once it has been pressed. If you know that Ctrl-Alt-Delete has been pressed, you are already privileged as the kernel and would be able to compromise a hypothetical protected screen buffer anyways.
https://i.imgur.com/BE0xN3i.png
The Windows login screen here doesn't allow you to type in the password until you press the magical keys that only the kernel can access. This significantly increases security, since any phishing program that puts up a fake static image doesn't know when to present the login dialog.
But a phishing program can just show the enter password screen, without the ctrl alt del prompt. Few users understand the security need to press ctrl alt del. And in newer Windows, it doesn't seem to prompt unless you enable it via GP.
https://i.stack.imgur.com/LHDfV.png
And the user would say "oh, another stupid UAC prompt", enter their password, and that would be that -- UAC doesn't stop and say "press ctrl-alt-delete to enter your password". If it did, then that would significantly decrease the risk here.
Applications cannot fake ctrl+alt+del.
That said you can integrate with the windows login and extend it to show w/e you want I've written a client for a smart card for GINA a long long time ago.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
> This is something I've wanted on all computers for a while: fundamentally, any computer where you can get access to the whole screen's buffer means you can fake a logged out screen asking you to log in, or any other number of phishing attacks.
In Windows, I can render the whole screen, so I can put up a fake login dialog. To some extent, Windows users are used to requiring a ctrl-alt-delete before being prompted for a password, but there's no reason why I can't put up a static image of what the screen looks like during a password request. Having a portion of the screen which an application is forbidden from accessing would solve this, but the requirement for full-screen applications that want to write every user-visible pixel means that there's fundamentally no way to prevent this attack.