Security

A user name is not a password

Chad Perrin cautions that user names are not passwords, and you should not rely on their secrecy for security.

Usernames are not passwords, and you should not rely on their secrecy for security.


As pointed out in the article, Avoid ambiguity when referring to account names:

Employing randomized, complex login names, unique to each login context -- a different randomized username for one's online banking site than for one's email -- is a technique used by some to increase the difficulty of cracking security on the account. The value of doing so is typically very small, and the question of whether that value is greater than the cost of the added effort involved is difficult to answer in the general case, but for a person whose login information management procedures easily handle this behavior there is really no downside to doing so in cases where the login name does not map directly to a profile name. As such, if that describes you, and you feel that it may enhance the security of your account, go ahead and do so.

The likelihood of the practice of using one's login name as a secondary password actually making the difference between a secure account and an account that has been compromised is very, very slim, however. Such user names are often stored on the system where one is logging in only in plain text, and they are also often mapped directly to a profile name in cases where an account has a public profile.

Most systems do not even use the login name directly. It is typically the case that entering a user name at a login prompt leads to the system, behind the scenes, checking that user name against a table of user names and user identity integers to find which UID to use. Once that UID is selected, the password (or, rather, a cryptographic hash of the password) is generally checked against the stored copy, then correlated with the UID, to determine whether login is successful.

After that point, anything the user does while logged in to that account is managed by way of the UID, and the UID is generally only resolved to the user name used to log in when some user-level interaction requires the actual user name instead of the UID. For instance, when a shell prompt displays the name of the logged in user so that the context of the user's actions is made clear, the UID will be resolved to the user name to present that user name, but when the account is checked for permissions to perform a given task, it is the UID that is used.

In many cases, such as in the case of a login user name displayed as part of the shell prompt so that the user will always have a clear reminder of his or her current user account login status when entering commands, a tendency to use complex, randomized character strings as user names can undermine the value of the user name itself. People's eyes tend to glaze over when presented with incomprehensible strings of special characters, so that whether one is using one account or another might be completely overlooked, particularly if the two account user names are of similar lengths.

The specifics of how a user name is employed on a given system should be considered before one chooses to use a complex, randomized user name as one's login name. Sometimes, more harm than good can come of it, especially in cases where any potential security advantage is negligible. As anyone who has accidentally entered a command into the wrong terminal emulator knows -- into one where there is an active SSH session logged in to a remote system, perhaps, or where the current working directory is different but the directory path is not shown -- having clear, visible reminders of context and circumstances that are obvious at a glance can be a lifesaver. For example, when I worked for the Wikimedia Foundation, I once accidentally shut down Wikipedia, Wiktionary, and Wikia (among other things) for a while by accident with one misplaced command.

The reasons any such security advantage may be negligible are many and varied, and may actually change from one system to another. A few examples, however, include the following:

  • Many account security breaches occur when a malicious security cracker somehow acquires access to the password file for a given account. Assuming that file only contains cryptographic hashes for passwords rather than plain text passwords, chances are good that the security cracker will not have at his or her disposal an easy means of directly injecting the cryptographic hash into the login process. This means that the malicious security cracker will most likely perform an offline brute force cracking attack to try to crack passwords, which means that the weakest passwords will succumb first. The relevant piece of information, for purposes of determining the value of a complex, randomized user name is that the login user name is probably identified in plain text in the password file, or in a separate file that is at least as easily accessible to the security cracker as the password file.
  • Login names are usually more restricted in terms of the characters that can be used than a password, because of the fact the system has to be able to do more with a user name than with a password. When resolving UIDs with user names to display those user names, send them to other applications, and so on, any special characters in the user name that might cause security or crashing issues for the system by creating an injection attack vulnerability or otherwise forcing unintended behavior need to be sanitized somehow.Because the primary purpose of a login name is not to provide a secret login credential component, it is typical that the easiest and most reliable means of guarding against such eventualities is to strictly limit the characters that can be used in a login name. As such, the maximum complexity of such a user name is generally much lower than that of a password, so it is best to focus more on the complexity of the password to prevent account security compromises rather than expecting a complex login name to save one's bacon.
  • On systems where a login name and a profile name are identical, one's login name may well be public knowledge anyway. Even if it isn't easily accessible to everyone, injudicious treatment of the "secret" of one's profile name by someone who can view the profile may create a crack in the secrecy of one's user name. If someone whose account has access to view one's profile is cracked, that account can be used to find out your profile name anyway, allowing for compromise of one account's security to be leveraged to compromise another account's security.
  • Because of the fact that user names can be useful much more widely than passwords, being fed to user friendly application interfaces, printed on the screen for the user's convenience, and otherwise passed around between various pieces of software or parts of the system, the opportunities for accidental discloser of the user name to third parties is often at least arithmetically greater than that of a password, if not exponentially, or even geometrically, greater.In fact, a system's administrator often has need of easy reference to various user accounts on the system, as in the case of servicing password reset requests, and thus the admin may also have access to one's login name. Since part of the reason for a securely implemented authentication system is to ensure that even an administrator cannot access an end user's account -- or, if the admin can access it, at least should not be able to do so without it being obvious it was the admin who performed some task under the auspices of the account rather than the end user's direct action -- using one's login name effectively as part of a two-part password is often less than entirely effective.

