Importance of "Standard User" Windows account vs "Administrator" account ?

[jetman]

Hi-

Just a quick question.

I have read in some places that it is better to create two accounts on a Windows PC- a "standard user" account (used for most day to day activities) and a password protected "administrator" account for when it is necessary to install software or make system changes. Apparently, this may help to guard against malware in some instances.

Can anyone comment on whether this actually leads to any improvements in security in practice ? Is it actually worth doing most day to day PC activites as a standard user ?

Microsoft dont really mention this to the average home user.

Thanks.

 

[AtlBo]

I run both in W7 64, and I don't notice the difference from a user standpoint. I have UAC set up to alert all and both accounts are password protected. In the standard account there are prompts for admin password from apps that require admin privileges to run, but it hasn't bothered me like I thought it would. Happens for numerous Windows operations too like accessing the Management console or system restore settings.

It's good discipline, but I wouldn't say I prefer using a standard account. Think it's more a respect for security that kind of adds to overall confidence. Can't speak for differences between W7 and W10 unfortunately. Using W7 on all PCs here but a couple of XP machines.

 

[Deleted member 65228]

If you're an administrator and need to open applications with elevated access regularly then an administrator account tends to be more convenient, however standard rights or not, if you allow an application to run with elevated access... then there's no security difference. UAC can be harder to bypass on a SUA if configured properly though.

 

[Andy Ful]

The default account, on Windows Vista and later versions, forces the user to run applications as standard user and allows to elevate applications (via UAC) on the same account. This is very convenient, but in fact, applications ran as standard user and applications ran elevated, share the same user profile, the same desktop, the same HKCU Registry Hive, etc. So, it impossible to isolate processes running as standard user from processes running elevated via UAC. Microsoft knew this before adopting UAC on Windows Vista, and always advised to use the Standard User Account (SUA) for daily work.
On SUA you run applications as standard user, and when you want to run an application with elevation you have to write Administrator credentials = you are logging to the Administrator account. So, elevated applications run on another account - they do not share the user profile, HKCU Registry Hive, etc., with applications ran as standard user. They still share the same desktop, but the attack surface is very limited as compared to the default account.
.
The most secure solution is not sharing even the desktop, because in theory, the malware can use this to elevate. You can accomplish this when using SUA for daily work and avoiding to elevate from SUA. If you want to run something elevated, then log-on to the default Administrator account. Now you have the best isolation between applications ran as standard user and elevated applications, because they do not share the same user profile, the same HKCU Registry Hive, and the same desktop.

 

[AtlBo]

If you're an administrator and need to open applications with elevated access regularly then an administrator account tends to be more convenient, however standard rights or not, if you allow an application to run with elevated access... then there's no security difference. UAC can be harder to bypass on a SUA if configured properly though.

You do also get prompts for applications you don't use frequently, so that is an addition, assuming your security program doesn't alert to the elevation request. Think I am getting this correct.

The most secure solution is not sharing even the desktop, because in theory, the malware can use this to elevate. You can accomplish this when using SUA for daily work and avoiding to elevate from SUA. If you want to run something elevated, then log-on to the default Administrator account. Now you have the best isolation because applications ran as standard user and elevated applications, because they do not share the same user profile, the same HKCU Registry Hive, and the same desktop.

If I run in SUA and run elevated only applications that I know to be safe, am I still following the safest SUA account usage for everything else? Also, could you explain a little bit how the desktop in an SUA could be abused?

 

[Andy Ful]

If I run in SUA and run elevated only applications that I know to be safe, am I still following the safest SUA account usage for everything else? Also, could you explain a little bit how the desktop in an SUA could be abused?

No. If you are running both non-elevated and elevated applications on the same desktop, the isolation is still invalid. But, this may be important only when something is exploited (web browser, text editor, document viewer, media player, etc.). In the real world scenario, you are very secure, because criminals do not bother to abuse SUA. They have the easy victims on the default account.
It is hard to find the details of abusing shared desktop to elevate on SUA. I did not hear of the malware in the wild that could do this (except maybe a variant of NotPetya posted by @cruelsister). Anyway, the desktop can be used to steal the admin password (even from the secured desktop). If so, the malware can elevate, when using runas command-line tool that is built into Windows.
.
Edit
If one uses SUA and allows the legal application to elevate from SUA, then for the short time, the malware and the not-yet-elevated application share (in a limited way) the same user profile, the same HKCU Registry Hive, the same desktop, etc. But, it is not easy to exploit this as compared to the admin account.

 

