51

The bank of a friend changed password policy, such that you are limited to 20 characters. However, he used 24 letters before and thus was not able to log in anymore. He called his advisor, who suggested, he should try to log in with the first 20 letters of his password... and it worked.

This really made us think about the password storage practice they use: I always assumed that a password is stored only as a hash, ("with a bit of salt") but never ever in it's plain form. Which would definitely be required to shorten a password by the bank. Or am I wrong?

A similar problem has been stated here.

Should I be concerned that this bank uses bad information security procedures?

RLH
  • 105
  • 2
Wulle
  • 611
  • 2
  • 3
  • 23
    *Truncating* long passwords has been done for years. You can put in 24 characters, but it only reads the first 20. To not accept longer passwords, and to make that as a new change, smacks of pure incompetence and poor programming. And, no, services do not need your "approval" to change their password policies. – schroeder Nov 25 '22 at 08:41
  • 90
    the more likely answer is they have always only actually been using the first 20 characters and just changed the front end to reflect that. – Affe Nov 25 '22 at 17:25
  • Depending on the context, the "password" may have been originally intended as something like a memorable word. Also, in any systems where you are asked for selected characters of a password, then it follows the password itself must be stored in the clear. – Steve Nov 25 '22 at 19:49
  • 6
    Banks are notorious for having strange password policies. Some of it has to do with the fact that many banks are still running legacy systems from the mainframe era. See https://softwareengineering.stackexchange.com/questions/87366/are-there-any-valid-reasons-for-disallowing-characters-and-limiting-the-length-o for some interesting reading on this subject. – mti2935 Nov 25 '22 at 20:43
  • 1
    @mti2935 Many banks limit complexity of pins/passwords **supposedly** because users tend to forget them, and they have *a lot* of old users, so I can understand a bit the motivation... but I find this a terrible reason for not allowing other people to use proper passwords. People that forget either it's because they haven't used it in months, and they'd likely forget the simpler pin/password too so you don't have any benefit, or the pin/password was so obvious that anyone with little personal knowledge of that person can reverse engineer that pin/password. – Bakuriu Nov 26 '22 at 15:28
  • There seems to be some confusion here. ***The system has ALWAYS only used the first 20 characters. (It's very likely the web page does not even send more than 20 characters.*** It just so happens they have now added to the web page, an alert, warning, or limiter, "20 character max". – Fattie Nov 28 '22 at 13:56

5 Answers5

56

Most likely the bank always used just 20 characters.

As Affe already suggested in the comments, the simplest explanation is that nothing has actually changed in the way the bank stores the passwords. Most likely the bank always had an internal password length limit of 20 characters, and the password entry fields used to silently discard the extra characters.

While truncating passwords is not necessarily a great idea, there's no reason to suspect actual security malpractice. Those 20 first characters are probably stored using a reasonable salted hashing scheme or a hardware security module (given all sorts of audit requirements, banks are in general slightly less likely to invent horrible homebrew crypto compared to other companies).

I can speculate that they now stopped silently truncating passwords as a necessary preparatory step towards supporting longer passwords (so that users will likely be able to set a new 24-character password now or in the near future and it will get hashed as a whole).

Thomas Markov
  • 103
  • 2
TooTea
  • 841
  • 3
  • 8
  • 6
    if **Most likely the bank only stores a hash of the first 20 characters** and ignore what the user actually knows, then this is a vulnerable authentication system. – elsadek Nov 26 '22 at 08:59
  • 6
    @elsadek Well,it might well be that no explicit truncation took place,but the password input field just had a length limit set to 20. Typing additional characters into it thus silently wouldn't work,but by the time you enter 20 characters the field is often already full of dots,so you don't get any visual feedback anyway. And regarding possible weaknesses,using a long password where all the entropy is concentrated in the last few characters is a dubious strategy at best,so the number of users materially impacted by truncation to 20 chars is likely low. – TooTea Nov 26 '22 at 12:52
  • TooTea the user has to be authenticated with the password he knows, your answer suggests that the systems check just the hash of the truncated password, which is the bad password? – elsadek Nov 26 '22 at 12:57
  • 7
    Most likely, the bank used a hardware security module to store the first 20 characters verbatim. Hashing passwords is required for security if the passwords will be held in a general-purpose storage device whose contents can be physically read without producing any kind of record of the process. For many purposes, using commodity storage devices and hashing is more practical than using hardware security modules, but if as a result of mergers a bank has a variety of systems that will need to share credentials after the mergers, the extra cost of hardware security modules may pay off. – supercat Nov 26 '22 at 18:24
  • 2
    @elsadek I'm curious, what is the vulnerability in this case? As in, how can this be exploited? – justhalf Nov 28 '22 at 04:49
  • @justhalf with the premise of the answer above, the system does authenticate the user with the wrong password. – elsadek Nov 28 '22 at 18:46
  • Okay, and with the premise of this answer, how can that be exploited? – justhalf Nov 29 '22 at 04:50
  • @justhalf any password that has a match with first 20 chars will pass. – elsadek Nov 29 '22 at 16:40
  • Yes, but how would an attacker exploit it? They would still need to find that 20 char combination. – justhalf Nov 30 '22 at 04:52
  • 1
    @justhalf I guess it's a theoretical "vulnerability" or "attack" in the way it's commonly defined in cryptography, that is: it let's you brute force an _n_-bit secret (password) in fewer than _2^n_ attempts (e.g. a 24-digit decimal random number as a password can be cracked 10000 times easier than it should). Of course this weakness is not very relevant in practice (20 characters is still more than enough). I'm not a cryptographer though (anyone who is is very welcome to correct me). – TooTea Nov 30 '22 at 08:15
  • @TooTea fair point. I can accept that :) – justhalf Nov 30 '22 at 08:20
