What is the point in having arbitrary username requirements?

Question

I've looked around on Security.SE, but couldn't find much related to the following problem:

I recently signed up for Chase Quick Pay as my method of being paid by a part-time job. I've heard of stupid password requirements, but never stupid username requirements.

When I enrolled, I didn't really take into account how weird it was (I really should have, because I have forgotten my username twice in the past 3 months due to the policy):

Now, the Stack Exchange engine has so graciously pointed me in the direction of a question with a good answer by @Polynomial that says it all in the first sentence:

The authentication strength should come from the password, not the username.

So, quite simply put: what is the point of having requirements like this on a username?

Edit: For clarification - are there any real security benefits to having these kinds of username requirements?

Bonus: I just looked at my own bank's username/password security policies, and found the following (not that abnormal):

Note: I don't really understand the point of disallowing 'X' as the first letter... anyone who can answer that gets a +10!

Answer 1

There are two main arguments for enforcing requirements/restrictions on username choices. The first is that making usernames more difficult for attackers to predict helps resist online guessing attacks. While usernames aren't necessarily considered to be as secret as passwords they are one of at least two pieces of information that must be stolen to impersonate a user. We shouldn't dismiss the advantage of this information remaining unknown to attackers.

The 2007 paper Do Strong Web Passwords Accomplish Anything? (PDF) evaluates the threat of online password guessing and considers the what our options are to combat it. A site can enforce a stricter password policy which may hurt usability if users struggle to comply and experience frustration with the process. Or the site can enforce some username restrictions and keep the password policy the same. Their theory being that if an attacker has to try a lot of possible combinations it doesn't matter as much whether that's due to easy usernames and complicated passwords, or semi-complicated usernames and semi-complicated passwords.

This ignores a third option of the site adding a second authentication factor to supplement the security of a password while leaving usernames alone. It also requires the site to work harder to avoid disclosing valid usernames that attackers can then pair up with possible passwords.

The second argument is that by enforcing somewhat unique username requirements a site can hope to deter users from choosing the same credentials they've used on other sites. This is a very real threat and it's a difficult one for a site to do anything about besides enforcing unusual usernames requirements (or assigning IDs themselves). However, one awesome study from 2010 monitored actual username and password reuse by people between their banks and other sites. The study found that people did indeed reuse their bank password on other sites 73% of the time, but also found that even if a bank enforced unique username conventions people would then reuse that username on at least one other site 42% of the time.

So enforcing unique username requirements lowered the chances of credential sharing, but certainly didn't eliminate that possibility. But that lower risk may still be seen by some sites as worth the inconvenience to users.

Another possible reason, that's less of an argument and more of a requirement, is legacy system compatibility. Whatever potentially old software is doing back end processing behind the snazzy web front end may have been coded to only accept usernames formatted a certain way. Without ripping out and replacing that software the site may be stuck passing on the restriction to customers. The 'User IDs cannot begin with an X' line leads me to believe this may be a factor in your case.

Answer 2

These user names requirement can cause user names to be less predictable. I don't think that this provides a substantial security improvement, but I can think of a couple of scenarios where they help a little. I doubt that it offsets the loss of usability, but I lack concrete evidence to conclude. As usual, security at the expense of usability, comes at the expense of security.: if users are more likely to forget their usernames, this means that either they'll have to store their username in an insecure location (defeating the purpose) or there has to be a way for them to recover their username (which may not be strongly authenticated).

Less-predictable user names improve privacy. If I try to create a johnsmith account and it fails because that username is already in use, this tells me that John Smith is banking with that firm. If John Smith's account is johnsmith1, I need to enumerate more usernames. However, with user-chosen usernames, the suffix 1 is a very good bet. Most websites rely on email addresses as unique tokens — if I want to create an account as john.smith@emailprovider.example.com, I'll need prove that I can read email sent to this address. Banks are usually reluctant to depend on external security, so they tend not to want to depend on email providers.

A significant number of attacks on banking are performed in a home setting — a spouse, a child, a visitor, etc. A less-predictable username can improve confidentiality against a casual attacker who has access to the victim's computer but is more likely to perform opportunistic attacks than to seriously research their attack. Again, with a user-chosen username, the complexity requirement isn't a significant improvement: many users will leave their username pre-filled in their browser, and if they don't choose johnsmith1, the variation is likely to be known to the attacker since they know each other well.

Less-predictable usernames also improve the defense against non-targeted attacks that work by trying out a lot of username+password combinations until a weak one is found. Again, having to try johnsmith1 in addition to johnsmith doesn't provide a significant improvement.

As for user IDs not beginning with X… it's a bank. Deep inside the bowels somewhere is a COBOL program running on an emulated IBM big iron running on a slightly more recent emulated IBM big iron running on an emulated VAX running in a virtual machine on an x86 processor. Before you were born, someone decided it would be a good idea to indicate deleted records by putting an X in the 17th column. The COBOL programmer who was brought out of requirement to fix the Y2K bug offered to fix that as well, but was told that this was outside the job spec and he was not to touch something that works (this could have worked out differently if the bank director's name had been Xavier instead of George).

Answer 3

1. To make user IDs less predictable.
2. To conform to other systems.

The reasons for less predictable user IDs might be:

1. An application limits a number of password guesses (a typical thing for internet banking) per a user ID. Then an attacker can mount an attack "try password 123456 for all known user IDs". If the attacker does not know the large amount of user IDs, this attack does not make much sense.

2. An application might have some design security flaws which we do not know. For example, an application might use a user ID to derive a session token.

'X' as the first letter might be disallowed to prevent interpreting a user ID by some (legacy) system as a hexadecimal number.

Answer 4

I agree that forcing a weird username will make breaking the account sligthly harder (as it works as a kind of second password) as opposed to having the same username as in the XYZ account whose password they are reusing. (But imposing some requirements also makes easier that the user forgets his own username!)

The main reason I see for setting a minimum length on username is to ensure they do not use common names like "Joe", but forcing something more unique (maybe they add last name, a date…)

If they have to be told by phone, it makes sense to restrict special characters. Requiring a letter would also help make it look like a normal username. I don't think it makes sense to require a number in the username.

The Banking rules are in general much saner. I suspect that usernames beginning with X are used internally (eg. a test user, some reserved account…).

Answer 5

I agree that forcing a weird username will make breaking the account sligthly harder (as it works as a kind of second password) as opposed to having the same username as in the XYZ account whose password they are reusing. (But imposing some requirements also makes easier that the user forgets his own username!

Answer 6

Different restrictions likely have different sources.

Restricting the set of characters in a username to ascii alphanumerics means that the username can be easilly stored in a wide variety of data formats and can't be used as a vector for most types of injection attack (SQL injection, HTML injection, shell injection etc), since the "markup-significant" characters are outside the range of ascii-alphanumerics. It also means that your staff can easilly work with the username.

Forbidding entirely numeric usernames is likely an attempt to avoid confusion between usernames and numeric user IDs.

Another source of restrictions can be a desire to avoid overlap between the usernames of different sets of users (internal human users, external web users, system users etc). This is the reason why Debian require accounts created on salsa.debian.org to have a "-guest" suffix" and may well also be the reason for your "must contain at least one number" and "can't start with X" reasons.