In short, as long as it does not impose an undue burden on you in terms of inconvenience, there is no real reason to avoid using complex, randomized strings of characters as login names to potentially improve account security, there is little reason to believe that it will actually make the difference between a secure account and a compromised account. Perhaps more to the point, treating the user name as a second password does little more than increase the effective length of the password in most cases, with the exception that the user name half of the longer "password" is more easily discovered than the actual password itself. As a result of this, you should never rely on the secrecy and complexity of your user name as a way to enhance account security, when such reliance is better aimed elsewhere, such as ensuring your password is strong and kept secret.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

12 comments
seanferd
seanferd

Never even thought about usernames that way. My only personal policy is to not use the same username everywhere.

dogknees
dogknees

A non-IT friend put me onto this idea. When you register at a site, use slight variations of you details and keep a record of what details go with what site. A bit tedious but it means when you get unsolicited mail you can usually work out who gave them your details and take appropriate action.

Neon Samurai
Neon Samurai

In cases where email names and username are identical, you just grab a company list of email and you've got half your dictionary ready. In cases where one is posting on the internet, having one's username or real name sprayed across the internet is not preferable. This falls into both the dictionary harvesting issue and personal privacy. Still further, one may not want the same alias across several websites. These have lead me to the practice of insuring that username and email and profile name are all different to separate what is publicly known from strictly private login credentials. With windows, email name on exchange does not match domain account username. With *nix, the publicly used email made different from the profile name through /etc/aliases. On the *nix side, this approach is hosed when any user looks at /etc/passwd "relational table" of usernames and profiles. On the Windows side, usually it's a visit to Documents and Settings and you've got your usernames. Both these assume the minimum of an initial breach or inside job though. My reason for mentioning this in another discussion was partially peer review as I'm still trying to decide if this is "feel good" security or actually providing a justifiable benefit.

mikifinaz1
mikifinaz1

After reading reams of information over the years about passwords, security and user names the one thing that is rarely discussed is to use a couple of tricks to make it easy. Make a string with a sound pattern like phish that auditorially represents some thing like a fish, that has at least eight characters and is not a word or name in any language for your user name. Then add a sequence letter and number with a character like the exclamation mark that isn't used by any OS or system. So now we have phish1a! it is easy to remember from the sound. Now you can create a pattern using a number. One is for net mail, 2 is for your mail client etc. and the a, b, c, represents the turn over. So you change netmail accounts you turn over the a to b for the new account. Now you can do the same thing for the password to extend as well as change it like phich1a! or make up a new "word" and apply the pattern etc. to both the user name and password. So you are worried about forgetting the username, address or password; well give your email address fishingForOne@mymail.com user name of Phish1a! and password phich1a!. Now the password, username, email are all woven together, they are not words to foil dictionary attacks, they are long enough to foil brute force attacks, they are easy to change and remember and the pattern and the sound are the keys to remember everything by. I came up with this working at a computer company that made all the employees change their user names and passwords every three months. People began to use the month date etc. to keep track and left post-it notes all over the place. So the IT guys shot themselves in the foot making all these stupid rules, which lead to the users undermining the security to make their lives easier. All sorts of variations on this pattern and theme can be developed so that you don't have to use your wife's name and your wedding date, to make it easy to use.

Neon Samurai
Neon Samurai

I've heard of the same done for physical mail. There are fields you can muck with in your address such as C/O or the name it's going too. Provided the required address fields are correct, the mail still comes through to you. You also know who is leaking your information third party companies based on who the mail spam is addressed to.

