Change the Administrator account name?

Boxers_2Religious debates are rarely clean or pretty.

The same is true in all spheres, whether debating Christianity against Islam, Linux against Windows, or Cagney vs Lacey.

In security, there are a few divisive issues that are always going to crop up.

Is your datacentre network trustworthy enough to pump secret data around it at any speed?

Are virtual machines on the same host PC “separated” for segregation of duties purposes?

Is SHA-1 completely broken yet?

There’s nothing more infuriating than arguing your position on one side of such a debate, only to see those infuriating people on the other side sit smugly in their assertion that what you state has no bearing on their view, which is still more correct than yours, nyaah nyaah.

I hope it doesn’t get that way with a debate between two people I like to claim as friends – Jesper Johansson and Roger Grimes – who are currently waging their war of words in TechNet, in what I hope will become a regular series.

The current article is on the big debate between those who think it’s a great security idea to rename the Administrator account to something else, and those who perceive little or no benefit in the practice – so little that it’s not worth doing.

For those of you too lazy to follow the link and read the article, Jesper (and his Microsoft insider, Steve Riley) are on the “don’t bother renaming Administrator” side, while Roger (with his own insider, Aaron Margosis) are on the side that renaming the Administrator account is a security win.

I really can’t dispute the mathematics, which says that if you have a 10-character password, you have a 1-in-umpteen-thousand chance of someone guessing and logging in as Administrator; if you have a 10-character password and a renamed Administrator account, however, the chances rise to 1-in-umpty-thousand. A couple of orders of magnitude of benefit, yes?

Sure – but there’s a couple of points I’d make here:

  1. There’s not much difference between zero and zero, and the two numbers representing the probability of a random guess succeeding are as close to zero as makes no realistic difference. At that level of difference between near-zeroes, you’re as likely to find your password is weakened by poor choice of random number generator as you are to find that renaming the account protected you while the password did not. In essence, you’re saying “we’re already protected against the sort of guy with enough luck to win the lottery a million times in a row, but just in case, we want to protect ourselves against the guy with luck enough that he could win a million and one times.”
  2. You could get the same increase in probabilistic protection by lengthening the password. Even if all you did was to add into the password the name that you were going to give the Administrator account, you’ve provided yourself with just as much mathematical protection against random guessing as you would have by changing the Administrator account name.

Okay, so maybe you’re not really getting orders of magnitude better protection – but surely it can’t hurt security, and it feels enough like security that several people in the field recommend it.

To me, that’s old-style security thinking, where the goal was to disable, disable, disable – when the web sites and applications were so full of holes that any time you saw something that looked like a hole, you immediately knew that the right thing was to plug it up.

Modern information security, though, should be more about enabling – enabling business and customers alike, to conduct business without unnecessary inconvenience. Without wishing to sound like Yoda, inconvenience leads to confusion; confusion leads to mistakes, which lead inexorably to insecurity.

If you rename the administrator account, you’re asking for its name to be a part of the secret that secures its access. You won’t get any cooperation in that, however, as the operating system and all of your applications are designed around the principle that the username is not a secret. You’re also asking your system administrators – the people who are going to be using the Administrator account – to remember that it’s been renamed, to remember what it’s been renamed to, and to remember to not let anyone else know that.

So, yeah, I’m on the side that says “renaming the administrator account doesn’t add any significant security benefit”.

The one benefit I do see is that the “random noise” of random attacks on any account named Administrator can be separated from the log entries indicating that someone is attacking your Administrator account. I think this is a bit of a false saving, though – you really shouldn’t be allowing any external access to the Administrator account. If your staff wants to access the Administrator account remotely, they should VPN in under their own account, and then use RDP, or some other protocol to connect to the machine they wish to administer.

I’m hoping to entice some of the Security MVPs to contribute to this debate – maybe even Roger and Jesper. There are two sides, here, and I doubt that I’ll actually end up converting anyone to my side who wasn’t already there to begin with.

