0

I am considering running public web and application servers with blank root/Administrator passwords, and I'm wondering whether this might be a bad policy.

I see several advantages of having no password. "No password" can't be brute-forced, lost, forgotten or end up in the wrong hands. Administrators will need to log in with their personal accounts, making it easier to see who has access and is doing what, instead of keeping track of who knows the root password. If you manage to lock yourself out, it's easy to reactivate any account with physical access to the machine.

I run mostly Ubuntu 14 and Windows Server 2008 servers, both of which refuse remote logins for accounts without passwords by default. The Linux machines are accessed via SSH, the Windows machines are accessed via RDP, as well as SSH through Copssh. The server is physically protected enough for practical purposes, anybody who manages to gain access would be able to do damage anyway, regardless of passwords.

The question is, may this a good security policy or are there practical considerations here I haven't thought of? Specifically, are there any particular services in Windows or Linux that may allow remote access to a machine, through accounts with blank passwords?

EEAA
  • 108,414
  • 18
  • 172
  • 242
Jakob
  • 25
  • 1
  • 2
    Do you actually mean a blank password, or do you mean a disabled account on the Linux side? For example if you have `root:*:...` for `getent shadow root` the password is not blank, **the account is disabled** for password authentication. A blank password would look like `root::...` and that is very bad. – Zoredache Sep 11 '14 at 23:20
  • My intent was to leave the root account enabled but with a blank password, making it possible to log in without a password, but only on the physical console. Can you please elaborate why a blank root password is "very bad"? How can it be used to compromise a (Linux) computer without physical access to the machine? – Jakob Sep 12 '14 at 08:12
  • 1
    It would cause you to flunk PCI. http://www.jscape.com/blog/bid/84215/Required-MFT-Server-Password-Settings-for-PCI-DSS-Compliance-Part-1 http://www.qcode.co.uk/pci-dss-requirement-8-part-3-user-password-policy/ You asked if it was a good idea or a bad idea. Multiple people have told you it's a bad idea. – Katherine Villyard Sep 12 '14 at 20:47
  • Likely relevant to your question: http://security.stackexchange.com/questions/66894/is-it-wrong-to-root-login-with-ssh – kasperd Sep 13 '14 at 08:55
  • The question is not whether or not to login as root (which I agree is bad), but whether leaving the account active with a blank password is bad. Yes, multiple people have told me is a bad idea, but I'm asking why? What actual damage does it do? – Jakob Sep 13 '14 at 10:57

4 Answers4

5

Speaking from a Windows standpoint: Blank passwords can absolutely be brute-forced. Pen testers do it all the time. It seems to me that at that point a user with enough access to map a drive could replace a service executable and then restart the service remotely, for example.

From a linux standpoint, anyone with a valid login would then be able to su to root.

In other words, no, I would not use this as a security policy.

Katherine Villyard
  • 18,510
  • 4
  • 36
  • 59
  • well I've tested doing "su" on a Ubuntu machine which has no password set, and then I get the error message "su: Authentication failure". So, the user would actually have to enter "sudo su" and enter their own password, and of course also have sudo access. Do you know if this behaviour is different across Linux versions? – Jakob Sep 11 '14 at 21:07
  • the users need to be in /etc/sudoers or in wheel group inorder to do that – resultsway Sep 11 '14 at 21:27
  • I'll just say that it's not traditional best practice and leave it at that. – Katherine Villyard Sep 11 '14 at 21:41
  • What I mean with "blank passwords can't be brute-forced" is that you can't log in by guessing the password -- even if you guess the correct password (empty), it won't allow you to login (through SSH and RDP). Or do you mean something different? I also don't understand the problem with mapping drives, can you please explain? – Jakob Sep 11 '14 at 21:43
  • 1
    To clarify, on Ubuntu the machine has a disabled root account, not an account with a empty password. There is a very big difference between blank, and disabled. – Zoredache Sep 11 '14 at 23:22
  • @Zoredache Indeed! – Katherine Villyard Sep 12 '14 at 00:50
  • Windows has "administrative shares," which includes the system drive (for example, \\servername\c$). Administrative accounts can map these shares and replace files, and can also remotely restart services. So if I stop a service, replace a service executable with something else (say "evilprogram.exe"), and then start the service, I fool the box into running that program. Another random example is to set a startup script in c:\windows\system32\grouppolicy\machine\scripts\startup and then reboot the machine remotely. This script could be resetting the administrator password with net user. – Katherine Villyard Sep 12 '14 at 01:15
  • I understand the danger of mapping system shares, but as you say, in order to do that you need to log in with another administrative account anyway to do it in the first place, so I don't understand how this is affected by the main administrator account having a password or not? – Jakob Sep 12 '14 at 08:14
  • 1
    No. In order to map a drive with a blank administrator password, I just need to map the drive. – Katherine Villyard Sep 12 '14 at 19:40
  • That does not appear to be correct. Windows 2003, 2008 and 8 denies users without passwords to access shared resources. That behaviour can be changed by turning off "password protected sharing", but is on by default. – Jakob Sep 13 '14 at 10:53
4

You're right that your admins should be using individual user accounts. Shared accounts are a bad idea all around.

