# Can it be secure to have root/user accounts without password

## litan

Hi,

whenever I installed machines, I followed the prevalent advice to use strong passwords for accounts,

especially the root account, since security is important to me.  Now that I learned more about Linux/Gentoo,

I can’t shake the feeling that I simply waste my time typing some of these passwords again and again.

But before I remove my root passwords, I wanted to get some feedback if this is really safe.

Details:

I have a couple of virtual machines where I log in as root to do system administration and as normal user

to do normal user things. The host has strong passwords for all accounts and I lock the screen/log out on

consoles when necessary. On the VMs I would like to log into the console as root and different users

without the need to enter a password (how to accomplish this technically is not part of the question).

I want to leave them logged in on the consoles and only lock the host.

I use those VMs for production and they hold sensitive data, so security is paramount but I don’t necessarily

want to compromise usability for redundant layers of protection.

In case it is relevant, I do not use sudo and don’t want to change this if at all possible.

While it is not my use case, I believe it would be the same for a bare metal machine that nobody has physical access to.

As I understand, in order to not compromise security by not having passwords, I would have to do at least the following:

- make sure that on the VMs no user is in the group wheel (which should block any user switching)

- if OpenSSH ist used, forbid login via password:

```
PasswordAuthentication no

PubkeyAuthentication yes

```

Now I am wondering what a root/user password can actually do for you in a scenario like this,

besides providing some pseudo protection against a local attacker if I forget to lock the host

and have no active login on the VM. I did some research and found a lot of people who believe

passwordless users and especially passwordless root are a bad idea but without providing a real explanation.

My questions are:

- Is such a setup secure? If not, why? What is missing to make it secure?

- What applications besides OpenSSH do I have to be aware of in order to not get into trouble?

- What are other (potential) dangers?

- Are there considerations unique to Gentoo in contrast to other Linux distros?

- If I want to have a user that is allowed to become (with su) some other users but not all users (especially not root) and not vice versa, how would I accomplish this?

Thanks

----------

## joanandk

This question is the same as if one would ask us, do I have to lock my safe? I always lock my main door.

So to your question: No, it is not safe.

----------

## Suicidal

I would use ssh keys without passwords before not requiring passwords on accounts.

At least that way you are still requiring a key to unlock the door.

----------

## Ant P.

By removing the password you'll no longer be able to log in to those accounts without sudo or ssh keys. So yes, in effect it's more secure.

----------

## litan

 *joanandk wrote:*   

> This question is the same as if one would ask us, do I have to lock my safe? I always lock my main door.
> 
> So to your question: No, it is not safe.

 

Please be more specific as to how you would attack my setup.

 *Suicidal wrote:*   

> I would use ssh keys without passwords before not requiring passwords on accounts.
> 
> At least that way you are still requiring a key to unlock the door.

 

This is about console login. As stated in my question, I am already using keys for remote login.

 *Ant P. wrote:*   

> By removing the password you'll no longer be able to log in to those accounts without sudo or ssh keys. So yes, in effect it's more secure.

 

That is not correct.

Afer a 'passwd -d testuser' I am able to log in at the console as testuser by simply pressing enter on the password prompt.

----------

## Ant P.

 *litan wrote:*   

> Afer a 'passwd -d testuser' I am able to log in at the console as testuser by simply pressing enter on the password prompt.

 

Sounds like you've been caught in a PAM trap. You might want to double-check that you can't log in as other passwordless /etc/passwd entries like shutdown, operator and games.

The default behaviour with a no-PAM system is to lock an account with no password.

----------

## litan

 *Ant P. wrote:*   

>  *litan wrote:*   Afer a 'passwd -d testuser' I am able to log in at the console as testuser by simply pressing enter on the password prompt. 
> 
> Sounds like you've been caught in a PAM trap. You might want to double-check that you can't log in as other passwordless /etc/passwd entries like shutdown, operator and games.
> 
> The default behaviour with a no-PAM system is to lock an account with no password.

 