10 thoughts on “Change the Administrator account name?”

  1. I know it’s been said that if your password is strong enough that you might as well be able to post your user name on a billboard on the highway, but isn’t renaming the Administrator account ensures the belt and suspenders needed for an entity?

    You argue that renaming costs, that it adds complexity, the argument is that there are some software programs that demand Administrator (including SBS 2003 that must run some installs from the RID 500 account).

    Isn’t this more of a case of the balance between supportability and security?

    If there is no additional measurable security benefits, then why did the install routine for SBS 2008 demand that we do rename it?  Microsoft has deemed it to be a security benefit in small firms versus the supportability costs involved.

    (I’m not a security MVP but I am a beta tester for SBS 2008 where the account is renamed during the install)

    Alun replies: It’s not a belt-and-braces approach, it’s a “belt-and-another-belt-but-this-one-lacks-a-buckle” approach. Changing the administrator account is equivalent to adding a few characters to the password – but leaving those characters known to anyone who can log on to the system.

    You are right that it is completely a balance between supportability and security – and since there’s another option that adds the same security improvement without reducing supportability, that’s the option you should generally choose.

    As you can tell, there are people who believe that renaming the administrator account is somehow better than simply extending the password, and presumably that, or one of the few compliance requirements that ask for a renamed administrator account, is why SBS renames the account by default. Or maybe there’s some other reason beyond this one?

  2. Where’s the statistical evidence for or against to show whether renaming Administrator is effective?

    It should be possible to measure proportion of break-ins in each type of environment, and also to measure problems of administration.

    Until we bring evidence into security, we’ll continue to have such “religious” debates.

    Alun replies: You ask for statistical proof, and I was kind of hoping that Roger would step in and give you some magic numbers to play with. But the truth is that if you look for mathematical proof on this, the numbers are so close to zero that any difference you might see between them in real life is more attributable to experimental error than it is to the thing you’re trying to measure.

    How would you set up the experiment? A few thousand servers, half configured with a renamed Administrator account, the other half with a regular-named Administrator, and each with ten-character random passwords. Now sit back and wait a few million years for the first one to get hacked.

    You just can’t do the experiment that would prove one or the other.

  3. You have to think of what exactly changing the Administrator username brings to the table? IMO, it’s not worth the trouble and the possible compatibility issues that come with “changing the default”.

    The interesting argument is the one with the dummy Administrator account that could be used as an early warning “system”, haven’t ever thought of that one. Besides the fact that you shouldn’t let direct remote connections with the Administrator account, you need to think that bruteforce attempts are generally not geared towards a specific host. Script kiddies just run scans and try any host that is visible in that given range. If they successfully compromise it that’s fine, if not they’ll just move to another host. What exactly is a log full of failed login attempts telling me? That bad people are out there and they are trying to own my machine? We know that already.

  4. Yeah, I can definitely see a couple of good reasons why you might change the name of the account:
    1. Compliance with some standard that requires it. [Quite frankly, this is the one that is simultaneously the strongest and the most irritating reason – you should attempt to achieve compliance through security, because you can’t necessarily achieve security through blind compliance.]
    2. If you need to audit the scattershot logons from people looking for any machine with an Administrator account set to ‘p@ssw0rd”, separately from those accesses by people who are using knowledge of your systems. I’m not sure this gives you much to work with, though.
    3. To get people to stop being so hung up on “the Administrator” – administrative users should each have _an_ administrator account, noone should use “the Administrator” account for anything except brain-dead software. But then, if you’ve got such brain-dead software, it’s probably brain-dead enough to need the Administrator account to be called Administrator.

  5. In fact, appending the “renamed name of Administrator account” to the end of password offers more complexity as username is usually case-insensitive, if the password WERE stored in plain text.

    But as we know, passwords usually store in hash, and complexity if hash is only as good as the length of hash. So when you putting more length to the password , in theory there will be a point that appending anything to it won’t increase complexity anymore. Although I highly doubt that anyone will use password of that length!

    And I agree with you, compare 2 near-zero number that is already small enough is meaningless…

  6. One of the main reasons we change the Administrator account is the time it allows you to respond.

    A lock is not there to protect, it is just delay the breaking in.. In the same context, you win extra time to respond to and a change in the Administrator account just lets you to establish a pattern.

    We use it mainly to run through the logs and learn some discerning patterns, it provides you with knowledge and to identify such patterns. Helps in reading the mind of the attacker

  7. You can definetely do that, it is the probability of someone being able to guess the password.

    If you assume somebody can guess your password randomly, you increase the time line to break-in by a factor. This is similar to two factor authentication, not that efficient but definetely you need to know the name as well as the password.

    You may say, to what extent it improves the security posture, but considering the cost of the control, it is definetely worthwhile.

  8. There are a number of other arguments here.
    1. This isn’t two-factor – this is one-factor. You have essentially moved part of the password into the user-name field.
    2. Are you going to change the username every 90 days in line with your password policy?
    3. What are you going to do when the username gets exposed? Applications have a hard enough time being updated every 90 days with a new password, and now you’re asking that the username, not designed to be changed through the life of an account, should be changed in a hurry after an exposure?
    4. You can achieve the same “increase the time line to break-in by a factor” with a longer password.
    5. Most applications are designed to keep the password secret, but to display the username – are you changing your applications to keep the username secret, so as to gain the same benefit as merely increasing the length of the password?
    Have you considered these “costs of the control” to determine whether changing the administrator account name is truly worthwhile?

  9. The most interesting point to the entire debate to me, is at the end you suggest to secure the Administrator account from remote access by a two factor authentication mechanism (ie. a VPN where other credendtials are used first), yet you also point out the reality that today’s technology access should be without unecessary inconvenience for ‘everyone else’.  What is then recommended for an Administrator account on a published RDP Application Server for users?

    Statistically, I don’t believe the ‘brute force’ scripts are running their entire password database and incremental logic to their username attempts.  Therefore a renamed Administrator account is more than statistically incremental, as you suggest in adding more characters to the password.

    So how about this.  Rather than a VPN; which adds overhead, cost, and unecessary complexity, why not implement a self-signed SSL certificate to RDP; with a renamed Administrator account.  This surely is just as, if not more effective than a VPN.  It’s that same ‘extra’ layer of authentication; yet simple, and less expensive.  The brute force script will not be able to handle the SSL warning; and their script will never be able to challenge credentials.

    Although I still think that the ‘brute force’ hacking scripts are not planning for a renamed Administrator account as invariably the usernames I see in my honeypot logs are a much smaller list of possibilities, that you suggest are statistical.

    OR, if you have access to a Web-Gateway for RDP, as is inclueded in Server 2008, and available on SBS 2003, use that as your only open access to RDP; and it’s ‘tougher’ for the hackers, that will move on to an open RDP before trying to attack your rdp-gateway.

    Now if you are a federal governemnt, with super-sensitive data; or other higher-profile victim, then clearly you only permit remote access to unclassified systems; and these rules will be beneficial to you as well; since your classified network is not remotely accessible at all.

Leave a Reply

Your email address will not be published. Required fields are marked *