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 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 anythingfred
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.
ssh
I am leaning toward system defaults which would reject blank passwords. I will, of course, verify this on a live system first. As for samba, I generally set that (at home) as a multi-user "shared" folder outside of individual$HOME
folders (e.g./media/sdb2/shared
), and whether it bites me or not for this, I would probably do the same for this hypothetical setup... But if someone can point out reasons why not to, I might change my real-world setup :-)