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.

TRiG
  • 609
  • 5
  • 14
MDMoore313
  • 978
  • 9
  • 14
  • 18
    Because the infrastructure holding your credentials (in plaintext of course) and your money is a 20 year old mainframe. –  Apr 17 '15 at 14:35
  • Only 20 years old? – MDMoore313 Apr 17 '15 at 14:36
  • 2
    Ballpark number of course, but you get the point. :) –  Apr 17 '15 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 '15 at 15:18
  • 7
    Probably running a hacked together codebase over 20 years old written in FORTRAN or COBOL – Cole Tobin Apr 17 '15 at 17:49
  • My ex-gf also confirmed this. They still hire cobol developers to their staff, just to maintain their ancient code. "If it works, we ain't changing it" is their motto. – AKS Apr 17 '15 at 20:54
  • 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 '15 at 21:03
  • 1
    I work at a bank, and our (outsourced) **core banking system** uses passwords that are not case-sensitive. That's not even the worst thing, though. Another service has plaintext passwords. – KSmarts Apr 17 '15 at 21:55
  • @Polynomial AS/400 user here. UGHHHH. –  Apr 17 '15 at 23:29
  • 1
    Related: [Are there any valid reasons for disallowing characters and limiting the length of passwords?](http://programmers.stackexchange.com/questions/87366) – BlueRaja - Danny Pflughoeft Apr 18 '15 at 00:06
  • 1
    Amazon used to (as in like, 2012-2013) truncate your password to eight digits *without telling you*, so anything you entered after 8 digits was silently ignored, due to some limitation of the unix components they used at the time. My wife had two passwords - more secure and less secure, differing by adding some characters - and was very irritated to learn she was using the less secure one perforce... – Joe Apr 18 '15 at 01:08
  • 1
    Case sensitive? Ask yourself why it is often limited to 8 characters… their brains are legacy, and will hopefully be retired and switched with newer ones, which actually are able to think… – o0'. Apr 18 '15 at 08:10
  • Note that (*theoretically*), if your bank account gets emptied because you had a bad password because your bank forced you to have a bad password, it's the bank's fault, and they owe you your money back. – user253751 Apr 18 '15 at 10:20
  • 1
    Welcome to the banking industry, where money flows and security doesn't matter! – Nathan C Apr 20 '15 at 12:23

3 Answers3

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.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 4
    Yup, my money is on it being a frontend for an AS/400 or similar. – Polynomial Apr 17 '15 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 '15 at 03: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 '15 at 09: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).

Stephane
  • 18,557
  • 3
  • 61
  • 70
  • 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 '15 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 '15 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 '15 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 '15 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 '15 at 18:55
  • @Szabolcs, I've had credit card fraud happen to me twice in the last few month. We figured out it was due to restraunt that allows you to place orders online. Their website was compromised. In the first instance, the credit card company didn't authorize the transaction and contacted me. In the second, I got an alert and stopped the transaction within minutes (I also called the store to warn them not to process it.) It's a crappy system, but users have low liability. I try to use Apple Pay whenever I can but it it hasn't been adopted by many stores yet. – pooter03 Apr 17 '15 at 18:56
  • Storing passwords in plaintext *on a general-purpose computing device* is bad, but there exist hardware security modules which do not allow the contents to be read without creating an audit trail that could not be altered without getting physical access to heavily-guarded equipment. Nowadays using password hashing on general-purpose devices is more practical than using secure hardware, but hardware can be more secure. Someone who gets access to a hashed password database could try millions of passwords against each user without anyone being the wiser, but an HSM could block that. – supercat Apr 17 '15 at 22:17
  • @supercat That doesn't excuse storing passwords in plain text. Hardware security modules are security through obscurity. – Cole Tobin Apr 18 '15 at 05:49
  • @ColeJohnson there's unfortunately **PLENTY** of websites that arbitrarily limit your password length for no reason. This never implies they store it plaintext, it only implies they have no clue what actually is a hash even if they're using it. – o0'. Apr 18 '15 at 08:12
  • (of course, since we are talking about a bank, then yes they are likely to store it plaintext anyway, but that's beside the point) – o0'. Apr 18 '15 at 08:13
  • @ColeJohnson: If only people with physical access to a machine that is kept in a heavily-guarded room will be able to read information stored therein or even make unlogged queries about whether a credential is valid, how is that security through obscurity? Physical security isn't always cheap or practical, but that doesn't mean it's not secure. – supercat Apr 19 '15 at 14:57
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.

Nzall
  • 7,313
  • 6
  • 29
  • 45
  • Nice answer, any cites to back this up? – MDMoore313 Apr 17 '15 at 18:18
  • 3
    You could also just normalize the password before hashing it. – Sam Dufel Apr 17 '15 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 '15 at 22:24
  • @Lorenpechtel Since it's mainly speculation on my part about the hashing, I've removed that part. – Nzall Apr 18 '15 at 12:11