I have found a tonne of information on password policy all over the Internet and several best practices checklists. However from a username point of view I could not find much. I thought it would be really helpful to have something like this to prevent harvesters from being able to build dictionaries or username enumeration as well as other preventive steps where the username can be used by an attacker.
Could someone link me to some relevant documents and information?
My opinion: If your security is well-designed, you don't need a policy about usernames. You don't need to try to prevent attackers from guessing usernames if you've done the rest of your security right, because it won't do the bad guys any good to be able to guess usernames if they can't (e.g.,) guess the corresponding password.
You might want to put some limits on what usernames your users can choose, to make sure that a random user does not create a username that implies some official position at your company. For instance, you might want to prevent ordinary users from selecting a username like root or admin or abuse or webmaster or spam or help, just to prevent other users from being confused by them.
I have included a couple sources, but lets discuss the issues.
Usernames should not be a protection for authentication. Authentication is separate from identification. Identification is a piece of data that describes a individual or group. Most of the time a username is a sequence of characters that uniquely identifies a individual. Typically a individual is authenticated with a password. I may claim I am Margret Thatcher, but if I can not type in Margret Thatcher's password than I can not authenticate as Margret Thatcher.
That aside there may be some secureity issues with usernames.
University of South Australia
1.4 Username Should be Unique and Unchanged for a Person Each person should normally have a unique username which they can keep for their entire life at the University. Staff usernames are distinguishable from student usernames. As Staff move between different cost centres, their username should not change but the associated Permissions should reflect appropriate access for their new role.
1.5 Staff who are also Students will have Two Usernames Staff usernames are distinct from student usernames. There is a need to be able to provide different permissions based on a person’s role as staff or student. Staff who are also students will be provided with a staff username/password pair and a student username/password pair. This allows staff to take on the role of a student when they are not working in their normal staff position.
YouTube Username Policy
Don't namesquat - YouTube usernames are in high demand. As a general rule, users are expected to be an active member within the YouTube community.
http://www.google.com/support/youtube/bin/answer.py?answer=151655
There is some good discussion on usernames policy and practices here: Should usernames be kept secret?
I agree with @D-w and @this-josh in that usernames are for identification not authentication, therefore prioritizing user convenience seems sensible. A user is far more likely to remember a username that is their email address or mobile number than a random number or letter combination. They also satisfy the property of being unique, although this can also be addressed via a private identifier (e.g. GUID) in your database and a public identifier which is their username.
Some risks to bear in mind though depending on your threat model on simple usernames such as email address or phone number that are effectively public information:
Denial of service - if the usernames can be easily enumerated or guessed and you have an account lockout policy, this can result in a denial of service attack
Information leakage - email address or phone number could be considered personally identifiable information, especially in conjunction with other information. Your users or regulators may not accept this information not being protected
Password attacks - if the username is easily guessable then it is one less piece of information an attacker requires. Arguably if you are using both username and password length and complexity in calculating your overall authentication entropy / strength then having a simple username requires you to have a lot longer password to achieve the same value
Password re-use - users may re-use their email address as username and a common password across many services. If one of these gets compromised then the attacker can compromise the others faster than if the system had a different username.
If these risks are too high to accept, then arguably the best username policy is the same as your password policy.