I double-checked with shutdown and operator. It works as expected (no login possible).

But I am wondering why you assume a no-PAM system.

I have sys-libs/pam-1.3.0-r2 installed.

The /etc/shadow entries are of the form:

shutdown:*: [...]

testuser:: [...]

----------

## litan

I can think of 5 scenarios where the user password is asked for:

1) console login

2) su

3) ssh password authentication

4) sasl authentication via postfix/dovecot (possibly other server side mail software too)

5) sudo

Of those, I believe, only 1) applies per default, all others require deliberate action to be in effect.

For them to be of concern, I would have to at least do the following:

2) add users to wheel group

3) add sshd to default runlevel

4) install and configure postfix/dovecot with sasl authentication

5) install sudo

So my line of thought is:

1) if I physically make sure nobody has console access (by locking the screen of the password protected host machine - remember, we are talking about virtual machines here)

2) and don't add anybody to the wheel group

3) and make sure password authentication is disabled in OpenSSH

4) and don't install postfix/dovecot

5) and don't install sudo

then there should be no opportunity for an attacker to ever get access to an account.

(Be it by knowing the account password or by the account not having a password at all)

Thus this setup would be secure.

I am sure there are more software packages that would be a problem with paswordless users if installed and

not carefully configured.

Since I did not yet receive an explanation for any of my questions, I would like to ask again:

- Am I missing something or is this setup indeed bulletproof?

- What default or even common features/packages on a typical Gentoo installation would be of concern for passwordless user / root accounts?

- What extra packages can you think of that would be a problem?

If you believe this setup is not secure, please explain how an attack would look like.

----------

## NeddySeagoon

litan,

For remote systems, disable root logins entirely.

This forces attackers to log in as a user then use sudo or su to become root.

Its a bad thing to have a bot brute force you root password.

Lets look at what an attacker needs to get in. Its not a lot. A valid user name and the matching password.

Everyone has a root user, so that's 50% of the required information gifted to them.

Use key based logins for users. Its your call if you set a password on the ssh key.

The key never leaves your machine. ssh key based logins are challenge/response based.

If your system is physically secure, that may be good enough. If its a laptop that is not physically secured, you want a password on the key.

Consider storing the key in a hardware token, like a Yubikey. There are several others.

This is all well and good when everything works as intended. Security is like the layers of an onion.

The idea is not to keep determined well funded attackers out. Just to make it clear that you have given security some thought and that there are easier targets to attack.

It really is like this xkcd.

----------

## litan

Hi NeddySeagoon,

while your post is not directly related to my question, you brought up a point that I also find quite interesting:

 *NeddySeagoon wrote:*   

> 
> 
> For remote systems, disable root logins entirely.
> 
> This forces attackers to log in as a user then use sudo or su to become root.
> ...

 

I doubt that this is necessarily true. One could equally just have a longer password, which is cheap if you use a password manager.

If you follow best practices regarding high entropy passwords, it should not really matter if someone has the chance to brute force

your password or not, especially in a low bandwidth situation like ssh.

A typical user name also has very poor entropy as compared to a strong password generated with a good random number source.

So its much less than 50% of the required information and as I said, this fraction can be shrunk almost arbitrarily by having

a longer password.

Further, I would even suggest that logging in as a user and then using su might have a downside to logging in directly as root:

Once an attacker has gained access to your user account, it is trivial for the attacker to intercept the root password the next time you use su.

This might just happen before you notice the attack if your intrusion detection is not up to par.

So in this scenario you effectively made your user account your root account so it would be essentially no different to enabling root login directly.

But now the downside:

You want to have a unprivileged user account for mainly two reasons:

1) to execute as many commands as possible without root privileges so that you are less likely to do mistakes like rm -rf / or run

programs that connect to the internet as root

2) to contain a security compromise if your internet connecting program has been exploited

While you are protected against your own mistakes according to 1) if done consequently, advantage 2) is completely lost if you use su.

