My bank (and every bank I've come across) only ever asks for individual characters from my password when logging in. Is my bank storing my password in plain text?


I agree with StrangeWill's answer; it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible). However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long. It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56. Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second. They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks. E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used. This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).

  • Interesting analysis. Are you saying that using reversible encryption (instead of one-way hashes) on the 3-character combinations makes brute-forcing the original password harder? How? – Nick Chammas Jan 23 '12 at 17:22
  • I think he is referring to the fact that a keylogger would only acquire part of the password and if a different set of characters is required next time then the logged partial password won't get you in. – pipTheGeek Jan 23 '12 at 19:27
  • 1
    @NickChammas I guess my point wasn't clear -- regardless of what they are doing this method means a sysadmin/hacker at the server should be able to either reverse the encrypted password (getting the plaintext the same way the server does it) or do a trivial brute force of the several hashes. Either way don't reuse your password, which is good advice even when its a salted hash. pipTheGeek - yes that sums the keylogger part up. – dr jimbob Jan 23 '12 at 19:52

They are probably storing it with reversible encryption. Though without an audit of their system it's impossible to really know, but this is fairly likely due to their high security requirements.

  • 3
    How do "high security requirements" require storing passwords with reversible encryption? (Or did I miss the sarcasm?) – Nick Chammas Jan 23 '12 at 17:09
  • @Nick - Especially reversible encryption that the running server must be able to automatically decrypt to check. Your password should not be considered secret to the bank or people on its systems (unlike say hashed passwords). – dr jimbob Jan 23 '12 at 17:26
  • 1
    StrangeWill - Good point. I guess then the stress is on "secure key management practices". @drjimbob - Why shouldn't your password be a secret to the bank's employees? Even with reversible encryption, I presume only machines will ever be decrypting and looking at the passwords in plain text, never a bank employee. – Nick Chammas Jan 23 '12 at 18:13
  • 1
    I believe the purpose is more of a piss-poor attempt to fool keyloggers by only giving them a piece of the puzzle. I guess somewhat OK if you log into your bank account once on an infected PC, but completely useless when your home PC is the one that is infected. – StrangeWill Jan 23 '12 at 18:25
  • 1
    @Dr jimbob: I agree, there are a long list of reasons you should hash things such as passwords instead of encrypt them, it's their system not mine! I can only describe the madness, not explain why they do it! ;P This type of stuff is rampant in software though, and isn't abnormal to even find plaintext passwords being stored in lots of software (though I assume banks at least use some crypto). Security-minded development is really lacking in most software IMO. – StrangeWill Jan 23 '12 at 20:37

Some possible scenarios

  • bank is storing password in clear text (Not very likely)
  • Bank is storing encrypted password(not hashed)
  • Bank storing hash(salted) of each character (don't be surprised, I have seen this)

This is obviuosly not a complete list, so feel free to edit add comments to this

  • 5
    I always thought there was a limit to bank stupidity, number 3 shows I was wrong. I think it might be time to put my money in the shed. :( – pipTheGeek Jan 23 '12 at 19:29
  • 2
    The point of keeping your money in a bank isn't so it won't get stolen; it's so that if it does get stolen, the bank will replace it. :-) – gkrogers Jan 28 '12 at 6:12

As previously stated, you simply will not know unless they tell you.

However, it's worth pointing out that many banks (especially the larger ones) put restrictions on password complexity because the web interface is simply a front-end for a decades-old mainframe system that had corresponding restrictions for other reasons. It doesn't mean that the passwords are aren't being hashed, it just means that the ancient system can't accept certain types (or lengths) of input for other silly reasons.

Is that better? Not necessarily. But at least it's not necessarily a reflection of incompetence either.


Just speculation, but perhaps they found a way to use Homomorphic encryption on the character (or Unicode value) to provide protection

  • I'm not sure this would work. Can you explain more? When you say homomorphic encryption for this scheme, I'm imaginging you have a way to check a three character (say chars 1,5,8) combo versus a hash made with homomorphic encryption (e.g., have a function that says these three characters work). Wouldn't this make bruteforcing the hash trivial as the hash could be checked char by char independently? I generally think of homomorphic encryption as say performing heavy computation on encrypted values and not being able to check the result until you decrypt and don't see how that is relevant. – dr jimbob Jan 23 '12 at 22:49
  • The idea could be illustrated by the fictitious function HomomorphicAdd(EncryptedPWChar_ToASCII + CharPosition). But this is a guess. I didn't spend more than time thinking about an actual implementation than I did typing this answer. I'll leave that analysis and discovery to the experts – halfbit Jan 24 '12 at 2:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.