23

It was recently brought to my attention that a certain big bank website allows users to log in with passwords that are not case sensitive. After confirming this, I checked other websites I bank with and found a second big bank website that does the same thing. I did not check their mobile clients.

To me it seems like this lowers security, as this increases the number of unique passwords that can be used to log in to my account. Is there a common reason and/or justification for this from a security standpoint? The top non-security reason I could come up with is that it reduces calls to the helpdesk related to case sensitive passwords.

Improve this question
14
  • 18
    Because the infrastructure holding your credentials (in plaintext of course) and your money is a 20 year old mainframe.
    – user42178
    Apr 17, 2015 at 14:35
  • 2
    Ballpark number of course, but you get the point. :)
    – user42178
    Apr 17, 2015 at 14:37
  • 3
    You're more likely to find that the hardware is new (e.g. IBM Power Systems kit), but the OS is a Unix-like distro such as AS/400 which is technically ancient, but still maintained.
    – Polynomial
    Apr 17, 2015 at 15:18
  • 7
    Probably running a hacked together codebase over 20 years old written in FORTRAN or COBOL
    – Cole Tobin
    Apr 17, 2015 at 17:49
  • 1
    What I can add here is that my bank's password not only is case sensitive, it also must start with 6(?) digits for phone verification. They changed this a while back, but while I always thought that the PW was case sensitive before, I think I never verified it, so it may always have been case insensitive.
    – Martin
    Apr 17, 2015 at 21:03

3 Answers 3

Reset to default
35

The most likely reason is that the backend only supports case-insensitive passwords. To quote OWASP:

Occasionally, we find systems where passwords aren't case sensitive, frequently due to legacy system issues like old mainframes that didn't have case sensitive passwords.

The chances of this happening are much higher with stodgy old institutions like big banks that are still running mainframes in the datacenter.

Improve this answer
3
  • 4
    Yup, my money is on it being a frontend for an AS/400 or similar.
    – Polynomial
    Apr 17, 2015 at 15:16
  • Is there any reason why the identification done in the front end should use the same passwords as in the back end?? In fact is there any reason an individual customer should be able to authenticate to the back end at all? I think this reason is totally bogus.
    – Marc van Leeuwen
    Apr 19, 2015 at 3:56
  • @MarcvanLeeuwen, companies using mainframes also tend not to use elegant multitier architectures with separate authentication directories. I understand that it seems too strange to be true, but I've seen it in action.
    – gowenfawr
    Apr 19, 2015 at 9:10
15

Typically, it is a choice between usability and security. Users have a surprising amount of trouble with capitals in password so capitalizing password before hashing them makes it easier on the user.

Of course, that also decreases the maximum entropy of a password of a given length. To compensate, you should use longer passwords... If you're lot limited to some silly number like "10 characters max" (in which case you're entitled to wonder if they are really handling passwords in a secure manner).

Improve this answer
11
  • 2
    I'm in the process of moving to a new bank because of that very issue. I've complained multiple times but they insist that 10 characters is enough.
    – pooter03
    Apr 17, 2015 at 15:40
  • 3
    @pooter03 If they have a max character limit, I'd be suspicious they're storing passwords in plaintext (like VARCHAR(10)). I'd bet they'd only allow ASCII characters because it's not worth their time to update their ancient codebase that "already works fine"
    – Cole Tobin
    Apr 17, 2015 at 17:54
  • Why did this get downvoted? Stephane didn't say that it was a good idea to do it, he merely states why banks might make such (misguided) decisions. BTW I've seen banks upgrade their online banking to a "better, smoother" experience, and at the very same time introducing a 10-character limit on their password. So I find it hard to believe that these limits are there because of the limitations of an outdated backend. It's more likely a misguided management's decision to "improve usability" and reduce customer support load.
    – Szabolcs
    Apr 17, 2015 at 18:37
  • This explanation is also in line with how ridiculously insecure banking is in the USA, just to make it a little more convenient. No PIN codes necessary for bank cards, security tokens are unheard of, people can start using an account by stealing just the easily copyable of photographable card number. The only protection is some sort of guarantee by the bank that they'll reverse fraudulent charges, and fraudulent charges seem to be extremely frequent. Never heard it happen to anyone outside of the US but I know many people to whom it happened inside of the US (fortunately not me).
    – Szabolcs
    Apr 17, 2015 at 18:41
  • @Cole Johnson, the 10 character max limit is enough of a red flag to spur me to move forward. I don't want to find out whether or not they encrypted the password store or not. :)
    – pooter03
    Apr 17, 2015 at 18:55
5

One of the reasons that banks often have case insensitivity in their passwords is because of phone banking: banks existed FAR before the internet existed, even before telephones were a thing. So once telephones became widespread, many major banks allowed people to to banking stuff via the telephone. it makes sense: all you need is two account numbers and a code to verify that you're the one doing the transaction. For this code, you usually went to the banking institute.

However, since you needed to enter your code using the number pad on your phone, the system just responded to the number presses, not the actual password. That means that there wasn't even a distinction between lower and upper case, because there was no difference in how you entered them on a numpad.

Once internet banking arrived, those systems used a similar backend to the phone banking system, including using the same passwords so users didn't have to remember extra passwords. However, this lead to the problem that it was trivial to make the difference between a lower and uppercase letter, and the way the passwords were entered in the system during the phone banking era was inconsistent: some tellers would use capitals, some would use lowercase, some would use CamelCase,... To prevent people from having to return to their bank to clarify this, they HAD to make passwords case-insensitive. Note that this part might not be applicable for all banks, but some banks have this reason.

Sources:

https://en.wikipedia.org/wiki/Telephone_banking - Wikipedia article about telephone banking;

https://www.ing.be/en/retail/day-to-day-banking/self-banking/pages/phone.aspx?tabName=Details - Article on Belgian bank website about phone banking;

http://www.hsbc.co.uk/1/2/ways-to-bank/phone-banking - Article on major British bank about phone banking.

Improve this answer
4
  • Nice answer, any cites to back this up?
    – MDMoore313
    Apr 17, 2015 at 18:18
  • 3
    You could also just normalize the password before hashing it.
    – Sam Dufel
    Apr 17, 2015 at 20:14
  • I see no reason you can't salt and hash such a password. Simply convert any password to it's touch-tone equivalent and hash/salt that. You're giving up 3 bits/char of entropy but there's no reason not to use other aspects of modern security.
    – Loren Pechtel
    Apr 17, 2015 at 22:24
  • @Lorenpechtel Since it's mainly speculation on my part about the hashing, I've removed that part.
    – Nzall
    Apr 18, 2015 at 12:11

You must log in to answer this question.

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