Running as a standard user which means anything executing as you also has limited privileges is one of the most basic steps of securing a system. All though, as Theheyes mentioned, it is certainly not a cure-all of everything. Security is about having multiple layers of defenses. Least privilege access is only one, certainly one of the most important ones, though.
Running as a standard user doesn't protect what is arguably the most important to the user though; their data. If malware infects your system, providing it isn't written assuming it will have administrator rights and will actually work running as a standard user, then it will have access to all of the data which you have stored in that account. Having said that though, running as a standard user isn't about protecting your data, but the configuration of the system and other user accounts.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I formatted my main few days ago PC, and when next there I plan to set up an additional account using Standard User for daily purposes. WIth the intention of trying to form a habbit of using it always.
Not read the link, but do you have to password your UAC main account? As it would be handy to eliminate one step of having to type password if need to run as admin.
If you are referring to the administrator account, then yes, it's best to password protect it.
Please be aware of something regarding elevating from a standard user account though, when you need to do something which requires administrator rights, you will receive the Over The Shoulder elevation dialog which will ask you to enter the credentials of the administrator account. It's possible for malware to intercept the Over The Shoulder elevation dialog and gain the administrator credentials and then go on and infect the administrator account.
Mark Russinovich said:
Even though elevation dialogs appear on a separate secure desktop, users have no way by default of verifying that they are viewing a legitimate dialog and not one presented by malware. That isn’t an issue for AAM because malware can’t gain administrative rights with a faked Consent dialog, but malware could wait for a standard user’s OTS elevation, intercept it, and use a Trojan horse dialog to capture administrator credentials. With those credentials they can gain access to the administrator’s account and infect it.
For this reason, OTS elevations are strongly discouraged in corporate environments. To disable OTS elevations (and reduce help desk calls), run the Local Security Policy Editor (Secpol.msc) and configure "User Account Control: Behavior of the elevation prompt for standard users" to "Automatically deny elevation requests."
Home users who are security-conscious should configure the OTS elevations to require a Secure Attention Sequence (SAS) that malware cannot intercept or simulate. Configure SAS by running the Group Policy Editor (Gpedit.msc), navigating to Computer Configuration | Administrative Templates | Windows Components | Credential User Interface, and enabling "Require trusted path for credential entry." After doing so you will be required to enter Ctrl+Alt+Delete to access the elevation dialog.
Inside Windows Vista User Account Control -
Mark Russinovich
Mark Russinovich actually demonstrates this in his
Windows Security Boundaries talk, at around about the 1:03 point.
You can enable the Secure Attention Sequence to make elevating from a standard user account safer, as Mark mentions above. However, I'm not sure if this can be done if you're using versions of Windows Vista or Windows 7 which don't have access to the Group Policy Editor; Home Premium and below. If you don't have one of the versions which have access to the Group Policy Editor, it's possible that you can enable the Secure Attention Sequence from the registry. All though, I can't quite find the correct key.
It's also perfectly possible for malware to gain administrator rights by compromising an elevated process due to the shared state of processes running with standard user rights and those running with administrator rights, as it is when you are running in Administrative Approval Mode. All though, it is more difficult for malware to gain administrator rights by compromising an elevated process if you are running as a standard user as opposed to running as a Protected Administrator i.e. in Administrator Approval Mode.
Mark Russinovich said:
Elevated AAM processes are especially susceptible to compromise because they run in the same user account as the AAM user’s standard-rights processes and share the user’s profile. Many applications read settings and load extensions registered in a user’s profile, offering opportunities for malware to elevate. For example, the common control dialogs load Shell extensions configured in a user’s registry key (under HKEY_CURRENT_USER), so malware can add itself as an extension to load into any elevated process that uses those dialogs.
Even processes elevated from standard user accounts can conceivably be compromised because of shared state. All the processes running in a logon session share the internal namespace where Windows stores objects such as events, mutexes, semaphores, and shared memory. If malware knows that an elevated process will try to open and read a specific shared memory object when the process starts, it could create the object with contents that trigger a buffer overflow to inject code into the elevated process. That type of attack is relatively sophisticated, but its possibility prevents OTS elevations from being a security boundary.
Inside Windows Vista User Account Control -
Mark Russinovich
This is not some kind of massive vulnerability in the User Account Control design though. When ever you elevate, you are introducing a security risk to the system. Elevating is purely a convenience for the user, nothing to do with security. If you truly want a secure environment to do administrative operations, you are going to need to switch to a dedicated account which hopefully won't be infected with malware. If you are someone who switches to a dedicated administrator account to perform administrative operations, then you may as well disable the elevation dialogs entirely for administrators. You can do this by navigating to the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System and finding the following value name
"ConsentPromptBehaviorAdmin" which should be second to top. If you then double click on it and set the
"Value data:" to
"0". Once you have done this, when you need to do any operations which require administrator rights, instead of receiving the consent elevation dialog and having to click "Yes", the operation will automatically be granted administrator rights.
Jim Allchin said:
The true test of how secure any system will be in practice has as much to do with how it is deployed as it does with its architecture and code quality. And how the system is deployed has a lot to do with usability and convenience. (If you don’t lock your doors at night because it is too much of a hassle, the locks don't offer much security.) Our goal is that the most generally applicable security configuration (remember, this is a combination of architecture, code quality and usability) is deployed by default. We sometimes use defense-in-depth approaches when designing security measures instead of hard boundaries for this reason. We also know that there are certain customers who, even with a deep understanding of the usability issues, may choose to enable a more locked down system than we could ever ship by default. For these people, we provide great flexibility to turn on even more protections. What makes this even more complex is that given how broadly a product like Windows Vista will be used, some people may try to create sensationalist headlines by calling out some apparent "weakness." Before they do, it is important to remember that the design was more likely a deliberate design choice that was balancing some other factor such as usability or application compatibility, rather than an oversight.
Security Features vs. Convenience - Jim Allchin
Im sure we have all come across some of *those* articles at some point.
