Update on 13 March 2013: A recent blog entry on The Old New Thing mentions a talk, during which Aaron Margosis, in addition to stating that the policy isn’t very effective because people forget having to press Ctrl+Alt+Del and will just enter their password when the prompt shows up, confirms that usability is indeed a problem.
In Windows NT, Ctrl+Alt+Delete is known as the secure attention sequence or SAS. If you ever tried installing Windows Server 2003, you will be prompted to ‘Press CTRL+ALT+DELETE to log on’. The procedure makes logging on more secure. How’s that more secure? For an uninfected copy of Windows, the sequence is handled exclusively by Windows. Once Windows intercepts SAS, it brings the user to the Secure Desktop, which consists of authentic Windows UI. The user can be confident that whatever he or she enters will not be handled by some bogus software.
Depict a scenario where you typically use Windows+L to lock your computer, some trojan might set HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableLockWorkstation to 1 and handle Windows+L itself. It presents a fake Lock Screen, as if the computer were locked. When you swipe up the fake Lock Screen, it presents you with a fake Welcome Screen, asking for your credential. It validates your credential with LogonUser function and hides itself if the validation succeeds. The problem? You’ve just entered your credential into a trojan! If you require yourself to press SAS before logging on, and if you do that before entering your credential to the fake Welcome Screen, Windows will take control and you will realise that a trojan was trying to fool you.
When Windows 8 came out, tablet PCs without a keyboard become more common (actually there has always been the problem since at least Windows XP). How do you perform SAS without a keyboard? Windows handles at least 2 more SAS, one Power+Volume Down, the other a dedicated hardware button called ‘Windows Security’. I actually tried enabling the requirement of SAS before logging on on my Surface RT, and it worked pretty well — you’ll be prompted to press SAS on Lock Screen, after which you will see Welcome Screen.
Okay, so much for background knowledge. What’s wrong with SAS? In yesterday’s entry, I mentioned Mark Russinovich’s TechNet Magazine article, where you could find a suggestion to require trusted path for credential entry to thwart trojans mimicking UAC credential dialog.
If you open Group Policy Editor, enable the policy ‘Require trusted path for credential entry’ under Computer Configuration | Administrative Templates | Windows Components | Credential User Interface, you will see it in effect. The policy also affects other places where Credential UI is involved. Whenever an elevation is required, a dialog pops up, saying ‘Enter my credentials on the authentic Windows sign-in screen’ with two choices, OK and Cancel. If you press OK, you will be prompted to ‘Press Ctrl+Alt+Delete or press and hold the power button, and then press the volume down button to enter your credentials’ (the prompt might vary by the availability of input hardware). Then you can press SAS, and do the normal elevation procedure.
What’s the problem here? There are many:
- Even if you are an administrator and are using Admin Approval Mode, you still have to go through the complicated procedure. However, the SAS is redundant because you don’t actually enter your sensitive credential. As mentioned in the TechNet Magazine article, a faked AAM dialog is not harmful. This problem itself does not kill the feature, but when combined with the next problem, I wonder how many users actually stand such mumbo-jumbo.
- The procedure is over complicated for efficient usage. The flow can be simplified for UAC scenario. Windows could switch to the Secure Desktop, ask the user to press SAS before continuing, just like the logging-on scenario. This saves the user a mouse click or two keyboard hits (first Tab away from Cancel, then hit Enter; and sometimes even more, see the next problem). Switching directly to the Secure Desktop and asking for SAS and then the consent is much more fluent than the current flow for AAM elevation. For other scenarios (non-UAC scenarios), whether letting the user to acknowledge before prompting for credentials or going directly to the Secure Desktop remains to be discussed. I would say going there directly is better. Most of the time when a Credential UI dialog comes up, the user indeed knows he or she needs to enter a credential.
- If you start a program with
"runas"verb in PowerShell, the prompt dialog does not automatically get focused. (If the policy is disabled, the UAC consent dialog automatically gets focused, and of course you expect that to happen!) - If the policy is enabled, you don’t get the desktop background when approving UAC elevation, and the icon shown in the consent dialog will always be the generic executable file icon. While it’s not the most important thing, it does make the dialog less stylish.
The most significant problem is the usability. The secure flow is designed to be so difficult to use! I wish Microsoft could rectify this problem in near future.
Please enable JavaScript to view the comments powered by Disqus.