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?

  • 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, 2014 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, 2014 at 8:12
  • 1
    It would cause you to flunk PCI. jscape.com/blog/bid/84215/… 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. Sep 12, 2014 at 20:47
  • Likely relevant to your question: security.stackexchange.com/questions/66894/…
    – kasperd
    Sep 13, 2014 at 8: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, 2014 at 10:57

4 Answers 4


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.

  • 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, 2014 at 21:07
  • the users need to be in /etc/sudoers or in wheel group inorder to do that
    – resultsway
    Sep 11, 2014 at 21:27
  • I'll just say that it's not traditional best practice and leave it at that. Sep 11, 2014 at 21:41
  • 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, 2014 at 23:22
  • 1
    No. In order to map a drive with a blank administrator password, I just need to map the drive. Sep 12, 2014 at 19:40

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.

  • Yeah, I would also recommend disabling administrator. Sep 11, 2014 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. Sep 11, 2014 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. Sep 11, 2014 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.) Sep 11, 2014 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. :) Sep 11, 2014 at 23:01

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.

  • 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, 2014 at 16:37
  • 1
    @Jakob On what system? It certainly allows this on every Linux system I've ever seen. Sep 13, 2014 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. Sep 13, 2014 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, 2014 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. Sep 13, 2014 at 17:24

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.

  • 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. Jun 12, 2015 at 5: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, 2015 at 15:54

You must log in to answer this question.

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