1

Some bank sites force me to use system generated numerical login (ie. 8 digit number). Apart from singnificantly decreasing usability and giving impression of security (to some), does it serve any purpose? Isn't the security aspect illusionary, since decreasing probability of guessing the credentials can be as well enforced by password complexity policy without making user life that harder?

I'm facing a situation in which such a solution has been choosen for commercial booking/reservation site. I feel that it can seriously decrease the number of users decreasing overall profitability so I'd like to gather broader perspective before trying to influence the choice.

[EDIT] - why most banks use such a solution? Is it just to create an illusion of security?

deadbeef
  • 131
  • 2
  • Can you clarify, you are talking about a numerical, generated UserID, and not a password, correct? So instead of typing in deadbeef and your password, you type in 847367283 and your password. – Graham Hill Jun 06 '12 at 07:41
  • Yes, as stated in the subject and description the question is around logins, not passwords, although most issues probably hold for both of them. – deadbeef Dec 20 '13 at 13:48

4 Answers4

1

In my opinion, never.

Like you said, a proper password policy already serves the purpose of lowering the likelihood of a bruteforce attack being successful.

Forcing randomly generated numbers on a user is a sure way to give yourself a headache, as the number of "Forgot Password" request will be overwhelming.

Worst case - it forces the user to write the number down somewhere easy to find.

0

I disagree with the premise of your question. I think your bank's scheme is likely more secure than allowing users to choose their own passwords.

One thing we know with great confidence is that a lot of users choose poor passwords. For instance, one recent study found that if the attacker is rate-limited to 10 guesses at the password per account, then the attacker can expect to break about 1% of accounts. These numbers appear to be pretty robust across a broad range of different kinds of password-protected systems. Therefore, any system that allows users to select their own passwords will have poor security for a significant fraction of the user population.

In contrast, your bank generates the password for you. This avoids the problems of user-generated passwords. A random 8-digit password has about 26.6 bits of entropy. That's not too shabby. For instance, if the attacker is rate-limited to 10 password guesses per account, then with your bank's scheme, the attacker can expect to break about 0.00001% of accounts. That is a significant improvement over user-generated passwords.

In contrast, password complexity policies are fragile. They help users avoid some bad passwords, but many other bad passwords are often accepted. Fundamentally, because the password policy checker has no visibility into how you chose your password, and because the how is the important part for calculating entropy, they are limited in their usefulness. For many sites, these limitations are acceptable, but I can understand why a banking site might want to do better.

One possible concern with your bank's scheme is that, if they don't implement any rate-limiting on password guessing, then an attacker who keeps trying all possible 8-digit passwords may eventually be able to guess your password. If the attacker can automate this process and try 10 passwords/second, then it should take about 115 days to exhaust the space. However, this kind of attack is easy to defend against: the bank can simply count the number of failed attempts at guessing the password and rate-limit guesses or impose some other defense against automated password-guessing.

Bottom line: Your bank's approach is actually more reasonable than it may seem. On the whole, it is probably more secure than allowing users to choose their own passwords -- especially if the bank applies good mechanisms to rate-limit password-guessing attacks.

Community
  • 1
D.W.
  • 98,860
  • 33
  • 271
  • 588
0

In a banks scenario, the usual security policy blocks a user account when wrong passwords are entered multiple times. When the login Id is random, the chance for an attacker to randomly choose a login Id and try to crack or block an account access reduces by considerable amount. A trade off is required between security and business requirement which is always a challenge in the digital world.

Mohit Sethi
  • 692
  • 4
  • 7
0

I doubt the bank considers this a security issue at all. Rather it is an implementation detal.

Having worked for a few banks I can say that the number of legacy systems they need to support and the interoperability problems they have to deal with is truly astonishing. It's bad enough when a bank has been around for 60 years and is still supporting systems originally run on IBM mainframes, but these days most banks have been through several mergers and have had the added challenge of combining several banks' entire ecosystems. The number of special cases is astonishing.

More likely than not the bank decided it was just too difficult more work than they wanted to do to create a robust mechanism for a user to create their own unique username that would work across all the bank's systems. They would not consider it a security risk if you wrote down your username so long as you kept your password secret. While it might be nice for customers to pick their own username, it might also require the creation of yet another system to manage usernames and create another system of record with associated administrative costs, because this new system would also need to be 100% available with disaster recovery and business continuation planning.

Major Major
  • 492
  • 2
  • 9