Why would having a user without a password be a bad idea (in this scenario)?

Question

I thought about whether to post this here or in security SE... but decided to go with Unix SE since this isn't really a question about cryptography stuff but more about Linux users / privileges. Maybe my google-fu is weak today but the only things I have come across so far either

1. have very general handwavy answers about it being a "bad practice" or "frowned upon" without any concrete examples, or
2. have replies that assume the user without a password has root access or is otherwise throwing away all possible protections.

To be clear: I'm not advocating this and am actually looking for valid reasons not to do this but I'd like to find concrete reasons why rather than just "it's bad". :-)

So with that out of the way, let me set up the example that actually got me thinking about this in the first place:

Let's say that I am considering setting up a home system where I have a strong password on the root account. In addition, I will have a non-root account named fred that is NOT in the admin group wheel (or sudoers on Debian / Ubuntu). On this system, I will also have /home on a separate, LUKS-encrypted partition that gets unlocked during the boot process. In other words, a password does still get entered between GRUB and the login manager - but the login manager is set to auto-login. Beyond this, let's say I also setup (from root): password -f -u fred to force unlock the password for fred (effectively making fred have an empty password).

---

What sorts of security issues could I expect to run into in this situation? It feel like there ought to be some good reason why you don't want to do this. But the only thing that comes to mind so far is:

• LUKS partitions don't get closed when the screensaver lock triggers (at least, not on Cinnamon and assuming one is set to trigger). So if someone broke into my house and fred was already logged in, they could just sit down and turn on the monitor then proceed to look through anything fred has access to - as long as they didn't unplug/reboot/carry off the PC first (and thus re-lock LUKS). And I suspect that if I tried hard enough, I could maybe find a way to call a script when screensaver is triggered and then lock LUKS from said script, thereby closing this hole (or maybe kde/xfce/gnome/etc already have some way to take care of this?).

Even if fred had a nice strong password, he couldn't install software / mess with system settings without being an admin. And, I don't know for sure, but I think browser / Wine access to files would not be changed either way. Is there anything more at risk here than if fred did have a password?

Edit: I don't think it matters but the distribution is Fedora (with SELinux on), but if you feel more comfortable answering with regards to another distribution (or without SELinux) that's fine.

Edit #2: Regarding ssh / samba. I generally setup something like a /media/sdb1/shared folder for rather than using samba's $HOME shares or whatever they're called. I find this fairly easy to setup in a small user setting like at home (I obviously would not do this in a work environment or a setting where not all users trust each other). But I do always use separate, password-protected samba user accounts (not the same users that get logged in with) and I follow several guides on hardening my smb.conf setup. If you see flaws in this setup, I will consider them valid for attacking the hypothetical scenario/setup with a blank password on the login account fred (remember the samba account password is not blank though).

For ssh, I want to confirm that the default is that blank passwords are rejected on all accounts (not just on root). If not, then I will consider FelixJN's answer to be valid. Otherwise, I would - similar to samba - probably use the same setup I normally do which is a hardened version of the default config. I don't recall changing many settings for this so I will try to see if I can find exactly which settings I usually modify and include them here. Off my head, I know I change the port number not that this matters much.

In confirming the ssh rejection, I was surprised to see that on LM19 passwd does not appear to support the -f (force) flag so oddly I was only able to create a blank password non-root user on fedora. When I tried to ssh from the LM19 box to fedora, it was refused:

    $ ssh -p 2468 fred@fedora-testbox
    fred@fedora-testbox's password: 
    Permission denied, please try again.
    fred@fedora-testbox's password: 
    Permission denied, please try again.

Aside from port, it looks like I also increased the minimum acceptable ciphers/MACs/KexAlgorithms, reduced LoginGraceTime/MaxAuthTries/MaxSessions, set PermitRootLogin no / UsePAM yes / ChallengeResponseAuthentication no. For PermitEmptyPasswords: no did appear to be the default but I had made my explicit.

Answer 1

The biggest practical reason I can think of is that some network software may allow someone to remotely log into your machine without a password. The risk isn't so much the software you know, its the software you didn't think about. Perhaps the software that came packaged with your distribution.

With passwordless users, it's your job to check every network connected service on your machine to see if it will allow remote login without a password.

A general security principle is that you want things to "fail" by locking everyone out instead of letting anybody in. If you have passwordless users then mistakes and simple oversights are more prone to unlock some backdoor somewhere.

One such example might be email servers. If you have a machine with a public IPv4 address then, guaranteed, there will be weekly or even daily attempts to login to SMTP. Hackers just cycle through every single IPv4 address looking for a vulnerable machine (there's only 4 billion addresses).

Likewise SSH. OpenSSH is configured to reject login attempts without a password (without authentication), so that's most likely safe. But I see a few attempts every day from hackers trying to find a username with a blank password. They just cycle through thousands of common usernames in the hope of getting lucky.

Answer 2

I would generally consider these aspects:

1. Remote access:

If you have any remote access options, like ssh active, this is an open door for obvious reasons. In that case points 2 & 3 especially apply.

2. Data privacy and security:

Your user exposes information that maybe should not be available to unpriviledged users and of course your date might be deleted by anybody. Some people are just destructive.

3. System security:

Of course officially the user has no admin rights, but no system is unhackable. Once someone has access as a user, no one would stop them form uploading malware, exploit security holes, compile programs locally and then breach the system ....

---

It is a matter of how many stones you like to put in someones way.

So the question is why have a non-password user, when you could also have an autologin and avoid at least some of these risks, making the need for physical access as high as possible?