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):

enter image description here

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):

enter image description here

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

enter image description here

  • 32
    I'd bet money that the X is a hack they use to mark deleted user accounts because they forgot to add a column for user state. So they'd change "peter" to "Xpeter" to move it out the way - which implies you're actually choosing your primary key when you choose a username rather than having an ID field and a separate username field. I've seen that more than once before (though I have no experience of banks...)
    – moopet
    Aug 29, 2014 at 10:31
  • 6
    Because it's brought to you by the same people who think SSN is a good authenticator? (Sorry; I couldn't resist a snarky answer.)
    – Bob Brown
    Aug 29, 2014 at 11:44
  • 23
    Can't begin with the letter x just to spite xXxMilfBanger420xXx who beats the Fifth Third dev team at Halo, despite being 12 years old. I'll take my +10 please.
    – corsiKa
    Aug 29, 2014 at 17:42
  • 6
    @ChrisCirefice On average, architects and DBAs at a bank will be no better than anywhere else. So, some banks get it right, and some get it horribly wrong. Just because we want them to be smarter and more secure than other businesses doesn't mean that the non-technical managers making the decisions know how to distinguish good solutions from bad. Aug 29, 2014 at 22:00
  • 4
    My guess is that on some legacy system, maybe an old mainframe system, there were accounts beginning with X that were admin accounts, and those accounts have been carried forward into the new system, and there is logic in various places that knows that an account called XJSMITH123 is an admin account. Still stupid, though. Aug 29, 2014 at 22:06

6 Answers 6


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.

  • 1
    I agree with you (and the study) that having slightly complicated usernames would make online guessing attacks harder, but I'm inclined to believe that a national bank would have good enough detection systems (IP-based, geo-location-based, etc.) that would thwart attacks even for different usernames. Thwarting 'X attacks for a given username' is trivial, but I can't see how a large corporation like this wouldn't have sophisticated methods to prevent guessing attacks. I only say this because I have forgotten my username twice now, so I'm slightly frustrated with the weird policy. Aug 29, 2014 at 16:02
  • It's not always a matter of what they could be using, but what practices they've decided are adequate. Online password guessing is a threat, but not a big one for banks compared to the more likely threats of phishing or trojans. Plus, it's easier for them to say 'hey we made usernames harder to guess so we've done our part' compared to investing in and maintaining a more sophisticated intrusion prevention product.
    – PwdRsch
    Aug 29, 2014 at 17:05
  • That makes me wonder what kind of software product management they have in place - because if I were in their position and had the resources to spend on a dev team to implement such a system to protect my users and their livelihood, I would without a second thought. I don't believe that using "well, we're insured and so are our customers!" is a good excuse for a lack of security. There's surely more that exists in the problem scope that I (nor anyone else) will ever really know, but it seems to me that banks are lacking, and give minimal effort to thwarting real threats. Just my 2¢. Aug 29, 2014 at 18:43

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 [email protected], 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).

  • When you say "if users are more likely to remember their usernames, this means that either they'll have to store their username in an insecure location" I think you mean "less likely," right?
    – trlkly
    Aug 30, 2014 at 16:13
  • 3
    @trlkly As all unix geeks know, less is more! Fixed, thanks. Aug 30, 2014 at 21:29
  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.

  • 1
    I would argue that if a bank (or other financial institution) doesn't have systems in place to detect a large number of sequential failed logins, even if the attempts are to different accounts, that's a problem in itself. Obscuring user IDs doesn't really help mitigate the underlying problem, which is a failure in monitoring.
    – user
    Aug 29, 2014 at 12:09
  • @Michael Kjörling There is a prevention and there is a detection. I was talking about prevention.
    – sta
    Aug 29, 2014 at 15:02
  • 1
    @Michael Kjörling Also, that was just an example attack. What if an attacker can use a user ID to launch a more sophisticated social engineering attack? Security by obscurity makes sense for me -- nothing I would rely on but it increases the threshold (the attacker needs more knowledge/time/money).
    – sta
    Aug 29, 2014 at 15:09
  • This to me appears to not be about prevention, it's about mitigation. Prevention would be perhaps blocking multiple sequential attempts (maybe by making each attempt take some non-negligible amount of time and only allowing a certain low number of outstanding attempts per remote IP address). Mitigation might be making credentials less guessable, causing an attacker to have to rely on other tactics. Now, both potentially have value, and the distinction isn't always very clear-cut, but they are separate points to consider.
    – user
    Aug 29, 2014 at 18:59

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…).

  • I concur with the idea that names starting with X are probably used internally, so +1.
    – trlkly
    Aug 30, 2014 at 16:14
  • Since user names (unlike passwords) may be shared, username rules should facilitate sharing over the phone (e.g., they should be case insensitive and you should do something about confustion between the letter O and the number 0).
    – emory
    Aug 31, 2014 at 14:29

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!


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .