This is why Windows NT runs the log-on user interface, the screen saver, and the elevation consent UI on separate desktops that have restrictive ACLs disallowing interactive user processes from creating windows there.
Nobody is denying that the "anti-hijacking" forcing of CTRL-ALT-Delete adds to security, what they're saying is that it has nothing to do with this topic.
This topic is about keyboard input focus. In Windows, due to the process hierarchy the login UI isn't running in the same context as desktop applications, so stealing focus or focus drift couldn't occur.
Yes, and the SAS guarantees that after you enter it, nothing else can have keyboard focus. I don't see why this is such a controversial point. You will never come to unlock your NT workstation and find that the keyboard focus is somewhere you don't expect, because you need to enter the SAS first.
> I don't see why this is such a controversial point.
Because It's untrue. The SAS is a sanity check.
If something is spoofing a login screen on your desktop and you press CTRL+ALT+DEL, you will get a system menu instead of a password prompt.
If you are in the login screen, which is able to hook CTRL+ALT+DEL, it will switch to the password prompt.
Here's the clincher: even if you have the SAS disabled (which it is by default on Windows 10) there is still no way for an app to steal focus from the login screen. The keyboard focus assurances are handled by something completely different - protected desktops (these also handle the UAC prompt for the most secure setting).
Full circle: even though nothing can ever steal focus from the login screen (unless it is running within that protected desktop), if you don't use the SAS there is no way for you to know that you are looking at the real Windows login screen.