[AtlBo]

Very interesting and thanks. If I understand, the compromise depends on the single application running elevated being compromised or say, for example, if I choose to run one elevated that I know is safe->it being compromised somehow. Or another way what I am saying is that only the elevated applications are vulnerable and could cause the problem, not the entire SUA account. This is unless I misunderstand things...

Seems to me unlikely that there are more than a few "known by hackers" vulnerabilities at this point for known safe applications that require elevation to run in SUA.

Very helpful specifics on the SUA and the benefits of running in this type of account. I have been picking it up ever so slowly, using it on the main PC for a year and a half I guess now.

As for runas, what about adding it to vulnerables? Think maybe this is something I should do with ERP. Does runas actually execute command line?

 

[Deleted member 178]

SUA wasn't made for security, it was a privacy boundary, so users can't peep others datas. However with UAC, it helps because malware most often requires higher privileges which needs to be granted by the users.

 

[CMLew]

I use SUA all the time on my secured laptop. Coupled with WFC, if there's any malware wanting to access, I would know for sure.
Hence on my laptop I install as little software inside as I could. Everything else, portable apps via USB drive.

 

[Andy Ful]

Very interesting and thanks. If I understand, the compromise depends on the single application running elevated being compromised or say, for example, if I choose to run one elevated that I know is safe->it being compromised somehow. Or another way what I am saying is that only the elevated applications are vulnerable and could cause the problem, not the entire SUA account. This is unless I misunderstand things...

Seems to me unlikely that there are more than a few "known by hackers" vulnerabilities at this point for known safe applications that require elevation to run in SUA.

Very helpful specifics on the SUA and the benefits of running in this type of account. I have been picking it up ever so slowly, using it on the main PC for a year and a half I guess now.

As for runas, what about adding it to vulnerables? Think maybe this is something I should do with ERP. Does runas actually execute command line?

​

.
Not exactly. The probable bypass on SUA requires exploiting something (or running the malware) not elevated and wait for another process that starts as standard user and is allowed by the user to elevate. So both processes must run for a while as standard user on SUA.
The process that is already elevated, does not actually run on SUA, but on another account (Administrator account). That can be also used by the malware (keyloggers), because the desktop is still shared. In theory, the shared desktop could be used also to elevate malware in the period of time when the user does not elevate anything, but this would be unlikely, as you mentioned in the post.
.
The conclusion.
If one uses SUA and allows the legal application to elevate from SUA, then for the short time, the malware and the not-yet-elevated application share (in a limited way) the same user profile, the same HKCU Registry Hive, the same desktop, etc. This is still better than on default admin account, but not as good as using SUA without allowing to elevate.
.
Edit
I edited my previous post to include the above conclusion.

 

[shmu26]

Hi-

Just a quick question.

I have read in some places that it is better to create two accounts on a Windows PC- a "standard user" account (used for most day to day activities) and a password protected "administrator" account for when it is necessary to install software or make system changes. Apparently, this may help to guard against malware in some instances.

Can anyone comment on whether this actually leads to any improvements in security in practice ? Is it actually worth doing most day to day PC activites as a standard user ?

Microsoft dont really mention this to the average home user.

Thanks.

The simple answer is that most malware cannot run in a SUA (standard users account). So it's a very easy way to beat most of the baddies. If you are on windows 8 or 10, you can make a four-digit pin, which you can use when prompted, instead of typing in your whole admin password. The most popular excuse for not using SUA is the hassle of typing in your password. So just use a pin.

 

[AtlBo]

That can be also used by the malware (keyloggers), because the desktop is still shared. In theory, the shared desktop could be used also to elevate malware in the period of time when the user does not elevate anything, but this would be unlikely, as you mentioned in the post.

This does seem like a remote chance on a well secured computer. Maybe good anti-keylogger/anti-clipboard monitoring software is good insurance anyway. Thanks for the knowledge.