15

This is not very good at all, and it makes me doubt that the bank knows what they are doing.

Max lengths for passwords is not uncommon on older legacy systems. That is bad, but perhaps understandable. But to add this restriction in the year of 2022 is just bad, and I frankly can't understand why one would do that. The only explanation I can come up with is that they have absolutely no clue what they are doing.

My next concern is the same as yours - how were they able to do this? To truncate the password they need to have it in plain text, so one might suspect that they store passwords in plain text. That would be extremely bad. However, we can not know for sure that they store the passwords in plain text just from this observation. An alternative explanation would be that they updated your password the last time you logged in (in the same way as one might update to a stronger hash algorithm when user log in). However, given how strange it is to institue a max length at all, I am prone to assume the worst here.

Finally, the bank could have spared themself having to answer questions from customers who can't log in by just silently truncating the password you enter to the max length. This would literally have been one line of code. In the end, maybe you should be happy that they didn't, so that you were alerted to the poor security practices of this bank.

Anders
  • 65,052
  • 24
  • 180
  • 218
  • 3
    It is not required to have the pw stored in plaintext in order to be truncated to 20 chars, see the @Spyros 's answer. – elsadek Nov 25 '22 at 16:22
  • 11
    It's worth noting truncating at like, 1024 characters isn't uncommon to prevent DoS stuff with the hashes, but that's definitely not what's happening here – Radvylf Programs Nov 25 '22 at 16:58
  • 18
    Banks face security audits (sometimes from third parties without the bank's consent). I've personally seen these 'audits' check password truncation, where they try to log in with a 96 character password and then see if only the first 80 were actually necessary. I bet the bank always only used the first 20, failed one of these security audits, and now imposes the 20 character limit on the front end to pass that audit test next year... – niemiro Nov 25 '22 at 20:12
  • 1
    related to @RadvylfPrograms's comment: https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length – Yay295 Nov 25 '22 at 22:47
  • 14
    Yes it often makes sense to have some max length for passwords. Presumably, most applications aren't going to want to allow a 5GB password, and if we agree that 5GB is too large and 20 characters is too small, then we agree there should be some max length, and we're just haggling over the price. – Zach Lipton Nov 26 '22 at 04:22
  • @elsadek I agree, this is what I am hinting at in the second paragraph. – Anders Nov 26 '22 at 11:12
  • @ZachLipton True, but not relevant here. (There are limits to how much they will let me eat at an all you can eat buffe as well.) – Anders Nov 26 '22 at 11:14
  • @ZachLipton Yes, but I'd argue that you should be able to use a *passphrase*, which could use, say, 10-20 **words**, so the minimum limit should be at least something like 10-20 characters per word times 10-20 words, or at least ~400 characters to be safe... round it up to 512 to have a nice round number and you are done: nobody will complain. – Bakuriu Nov 26 '22 at 15:33
  • @niemiro explains the situation perfectly. OF COURSE they were not storing the passwords in plaintext, that's just whacky. – Fattie Nov 28 '22 at 13:57
15

Should a bank be able to shorten your password without your approval?

The security policy of an entity that processes users' data is the entity's responsibility, not the users'. As such, the entity doesn't need the users' approval in order to make decisions on any aspect of the policy. Because this can lead to poor practices, though, there are laws that set the minimum level of protection that the entities should provide to their users. Other than that, there's not much one can do, unfortunately.

[...] never ever in it's plain form. Which would definitely be required to shorten a password by the bank. Or am I wrong?

There are some ways to achieve this without having to store the password in plaintext. The concept is similar to how password hash migrations may be implemented; here's an example of a password hash migration:

  • there's your password hash in the db
  • you enter your password at the client side
  • the password is sent in plaintext (usually/preferrably protected by other means, e.g. TLS) to the server
  • the server finds that the stored hash is an old one so it sets to replace it with a new one
  • the password you sent is hashed and compared to the stored hash
  • the hashes match, hence the password is valid
  • the password is hashed with the new algorithm
  • the password hash of the new algorithm replaces the old hash in the db
  • every time you login from that point on, the new algorithm's hash is used for comparisons

Similarly, this is what could have happened in your case:

  • there's the hash of your 24-character-password in the system's db
  • you entered your 24 characters password
  • the password is transmitted to the server in plaintext (again, under the protection of e.g. TLS)
  • the server finds that the stored hash is an old one so it sets to replace it with a new one
  • the password you sent is hashed and compared to the stored hash
  • the hashes match, hence your password is valid
  • the server uses the first 20 characters of your password to produce a new hash
  • they replace the old hash with the new one

What was described above could have been in place for a long time; once they saw that all (or the vast majority) of the users have had their passwords replaced, then they may proceeded in enforcing the rule to the client side as well. The key point here is that they may have done this without having to store the password in plaintext at any time.

Unfortunately, I cannot explain why they have set the limit to the password length; I can hypothesize but that would be a wild guess.

Should I be concerned that this bank uses bad information security procedures?

Honestly, only the bank's key people know.

Truth be told, you don't know whether they actually shortened the password or not; it may have always been the case that you were providing a password of 24 characters but they only used the first 20 of them in order to produce the password hash, and now they just decided to enforce the rule at the UI side too.

Spyros
  • 1,451
  • 1
  • 14
  • 13
    Answer is technically correct, but as a cynical developer I have little faith that a company that has password length limits would have proper storage practices. – bracco23 Nov 25 '22 at 17:27
  • I thought the title question ("Should a bank be able to shorten your password...?") was not about whether the bank should be _allowed_ to, but about whether a bank that is using reasonable security practices would be _technically capable_ of doing so. If that understanding is correct, the first paragraph of your answer is not quite relevant. – David Z Nov 28 '22 at 07:24
3

This seems more related to communication strategy with clients. Should clients be advised of the new policy before its implementation? Is there a risk if doing so?

It is not required to store the password in plain text in order to truncate it to 20 characters. The password's string could be handled on the fly, which means they store only the hash of the first 20 characters, side by side with the original password's hash.

They might be implementing the new policy gradually, so at some point the server already had the hashes of the first 20 characters password, while the original is yet in use by the authentication process.

Edit:
A weak authentication system would store the hash of first 20 characters only and ignore the user's actual secret, that means for the system a passwords like myTwentyCharPassword is equivalent to :
myTwentyCharPassword6697 or
myTwentyCharPassword@222 or
myTwentyCharPassword@@00 or ... etc

That's why the hash of the original password must be stored also, for the authentication to work properly as expected by the user.

elsadek
  • 1,822
  • 2
  • 18
  • 55
2

As a developer (with 25yrs experience, 10yrs in banking), I can confirm that NO bank should EVER store (and therefore "know") your password.

When you create a password (e.g. "H3ll0_123!"), your browser sends the password to the bank's backend server which then converts it into a hash (e.g. b89eaac7e61417341b710b727768294d0e6a277b). The only form of your password that ever get stored, is this hashed version of it.

Whenever you later login, your credentials are verified, so the bank once again convert your entered password to a hash and compare it to the stored hash. If they match, then you're successfully verified. If not, you have supplied an incorrect password.

At no stage should the bank interfere with your plain text password (i.e. write it to a log file, store it, display it etc. NEVER! It would be highly unethical)

So in summary, NO bank, or any service provider for that matter, should EVER know your passwords. And therefore NEVER be able to shorten them on your behalf.

PS: you also can't calculate a shortened password hash from a full sized password hash either - e.g. password "H3ll0_123!" => hash b89eaac7e61417341b710b727768294d0e6a277b, might translate to something completely different if you shorten it, such as password "H3ll0" => hash 6c98bf0e3210f1c6923427a1e1a3b214c1de92c467683f64667

z0mbi3
  • 129
  • 3
  • `NO bank, or any service provider for that matter, should EVER know your passwords. And therefore NEVER be able to shorten them on your behalf` But the bank obviously sees the password when you send it to them, and nothing stops them from truncating it before hashing (the last paragraph seems to me to imply that it isn't possible, but it's because it's considering only the truncation _after_ the hashing and not before) – sox with Monica Nov 28 '22 at 12:42
  • The bank should receive your password and immediately hash it and dispose of it. That's what any tech provider should do. This is 99% of the time what happens, but it's possible that e.g. 1% of tech providers store or intervene with the password. This is highly unethical by the way! And to store this unencrypted is the worst offence anyone can do. But in short, no, a bank should not intercept and shorten - it's highly unethical. – z0mbi3 Dec 21 '22 at 11:52