3

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.

Improve this question
7
  • To close the LUKS volume, you’d have to close all the open files that are stored in it. Does your system allow any kind of remote access (SSH, file sharing...)?
    – Stephen Kitt
    Jun 11, 2021 at 5:39
  • You can have a user with a password get a GUI auto-login.
    – A.B
    Jun 11, 2021 at 7:23
  • +1 for asking this an a way that avoids asking for opinion! I think those who voted-close "opinion based" didn't actually read the question.
    – Philip Couling
    Jun 11, 2021 at 11:12
  • @ Stephen Kitt, good points. I saw the other reply first but looks like you commented before that. I will update OP shortly but for 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 :-)
    – zpangwin
    Jun 11, 2021 at 15:06
  • @ A.B. you are absolutely correct. But what fun is trying to poke holes in that? :-) Anyway, I thought if a hypothetical setup with NO password could survive reasonably well, then the situation you are describing ought to do even better. But if you can think of attacks for that situation on non-root account, with the other things I have described (well protected root, FDE) then I think would likely accept that as answer too (it is a subset of the question I asked after all)
    – zpangwin
    Jun 11, 2021 at 15:11

2 Answers 2

Reset to default
2

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.

Improve this answer
4
  • I think I see your general point about (at least for most people) not being aware of all things on the system. I think this could be mitigated against at least somewhat by more advanced users and/or running auditing tools like lynis (which I am now curious if this tool would flag a blank password lol). For email servers/openssh stuff, I guess I have been thinking that in terms of a home network those would most likely only be vulnerable via LAN/wifi (I guess some people don't use home routers but seems likely anyone setting up FDE would know to do that much). Do routers not protect somewhat?
    – zpangwin
    Jun 11, 2021 at 15:54
  • ^ Your points are perfectly reasonable; so are FelixJN's. Starting to see one problem with my question/OP in that it doesn't blatantly say that auditing has been done but even if I changed the wording to "every possible precaution/safeguard except non-root password has been implemented", it'd still be there. Part of me is still wanting to hold out for a "concrete" example; I feel like I'm still missing a critical piece of how an exploit actually uses a blank password on an otherwise well protected system. But I guess this might be something like Linus's saying that all security issues are bugs
    – zpangwin
    Jun 11, 2021 at 16:08
  • ^ e.g. just like fixing bugs (or security issus), there is always another config / setting that could be tweaked or a new one that comes out when you update packages. In other words, it might be fair to say that the issue with a non-root account having a blank password isn't an issue in and of itself; essentially, it acts as a convienent stepping stone for an attacker when another more serious issue is present and issues of this type will always be present in any evolving system (and probably in any finished systems created by imperfect beings). So any concrete example would only be temporary.
    – zpangwin
    Jun 11, 2021 at 16:21
  • You and FelixJN both had very good answers but the way you worded yours - especially the line " The risk isn't so much the software you know, its the software you didn't think about." - seems to have got me thinking much more on it and I think contributed more to me arriving at "Any concrete examples where a blank password can be exploited are really only temporary security bugs/security misconfigurations that haven't been patched yet" so I think it is only fair to mark that as the solution.
    – zpangwin
    Jun 11, 2021 at 16:28
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.

  1. 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.

  1. 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?

Improve this answer
8
  • Could you elaborate on how 2 and 3 are related to passwords, I don't see the connection... And of course ssh defaults to refusing connection attempts with blank passwords. I wonder if you can think of another example which does not.
    – Philip Couling
    Jun 11, 2021 at 11:19
  • 2 & 3 just matter in terms of how difficult it is to gain access as a user - these points of course also apply to getting access as a user via other means. Yes, ssh does this, but the question is how far the "no-password" goes or not for the scenario.
    – FelixJN
    Jun 11, 2021 at 12:03
  • I actually hadn't considered the ssh aspect when I posted this but I think I would lean more towards Philip's interpretation for the following reasons: a) as he stated it is the default behavior of ssh to refuse blank passwords, and b) I have already stated that the system is not devoid of protection (separate, de-coupled, & well-protected root account, FDE) so intentionally configuring ssh/sshd to allow this seems out of keeping. But I do see your point that this is very dependent on how far I want to take the no password scenario and that I failed to specify - will update shortly.
    – zpangwin
    Jun 11, 2021 at 14:59
  • Re-reading, 1 other thing that I am curious about: Maybe misunderstanding?... So 2 & 3 are somewhat vague on how what kind of exploits but thinking that in many cases the exploits would not be made easier by the presence of a password. To give a somewhat more concrete example, let's say there was an exploit via the web-browser. Normally web-browser never prompts user for password to save a file, so absence of a password shouldn't matter if browser itself is compromised. I would think more than password, proper sandboxing like firejail or things like SELinux / 'AppAmour` would matter more.
    – zpangwin
    Jun 11, 2021 at 15:44
  • "Matter more" - well it think now we are going towards the problem of "option-based". Let me make my point by an analogue: Of course driving a tank will be safest in terms of road accidents, but the low speed, lack of parking spots and trunk space will make me take a car instead. Surely, it'll have an airbag for security. So the only hassle left for me is putting on the seatbelt (i.e. typing the password). Up to each individual to decide if that is too much or very little for the advantage it offers. .... I feel like we are getting too philosophical and maybe a good answer is not possible.
    – FelixJN
    Jun 11, 2021 at 16:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .