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?

fredley
  • 1,455
  • 1
  • 16
  • 25
  • 3
    Related: [How secure is asking for specific characters of passwords instead of the entire thing?](http://security.stackexchange.com/questions/7467/how-secure-is-asking-for-specific-characters-of-passwords-instead-of-the-entire) – Gilles 'SO- stop being evil' Jan 23 '12 at 15:07
  • 3
    What banks do this? Chase and Schwab and a few others I checked don't – makerofthings7 Jan 23 '12 at 16:01
  • 2
    +1 to @makerofthings7 - My current bank doesn't, nor has any other I've dealt with. – Iszi Jan 23 '12 at 17:07
  • 3
    I'm surprised by this, every bank I've ever dealt with (in the UK) uses this as part of their authentication. – fredley Jan 23 '12 at 17:09
  • 2
    Some more answers to a similar question here http://security.stackexchange.com/questions/4830/how-do-some-sites-e-g-online-banks-only-ask-for-specific-characters-from-a-pa/4835#4835 – Rory McCune Jan 23 '12 at 17:39
  • Sounds like if banks are truly worried about this, they should be using One-Time passwords. – user606723 Jan 23 '12 at 19:28
  • 7
    Asking for individual characters from a password? WTF? – CodesInChaos Jan 23 '12 at 19:35
  • 1
    my bank (in the UK) uses this as part of a two-factor authentication: a secret password that you enter all of, and a less secret password that you enter selected letters from. Seems like a reasonable choice if they are worried about keyloggers. – RoundTower Jan 23 '12 at 23:52

5 Answers5

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

Community
  • 1
dr jimbob
  • 38,936
  • 8
  • 92
  • 162
  • 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
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.

StrangeWill
  • 1,593
  • 8
  • 13
  • 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
  • @Nick: High security requirements don't require one-way hashing (though I do agree, hash by all means when possible!), they only require strong cryptography and secure key management practices. – StrangeWill Jan 23 '12 at 17:42
  • 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
  • The purpose of this as I understand it is so that the call centre operators can verify that you know your password (or at least three random characters from it) without asking you for the whole thing. The fewer people that know a secret, the more *secret* the secret is. – Ladadadada Jan 23 '12 at 18:18
  • 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
  • I've always seen this defended by the banks as extra security against keyloggers. Also the use of dropdowns to "protect" against keyloggers. I'd prefer to just opt out of telephone banking in favour of secure online banking. (Meaning hashed password, requested in full every time and no nonsense restrictions on the password) Or have them use a code they text to me and I read back along with the basic name, DOB, partial address, mothers maiden name etc that has served us all so well for so long. – pipTheGeek Jan 23 '12 at 19:23
  • @StrangeWill - If the server can decrypt a password, a knowledgable sysadmin can as well mimicking the server's process. They might have to do some tricks to do so; but the info is there. That said; anyone with full access to the servers can get the passwords if they really want, even if passwords are being checked against hashes (e.g., secretly log the passwords that are being sent to the server in plaintext somewhere) -- though hopefully security audits/practices would prevent this. But then a one time breach only gives the logins until its detected versus everyone's password immediately. – dr jimbob Jan 23 '12 at 19:57
  • 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
  • Oops - I should not have addressed my last comment to you StrangeWill; it was meant as a reply to @NickChammas comment `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` (my bad; I think I saw your name in the comment and replied wrong). – dr jimbob Jan 23 '12 at 22:20
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

Sachin Kumar
  • 830
  • 3
  • 9
  • 14
  • 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 06: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.

tylerl
  • 82,665
  • 26
  • 149
  • 230
1

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

Community
  • 1
makerofthings7
  • 50,488
  • 54
  • 253
  • 542
  • 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 – makerofthings7 Jan 24 '12 at 02:01