Any security advantages in using a Standard Account in Vista?

[Blackcat]

On a standalone computer with only one user is there any enhanced Security in using a Standard user account? .

Compared to the default Admin account are there any other major (security) differences apart from just slowing me down by having to type in my password.?

One difference I have found is that for some reason the Standard account runs a lot faster :P ???

[Lucy]

In LUA, the system runs at least privileges, even explorer.
In admin, UAC deprives upon execution, and asks for user to make a choice when necessary. It works the other way around. It is neither logical, nor good in terms of security.

If you are constantly putting your pasword on UAC, either you didn't fully configure your user account, or you are using badly written apps. Configure your LUA, and put UAC in quiet mode thanks to TweakUAC and it should be better when under LUA.

You know, UAC is not a security tool and was not primarily designed for this purpose.

I quote from a M$ MVP:
The fact that the default (protected) admin account actually has
the user running limited, makes people think it is okay to run in this
account for their day to day activities. It should be pointed out that
even in Vista you should create a standard user account for yourself and
everyone else that uses the computer. For the occasional administrative
task you can supply credentials at the consent prompt. If you are going
to do alot of admin stuff - use whatever admin account suits you.

[Dogbiscuit]

-{ Quote: "You know, UAC is not a security tool and was not primarily designed for this purpose." }-
More details here: Microsoft: UAC not a security feature (http://www.networkworld.com/news/2007/021407-microsoft-uac-not-a-security.html)

[MrBrian]

From http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx:

-{ Quote: "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.

The bottom line is that elevations were introduced as a convenience that encourages users who want to access administrative rights to run with standard user rights by default. Users wanting the guarantees of a security boundary can trade off convenience by using a standard user account for daily tasks and Fast User Switching (FUS) to a dedicated administrator account to perform administrative operations. On the other hand, users who want to forgo security in favor of convenience can disable UAC on a system in the User Accounts dialog in the Control Panel, but should be aware that this also disables Protected Mode for Internet Explorer." }-

See also this thread (http://www.wilderssecurity.com/showthread.php?t=215470).