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
- have very general handwavy answers about it being a "bad practice" or "frowned upon" without any concrete examples, or
- 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
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
fredwas already logged in, they could just sit down and turn on the monitor then proceed to look through anything
fredhas 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?).
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
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).
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
PermitRootLogin no /
UsePAM yes /
ChallengeResponseAuthentication no. For
PermitEmptyPasswords: no did appear to be the default but I had made my explicit.