What methods can be used to prevent mistyped usernames?

Question

I wanted to log on to my account on my bank's website. The account is protected by a number of security checks. The first one is what really amounts to a username, a confidential one. It's an 8-digit numeric passcode (given to me by the bank), after entering which I need also to enter some personal data and a password. Today, I was notified by the system that my passcode was locked out and that I had to contact the bank by phone. I did, and I was informed, after giving a fair amount of personal data to the person on the phone in order to verify my identity, that my account was now all good and I could log on. They also told me that was probably because someone used my passcode by mistake and, being unable to enter the correct information later on, locked my passcode out. I'm quite confident that that was indeed the case -- it seems rather plausible, though my first reaction was, "Someone just tried to steal my money!"

If that's what happened, it was an inconvenience for all parties involved: the person who was mistaken about their passcode was not, obviously, informed that they were entering a wrong passcode, and they wasted their time trying to enter the correct information later on; the bank had to use their human resources on helping me out; I had to waste my time and money on calling the bank at 00:05 AM on a Monday.

Is anything being done by banks or other entities in order to prevent such situations? What is being done? It's them who provide the codes, and I see no reason not to make them dissimilar among the users. I've not tried to do any calculating, but it doesn't seem very complicated to make sure certain common mistakes are not going to happen.

EDIT: Thank you for all the answers given so far. The answers stress the fact that the inconvenience was minor and I should be happy that was all that happened. I'm certainly not unhappy my money didn't get stolen. :) However, could you please address the question of dissimilarity? Is there a good reason not to make sure the randomly generated passcodes are immune to transpositions of adjacent digits for example?

Answer 1

Banks that issue numeric usernames are rather annoying. And while I am more paranoid that most, you're probably right that someone just fat fingered their ID and didn't realize it until they locked you out.

To answer the question, some banks do help ensure you are attempting to login with the correct user account. Those "Security Images" you see on some bank login pages, yes the banks tell you that those pictures help you ensure you're logging into their website. But the real benefit is to help users realize they're attempting to log into someone else's account. Sites that use this process will ask for your username on the main login page, then take you to a new page with your 'security image' and the password field. They may also ask for another form of authentication (security question, etc) before asking for the password if you are logging in from a computer they haven't seen you login from before.

If every time you login you see the image you selected on signup, you're more likely (assuming you use the site often enough) to notice when that image is different. This could mean that you're logging into a phishing site, but more likely, you fat fingered the user account.

EDIT: -- To answer your edit --

When dealing with numeric userids, there are only 10 digits and they're crammed in a very small area on 10-keys and mobile devices. Given many tens (or hundreds) of thousands users, the scarcity of digits and how close they are in two of the three common layouts, there is really no way to adequately ensure that any one ID is dissimilar enough from another to prevent common mistyping errors.

Also, if you think about it from a performance standpoint, detecting if a new ID is uniq is a very efficient and quick process in most well designed systems. However, detecting if a new ID is dissimilar from others would require iterating over every other user ID and comparing the two with whatever your algorithm is. This would be a (relatively) slow and painful process. With enough time and effort, you could cache ngrams and any other comparison points to help speed it up, but still, it's going to be slow.

In short, I'm not aware of any company doing this on user ids, certainly not on numeric ones. (But I'd happily read a whitepaper or engineering blog about someone doing it)

A couple of other users (including Philipp) have mentioned checksum digits, which I didn't discuss since it I initially focused on the system side and the dissimilar usernames focus of the question. But in further thought it does have a place in this conversation. Checksums are often used to augment account numbers i.e. Credit Card numbers, which any first semester programming student can write a validation tool for. This all but eliminates mistyping and can be checked client side without posting to the entry form. It's impossible to say (without inside knowledge) if anyone is using this on numeric user accounts... I would venture that someone is, but I haven't seen it and since it wouldn't make for interesting discussion (or documentation) within the community, haven't heard of anyone doing it. I think we can all agree, your bank isn't. :)

Answer 2

You could generate the passcode by taking a consecutive number and append one or more additional digits to it which are a checksum of the actual number. You can check the validity of a passcode on the client-side by checking if the checksum-digits entered by the user match the actual part of the passcode.

One checksum-digit reduces the chance to accidentally enter a valid passcode of another user to one in ten, two to one in hundred and three to one in thousand.

The downside, however, is that the longer the passcode, the harder it is to memorize, which will in turn lead to people forgetting their passcodes and again consume human resources to recover it. That means that the designer of the system has to find the right balance between inconveniences generated by people entering passcodes of other people and people forgetting their passcodes.

Answer 3