(we don't count the security through obscurity/luck gain that only works against attackers that don't intercept your root password for some reason)

This holds for ssh password authentication as well as key authentication.

If you are using sudo in a password authentication scenario, it gets even worse:

An attacker that has brute forced your user password or got it by any other means, will just be able to use sudo with that

same password to gain root privileges. At least that is how sudo worked on all the Ubuntu installations I have used (never used it since).

The only advantages of using sudo that I am aware of are:

- having an audit trail on a multi admin system

- to make a system in a shared environment a little more secure against unsophisticated attackers

- and to limit the bad effects of your mistakes if you are prone to making those by giving you some extra time to think while you have to type your password.

I think they don't outweigh the serious downside.

 *NeddySeagoon wrote:*   

> 
> 
> Use key based logins for users. Its your call if you set a password on the ssh key.
> 
> The key never leaves your machine. ssh key based logins are challenge/response based.
> ...

 

That's right.

Part of my described setup actually is that I use keys and forbid password login for SSH. (see my initial post)

By the way: there are other good reasons to have a password on your ssh key, even if the system is physically secure.

One of them is that nobody can get your key from main memory when exploiting some vulnerability in ssh or some other

software. I remember a OpenSSH vulnerability that allowed an remote attacker to see parts of your memory.

 *NeddySeagoon wrote:*   

> 
> 
> Consider storing the key in a hardware token, like a Yubikey. There are several others.
> 
> 

 

That is also a good idea but I would not recommend something proprietary like Yubikeys but rather the

both open source software and open hardware products Nitrokey or Librem Key

https://www.nitrokey.com/

https://puri.sm/products/librem-key/

 *NeddySeagoon wrote:*   

> 
> 
> This is all well and good when everything works as intended. 
> 
> 

 

Are you referring to what you just described or to the setup that I detailed in my previous posts?

 *NeddySeagoon wrote:*   

> 
> 
> Security is like the layers of an onion.
> 
> The idea is not to keep determined well funded attackers out. Just to make it clear that you have given security some thought and that there are easier targets to attack.
> ...

 

I knew this xkcd, its hilarious  :Smile: 

I would add that, while I think it is generally a good idea to improve security by adding redundant layers,

that will always be a trade off to usability. Some of those layers in this model are usually critical,

while the others are optional.

While you would gain security by using AES256 vs. AES128, AES128 is still secure in 2018.

That brings me back to my original question:

Can user/root passwords be an optional (redundant) layer of security in the setup that I described in my previous posts

or are they always critical?

By 'secure' I mean  that nobody will be able to compromise the system without either

a unpatched vulnerability, a breakthrough in the field of cryptography, or human error on the defender side.

(like in the AES128 example)

Thank you.

----------

## NeddySeagoon

litan,

Anyone who has physical access to your system can image its RAM almost totally intact.

There are two methods.

1) Reboot a USB key an save a RAM image. RAM is not wiped on reboot, or even power off.

2) Remove the RAM while the system is powered up and image it elsewhere.

Even though its DRAM and the contents must be refreshed, the contents take much longer to decay than the refresh time.

Google knows of both these attacks.  Worse, decrypted key recovery has been demonstrated following both of these attacks too.

It boils down to analysing your threat model, then deploying suitable defences.

Not forgetting the $5 wrench too.

I wasn't recommending Yubikey, As you say, there are other open examples.

They all have one flaw. They are trying to create write only memory and that's hard to do in a way that can be useful.

----------

## Ralphred

Guys, you can go at this for days.

Unequivocally, security is always a trade-off against usability.

A password, by definition, is only security through obscurity.

If in your use case the machine is 100% physically secure, and there is no vector for remote attack that can utilise a password, the password is moot.

If ,however, there are more secure alternatives for you to access the machine (re: priv/pub key auth), that allow you the same level of usability, whilst at the same time allow the increasing of the inherent entropy of your "obscure" yet unused password, it would be irresponsible to not take advantage of this in a "production" environment involving "sensitive data".

 *Quote:*   