On the Windows side the blank password idea seems pretty bad. Anyone who manages to get unprivileged local code execution on a machine will have a much easier time of escalating privileges with a blank RID 500 Administrator password, in my opinion. Even with the policy setting to limit blank password logons to the console you're running a risk that Microsoft has missed a method to utilize a blank password remotely.

No one needs the Windows RID 500 Administrator password, so "keeping track" of the people who know it is unnecessary. Set it to a long, random, high-entropy string during installation, physically document it, and lock up that physical documentation.

The risk / reward equation of this blank password strategy seems out of balance to me.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • Yeah, I would also recommend disabling administrator. – Katherine Villyard Sep 11 '14 at 22:47
  • @KatherineVillyard - I'm on the fence on that one. Having a local Administrator account available as a "break glass in case of emergency" mechanism seems not totally unreasonable to me. A long enough password it seems, functionally, like being disabled to me. – Evan Anderson Sep 11 '14 at 22:49
  • Yeah at $previous_workplace, we were split between "Give it a really good password and then hide the password somewhere" and "Give it a really good password and then disable it." In an AD environment, I generally go with the latter, but I can see the point of the former, especially in standalone environments. – Katherine Villyard Sep 11 '14 at 22:50
  • 1
    @KatherineVillyard - The loss of an AD trust relationship is always a possibility, and having a local Administrator account available can make a huge difference in resolution time. (Ideally, I wish that server-managed password vaulting products like CyberArk EPV were cheap enough that everybody could use them-- then management of crazy-long, never-seen-by-human-eyes passwords would be a lot easier.) – Evan Anderson Sep 11 '14 at 22:53
  • Yeah. The local admin account doesn't necessarily have to be the RID 500 Administrator password, either, although managing Windows machines in bulk can make creating different local administrators less convenient. Anyway, I do see the merits, I just tend towards the disable side. :) – Katherine Villyard Sep 11 '14 at 23:01
3

Don't even think about giving the root user a blank password. If you do this, it's trivial to leverage a non-root compromise into a root compromise.

Consider one of many possible scenarios:

An attacker uses an unpatched vulnerability to compromise the web server or the application the web server is serving. He gets a shell running as the web server's user. With a blank root password, he merely needs to execute su and he now has root.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • That is not true, "su" will not allow you to log in as a user without a password. Can you please give a different example of a possible scenario? – Jakob Sep 13 '14 at 16:37
  • 1
    @Jakob On what system? It certainly allows this on every Linux system I've ever seen. – Michael Hampton Sep 13 '14 at 16:40
  • 1
    Actually, @Jakob, on a system with a "blank" password for root, su will work without even prompting for a password. I just verified it. If the root account is "disabled", then it probably doesn't matter what you set the password to be, as long as you can absolutely guarantee the account won't be re-enabled... otherwise, you're just taking a risk so you can pretend that you're right. – Hunter Eidson Sep 13 '14 at 16:47
  • I just tested this on Ubuntu 12.04 and Ubuntu 14.04. My steps: I run (as myself) "sudo passwd -d root", enter my own password, then I run "su", it asks for the root password, I enter nothing and just press return, and then it says: "su: Authentication failure". – Jakob Sep 13 '14 at 17:19
  • @Jakob That appears to be a Debian-specific setting (inherited by Ubuntu) in the PAM common-auth configuration, which permits the blank password only if on a terminal listed in `/etc/securetty`. This `nullok_secure` option does not exist in upstream PAM and therefore in most Linux distributions. – Michael Hampton Sep 13 '14 at 17:24
  • True, it appears the behavior depends on whether I do this on the physical console (it doesn't ask for password and lets me in), or via SSH (it asks for password but then refuses it when it's empty). – Jakob Sep 13 '14 at 17:42
0

I think current answers do not answer the question in full. Original question says "I see several advantages of having no password." and yet all answers talk about blank passwords.

So the question is: is blank the same as none?

Currently, hosting providers offer the possibility of setting up servers with uploaded public SSH Keys. This is quite convenient as it means one less thing to do when setting up new servers.

Since DigitalOcean has been mentioned it is relevant to point out that in this situation

When using SSH-keys, no root password is set.

This is certainly not the same as saying that root user has a blank password (I'm thinking empty is not the same as undefined sort of thing)

So the question now is whether root accounts can be set without a password at all. In an ideal world, I guess this would be even more secure than having any imaginable password, as there is none to match. But I wouldn't say I'm 100% sure about this. Could someone confirm this?

EDIT: It turns out that my guess will remain in an ideal world for a while. I created a support ticket in DigitalOcean and the answer included the following:

That is correct that no root password is set when using ssh-keys. It is recommended to use "passwd" once you have logged in to set one.

So that's that. It's safe to use SSH private keys during initial setup but passwd has to be performed still.

cortopy
  • 363
  • 4
  • 10
  • It is possible to have no password, which is not the same as a blank password. In the context of DigitalOcean, for example, droplets created with an SSH key will have no password. While you will still receive a password prompt, root has no password, it cannot be used by password authentication at this point. Any password you type, blank or otherwise, fails to authenticate. Setting a password via passwd may still be important for people who do not setup a privileged account with the ability to sudo. – Jarland Donnell Jun 12 '15 at 05:13
  • That's exactly what I had assumed in the first instance, but DigitalOcean's response confused me a bit. It sounded to me like root should have a password. – cortopy Jun 12 '15 at 15:54