They prevented an attack on your account. This is a desired outcome - had they been able to try unlimited passwords, they'd have guessed yours. The attack was stopped in time, costing you a minor inconvenience. If this pattern was repeated in order to seriously inconvenience you, the bank can simply issue you a new random passcode.

They aren't as interested in preventing inexpensive inconveniences as they at preventing costly fraud.

EDIT:

The problem with a randomly assigned 8 digit number is that you likely won't remember it if you don't have to use it on a regular basis. How do you remember if your number is 82640927 or 82604927?

Something that has long been used to reduce typos is the Luhn check digit algorithm. It will validate the number, prompting the system to ask a user to re-enter the number if any one digit is incorrect, or if a pair of digits is accidentally transposed. Credit cards have used this for decades. But the Luhn algorithm will not prevent all accidental problems, nor will it stop deliberate attempts.

The best way to reduce accidental collisions is to increase the potential number space, and to randomly assign users across the number space. Simply having 10 digit numbers doesn't stop collisions if the users are numbered 0000000001, 0000000002, 0000000003, ... One way to achieve this is to use a sequential seed, then feeding that into a hash algorithm to produce the 10 digit number (taking an unsigned int of the bottom four bytes is one way to achieve this.) It's sufficiently random that any two numbers won't have a relationship to each other, making accidental typos truly few and far between. A Luhn digit can also serve as a courtesy check to help the user not waste time entering a password on an obviously faulty account number.

Answer 4

Web services can take into account the location of where log in requests are originating from and correlate with your past log in attempts. Similar to how credit card companies will contact you when they notice "unusual activity" on your credit card. This is one piece of logic a organization providing a service on the web can use to address incidents like this. If they can say with a high confidence that the username associated with the connection isn't you - they can take steps to isolate those events from impacting the real account.

In your case, the bank could have the logic programmed or analyst deduce if the individual attempting to log in with your account ID was from the same area as you - or if they are confident that it was a completely different geographical area.

Another route that would help give them a picture would be the logs available to them from the event. It sounds like the customer service representative you spoke didn't have access to said logs - and probably wouldn't have had the expertise to view them. Even if they did - whose to say the application verbosely logs that information? Would they even want it to? How many people would then have access to that information?

Advance logic in these situations can get tricky quickly. How your bank in this instance handled it sounds like the most straight forward and least expensive response for all involved. If the only disruption for you in service was a 5 minute phone call with your bank - it's a very low impact way to address a potentially high damage situation.

Answer 5

There is one key advantage to an assigned username or password - usually it's more random than a user would generate. For an 8 character numeric only username, there are 100 million (10^8) possible permutations. This is less than 1/3 of the population of the USA, and about 1/2 the population of Indonesia. So this method certainly would not scale to beyond that number of online banking users.

Yes, this does mean that usernames are easily guessable - an attacker just has to iterate through 8 digit numbers. Of course, one would have to be very lucky to brute force their way into a high net worth account in this manner.

However, as you experienced, the same activity can easily be used to perform a Denial of Service attack. Just randomly guess the password N times per username in quick succession (where N is the number of attempts required to trigger an account lock). In a few hours, the bank will have to phone-verify every online banking customer, and their call-center will be overwhelmed.

The solution is to expand the username character set. By allowing case-sensitive letters as well, the number of permutations expands to 218 trillion ((26+26+10)^8), greatly reducing the effectiveness of the above denial of service attack, as well as accidental collisions like the one you experienced.

The downside is that usernames become more complex for users to remember and enter. This can be partially mitigated by allowing users to choose usernames. And the downside of that is some loss of randomness.

Answer 6

One thing that some websites, like Google, seem to be doing to prevent this type of attack is to, after a certain amount of login attempts, not lock you out, but give you something called a CAPTCHA. This is used more to prevent bot logins, but it slows a malicious human user down, as well, as he/she still has to figure out the password, and some CAPTCHAs are hard. It could also inconvenience a legitimate user, but by the time you get a CAPTCHA on these sites, it's likely you don't remember your password.

Another thing some sites seem to be doing is to lock a username temporarily, not permanently. For example, my 2-year college's site locked you out for 15 minutes when you entered the wrong password 3 times, then an additional, cumulative 5 minutes for each new password attempt before the lock is up. Many Android phones' screen locks do this as well. This method could allow DOS attacks, as the malicious user could try so many attempts the true user would effectively never be able to log in again, although linking the time limit to specific IP's, cookies, etc. could mitigate this, bearing in mind that IP's can be spoofed.

Both of these methods function more to deter bots than malicious human users, but they slow human users down, while not permanently locking the account for the legitimate user in the case of accidents. I'm not sure how well each method would work for banks, as they are much more paranoid than, for example, Google. Also, most of the sites I have seen these on used user-specified usernames, but I assume they would work for bank-specified numeric usernames, as well.