25

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?

Improve this question
8

5 Answers 5

Reset to default
21

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).

Improve this answer
3
  • 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, 2012 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, 2012 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, 2012 at 19:52
7

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.

Improve this answer
10
  • 3
    How do "high security requirements" require storing passwords with reversible encryption? (Or did I miss the sarcasm?)
    – Nick Chammas
    Jan 23, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 20:37
3

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

Improve this answer
2
  • 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, 2012 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, 2012 at 6:12
2

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.

Improve this answer
1

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

Improve this answer
2
  • 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, 2012 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
    – makerofthings7
    Jan 24, 2012 at 2:01

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