> I did some research and found a lot of people who believe passwordless users and especially passwordless root are a bad idea but without providing a real explanation. 

 

Let me offer an explanation, after 25 years in security I can tell you the best way to secure a machine is to unplug it from the rest of the world and have 2 guys with loaded firearms guard it at all times, even then I'd still put a password on it, because "No, we had two mercs with ak's guarding it." is never an acceptable answer to "Did you change the default password?" in a debrief.

----------

## litan

Neddy

 *Ralphred wrote:*   

> Guys, you can go at this for days.
> 
> Unequivocally, security is always a trade-off against usability.
> 
> A password, by definition, is only security through obscurity.
> ...

 

Thanks for answering my question, Ralphred.

Since no one brought up valid arguments against it, I think I will now go for it and remove the passwords

on my VMs where I implement the mentioned security precautions.

If someone who thinks we missed something joins the party, please chime in.

 *Ralphred wrote:*   

> 
> 
>  *Quote:*   I did some research and found a lot of people who believe passwordless users and especially passwordless root are a bad idea but without providing a real explanation.  
> 
> Let me offer an explanation, after 25 years in security I can tell you the best way to secure a machine is to unplug it from the rest of the world and have 2 guys with loaded firearms guard it at all times, even then I'd still put a password on it, because "No, we had two mercs with ak's guarding it." is never an acceptable answer to "Did you change the default password?" in a debrief.

 

Yeah, but as but if I understood you correctly, that point should not apply to my case since I only remove

the passwords on VMs and lock the screen/consoles of the host system with strong passwords.

----------

## NeddySeagoon

litan,

 *Quote:*   

> Yeah, but as but if I understood you correctly, that point should not apply to my case since I only remove
> 
> the passwords on VMs and lock the screen/consoles of the host system with strong passwords.

 

As long as there is no other attack vector to the VMs.

e.g. they are not reachable from the network.

----------

## litan

 *NeddySeagoon wrote:*   

> litan,
> 
>  *Quote:*   Yeah, but as but if I understood you correctly, that point should not apply to my case since I only remove
> 
> the passwords on VMs and lock the screen/consoles of the host system with strong passwords. 
> ...

 

Neddy,

thank you for your input.

Well, some are reachable from the network.

I run different services on them, including:

- openssh (only key auth, password auth disabled, so this should be secure I believe)

- asterisk

- apache2 (with some sites using authentication but that is done via separate htpasswd files)

- OpenVPN (authentication is done via TLS certificates)

- postfix/dovecot combo with both pop3 and smtp auth done via dovecot SASL (I know that I need to be careful here to prohibit access to accounts without passwords in the dovecot configuration because it uses PAM for athentication by default)

Anything here that stands out as problematic?

Or are you thinking about other attack vectors from the network side?

I assume that client-applications on those VMs shouldn't be a problem.

Any other applications that come to mind that rely on user passwords for privilege separation?

Maybe locally?

I find the dovecot case especially worrying because of the default behavior. I don't need to configure

each account that I want to use for mail explicitly but all accounts on the system are considered.

If I had forgotten that fact I might have enabled the whole internet to read my mail and abuse my system as a mail relay.

I don't know much about PAM but it looks to me like every application that uses PAM authentication by default will be a problem. Is this the case?

On the other hand, I read that OpenSSH reads /etc/shadow by itself if configured with UsePam=no so there is also this type of application to be aware of.

I found another local  program besides su that asks for a password: login

but that seems to be possible only for root so it should be safe?

----------

## NeddySeagoon

litan,

I don't know enough about how authentication operates on these programs to offer any useful commentary.

----------

## litan

 *NeddySeagoon wrote:*   

> litan,
> 
> I don't know enough about how authentication operates on these programs to offer any useful commentary.

 

Thanks anyway. Your feedback is much appreciated like that from all of you! Thank you for your time!

----------