apotheon
apotheon

All else being equal, you might as well use the kind of procedures you have described. It won't *hurt* security (directly), so -- if there's no downside -- why not? Whether there's a downside depends a lot on how you manage the login credentials for all the various login contexts in your life, though. If it becomes more difficult, given your credential management procedures, to do it your way than to just not consider the username itself a critical component of security, then I don't think that the potential benefits of treating login names as secondary passwords are great enough in practice to bother. It's worth keeping in mind that, most likely, the majority of mass password harvests that don't rely on a vulnerability that provides fairly direct access to unencrypted passwords will rely on an offline brute force cracking vulnerability. There isn't much an end user can do about the former case -- you're pretty much screwed there. In the second case, you're talking about the sort of situation where trying to keep your login name secret and tough to guess does you zero good while doing the same with your password could be quite helpful in ensuring you're one of the few people whose passwords won't be cracked. As such, the idea that access to something like /etc/passwd requires some kind of "initial breach or inside job" doesn't indicate that it's a relatively rare event. It is, in fact, likely the second most common vector for successful mass password harvesting attacks.

HavlicekChas
HavlicekChas

Nice idea for making up passwords, but is it useful for everyday use? It's going to be tough to remember more than a handful of passwords. Unless you write them down and what's the good of that? I use Sticky Password www.stickypassword.com and have some passwords that I made up along with most that Sticky Password created. It's a system that works great for me.

jfuller05
jfuller05

about passwords and such. I always tell them substitute letters for numbers, it's easy to remember and safe! People I have dealt with will setup ebay accounts, for example, have their credit card saved on the paypal site and then use a lame password like, "rickyone". The guy I dealt with about this said it's too hard to remember a good password, even though his account could be easily broken into :). I showed him examples like the one in your post, switching letters for numbers, etc., but he wouldn't change his password. The example I always give is: P@55W0rd! This shows the way to use symbols and numbers as letters in an easy to remember way.

Aaron Mason
Aaron Mason

One can introduce an element of randomness into password generation that doesn't result in passwords that are impossible to remember. I keep two lists of words - one list of three-letter words and one list of four-letter words. I pick one from each list and slap a number in the middle, capitalising a random letter. This has the potential to produce passwords simple enough to remember, but with enough entropy to make guessing passwords a very difficult and time-consuming task. This method also allows one to create a password that's meaningful without leaving too little entropy. Say one is going in this years Relay For Life (an Australian fundraiser for cancer research) - you could make your password "rUn4life". If your wife's birthday's coming up, you can create a password that's not only strong enough, but helps you remember something else important - "giFt4her". Of course, no password policy will protect you from people who don't trust their own memories. This will make passwords easier to remember, but it won't eliminate the problem entirely. Your best bet is to then ensure that your system doesn't make that problem its weak link - restrict permissions so that this doesn't happen while still allowing the user to do their work. That's my $0.02.

Neon Samurai
Neon Samurai

True, passwd is going to be the first target on an attackers mind and the first breach could be an arbitrary file download through a PHP flaw, PDF vulnerability or IIS issue. In terms of management, my personal method is Keepass and doing a quick six char random lower/number string is easy to do before generating a password. With users, it becomes similar; manage it in the client app's saved accounts. But this also assumes that users or the applicable client program keeps that data safe somehow. username separate from email name offers more obvious benefits though as does alias separate from real name in publicly viewable postings. A very topical article for me though; cheers for that.

Neon Samurai
Neon Samurai

The first thing a hybrid brute force attack is going to do is substitute letters and numbers along with increment those numbers people like to tag on the end; "oh, I have to change my password - password2, done." Symbols are also substituted. The weakness here is still relying on a dictionary identifiable text string. A better approach may be focusing on passphrases to at least gain the advantage of length (rainbow tables are around eight char so you need nine or more). Another approach is take the first letter from each word in a phrase or similar mnemonics.

apotheon
apotheon

It's true that the value of password-like login names can vary depending on circumstances. One example that springs immediately to mind is that of the unfortunate souls who have to use the online account access for American Express. It's not so much that the utility of a randomized, complex login name would increase in such circumstances. Rather, the password policy there is so abysmally useless that it's probably even less valuable than a password-like login name. In general, though, I tend to be of the opinion that if you want to use a fourteen character string of random characters for a login name to improve security, you might want to consider just adding fourteen random characters to your password instead.

Editor's Picks