id="info"

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.

Editor's Picks