Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our security manager insists that we should use anonymized usernames.

E.g. for a user named John Doe his username would be 'g74h19' instead of something like 'jdoe'.

We already have a policy that locks out an account after three invalid logon attempts. So except maybe for making a DOS attack harder I can't see how this would help security - even worse you would no longer be able to see who is who in the logs.

Are there any security recommendations that support anonymized usernames? (link)

Is anybody here using them?

share|improve this question
up vote 16 down vote accepted

I'm going to approach this from a Windows domain perspective. If I'm an attacker, I don't care what the usernames are. I simply want them. So I'm going to look for a system that doesn't have RestrictAnonymous, or a Windows 2000 system, and I'm going to scan for all the usernames in the domain. Or I'll gain a single valid user account on the domain and then issue said scans. Now I have ALL user accounts to try against.

Oh and I can scan for groups, too. So I'll look for the really nice ones like Domain Admins or Enterprise Admins or groups which look particularly interesting. And I'll see who are the members of the group in question and look to go after them.

So while anonymizing usernames may seem helpful, I don't think they do much to actually increase security. And they make it harder on end users, support staff, and administrators when troubleshooting a particular set of users' problems.

share|improve this answer
+1 for explaining the hack vector that would negate the use of anon uids and for the link back to the User where the good security starts with like the complex password issue - users will right them down Bruce Schneier – littlegeek May 27 '09 at 13:45
+1 for making a good point regarding the enumeration attack vector. Of course this assumes the attacker is on the inside or has access to a service to list user. Anonymizing helps against accidental disclosure. The classic is going through the website to find peoples emails. If John's email is and his username is jdoe the attacker just gained more knowledge about the operation than you wanted him to. – Pierre-Luc Simard May 27 '09 at 15:18
Well-said. The one exception I make to this rule is renaming Administrator, for the same reason that I move SSH to a non-standard port. It's a very minor layer of obscurity that will do nothing to stop a determined attacker, but makes it more difficult for a mindless scripter to hammer away at my system. – sh-beta May 27 '09 at 21:37
True, renaming administrator makes sense. Because that way you can use IDS/IPS to alert on administrator a whole lot faster than you would pulling event logs. – K. Brian Kelley May 27 '09 at 22:46
One thing to add to this excellent answer is a discussion of Identity vs. Authentication (, a link recommended by Bruce Schneier Identity is inherently public, and it seems that trying to obscure public identity bears a higher cost than any benefit. – pcapademic May 28 '09 at 2:02

anonymised user names are another example of security by obscurity. By anonymising the username it makes it difficult for a would be attacker to guess it, from say an email address. Exchange for example often uses the users username as part of the email address.

As you stated you have a lockout policy in effect then you already have some method of security in place and so anonymising will make it more likely to hit the limit with a brute force attack. One thing you should consider is, what if the user inadvertently gives away their password? In a case where there usernames are not anonymised, the attacker has the password and is likely to be able to guess the username from their email in under 3 attempts. If the username is anonymised this is much less likely.

So there is some benefit from having them, but it depends whether this limited benefit outweighs the convenience of easy user names. How much security is enough for your organisation?

share|improve this answer
How would somebody get the password but not the username? If a user gives away his password wouldn't he give up his username just as easily? – laktak May 27 '09 at 20:55
Not neccaserily, but I agree its not a huge amount of extra protection, but it is some – Sam May 27 '09 at 22:02

Security and Usability must constantly be balanced against each other. This would improve security against a brute force or username guessing attack but makes life far more difficult for the users. The user must now remember 2 pieces of (to them) random information to be able to log in and perform their job functions. This is a risk to the business as the users are more likely to both write down their usernames (and if they're writing that down it's a very short leap to writing down their password with it) or forget their username causing a loss of productivity.

I do not believe that it is worth randomizing usernames. These are shown in clear text on the screen so are very vulnerable to shoulder surfing anyway. They will also cause unnecessary grief for the users. Most importantly they encourage the users to practice bad security habits.

share|improve this answer

They also can be of use in masking data between employees. People writing reports for payroll etc don't see exactly who is making what. Other situations where if management is choosing layoffs and data on employee performance is presented with anonymous usernames can't be accused of picking and choosing. Random things like that.

It makes a bigger difference for large organizations where taking parts of first names and last names will cause a lot of overlap.

Edit: Obscuring usernames also makes it a bit harder to figure out which user accounts you want to bother trying to hack. With a standard scheme everyone will know the CEO/CIO/CFO/Director usernames. Its a lot harder to figure out which employee number they are.

share|improve this answer

Working for a .EDU this has come up, but not for security reasons. Like many, we base our usernames (still stuck on 8-character limits due to the presence of older Solaris servers in our user's environment) on the real name at time of registration. Since we have between 19,000 and 23,000 active students at any given time this is done by an algorithm, so guessing what a given user's username is from their real name is not that hard. Depending on how you read the regulations (FERPA), this could count as a 'directory service' of the type that they have a right to opt out of.

This is the problem. If a user with a pretty unique name registers, Farheed Zakaria for example, the account generation process will assign them a username. That would be 'zakarif' in this case. Easy to guess. If you consider this a directory and they opt out, then we'd have to change the username. Changing usernames is a tricky process, and isn't automated. When students get married and change their last names, we do not change their username. We have staff that married in the early 90's that still have usernames that include their old last names.

So, goes the thinking, what if at account-creation we assign users with less easy to derive names? At the university I graduated from, the above name would be "zaka0008"; the first four letters of the last name and a numeric for uniqueness. That isn't easy to derive from the given name, yet still contains some identifiers to help users remember it. That would allow us to avoid doing account renames.

We haven't done this yet, since we haven't had a firm ruling of the applicability of FERPA to this situation. But this is a real world example of going to less obvious usernames.

share|improve this answer
the school I went to first just used to use the pattern of <first initial><last initial><studentid#>. Now they use <studentid#>. It's simple in that particular context. Not sure how good it is overall. – warren Sep 25 '09 at 11:45

Technically, the username is half of a cipher so using an easily guessable username is the same thing as using an easily guessable passphrase.

share|improve this answer
Except that usernames are enumerable with minimal privileges, are regularly passed over a network in plaintext, are displayed openly on a locked console, and generally match up to publicly known email addresses. "half of a cipher" being easily guessable is completely meaningless. Crypting algorithms take the whole thing into consideration at once, they don't go letter by letter. MD5 crypt example: abc = 900150983cd24fb0d6963f7d28e17f72, abcd = e2fc714c4727ee9395f324cd2e7f331f. So really, they aren't even CLOSE to being the same thing. – sh-beta May 27 '09 at 21:45
Usernames are no longer enumerable by default since Win2003 server. It's also in almost every security template to turn off anonymous account enumeration. Just because you can give away half of the code doesn't mean you should. Also, most well-run orgs implement a login obfuscator with regards to email. That is, email addresses are first.last@company while user ids are different. If you think that the username is meaningless, you're not seeing the whole picture. – diq May 27 '09 at 23:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.