11

Some financial websites that I use use passwords in a peculiar way. Instead of asking me the whole password string, they only ask me to enter e.g. "3rd, 5th and 8th character of your password", i.e. a random combination of characters of the password string.

I think this would make sense if it's done using a shared random number table etc. But this is a password. In order to do this, they'd have to either store my password without hashing, or store the hashes for all the combinations they want to ask, which also sound bad. Am I right to think that this is a fairy bad security practice?

Enno Shioji
  • 237
  • 2
  • 6
  • Sometimes. That could be good if they are checking with a Hardware Security Module. –  Aug 03 '14 at 17:36
  • I agree, on the surface or only looking at the title, these 2 questions are dups. However, looking at the full questions, this question is more asking why banks use this practice, while the other question asks if it is secure and, if so, why. This question also asks whether it is secure, but that isn't the main purpose. – trysis Aug 03 '14 at 19:28
  • I recall using an phone banking service which had a similar approach - there a live person asked for just some letters from my "secret word" as part of the identification procedure. It makes sense that the operator would not be told the whole password (25 years ago... Long before touch tone phones were universal in that part of the world). It makes no sense for a website. – Floris Aug 03 '14 at 19:58
  • 1
    @trysis I think that it is still a duplicate. But we already have this exact question (bank specific) twice. [here](http://security.stackexchange.com/questions/10938/is-my-bank-storing-my-password-in-plain-text) and [here](http://security.stackexchange.com/questions/4830/how-do-some-sites-e-g-online-banks-only-ask-for-specific-characters-from-a-pa). oh, and also [here](http://security.stackexchange.com/questions/52972/how-does-my-bank-knows-my-second-and-forth-chars-of-my-password) – tim Aug 03 '14 at 21:45
  • 2
    and here is [another one](http://security.stackexchange.com/questions/38744/taking-password-letters-not-whole-one-is-this-secure). All are easily found using the site search or google:`site:security.stackexchange.com bank password` – tim Aug 03 '14 at 21:54

2 Answers2

31

You are basically right; this is poor practice, for several reasons:

  • As you note, it requires server-side storage of the password as plaintext or in some reversible format.
  • Typing a password repeatedly works on "muscle memory", which allows the user to "remember" his password as a sequence of gestures on the keyboard; asking for specific letters exercises distinct parts of the brain and is likely to induce dangerous behaviours, i.e. writing down the password.
  • If the site asks for only three characters, then an attacker has a fair chance of gaining access by simply responding with three random letters. Online dictionary attacks can work, too. (Of course, bank Web sites often couple that with a trigger-happy lockout system, but a smart attacker will switch to another target account before reaching the autolock limit.)

The three main reasons why bank sites do that are:

  1. If they ask for only three letters, not always the same, then a key logger or shoulder surfer won't be able to immediately his illegitimately acquired knowledge. It can be thought of as some sort of damage containment, where the password is only partially divulged.

  2. Asking for only some letters is an Hollywood-sanctioned security measure. It makes for a great show. Customers, being unaware of what information security really entails, will see that and think "wow, that's secure !".

  3. Many people in the industry are no less impressionable than average customers. Quite a few "security architects" will see such a system and also think "wow, that's secure !".

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    Is this answer generally valid, or does it refer specifically to the situation where the described check for certain letters from the password is the *only* level of protection? I am asking because I know a banking site that requires a traditional password (presumeably stored in a non-reversible form) *and* certain letters of another password upon every login. – O. R. Mapper Aug 03 '14 at 19:27
  • Sorry but if you have many different passwords (as you should) and change them regularly (as you should) it is hard to see how muscle memory can play a big role in the memorization... – Floris Aug 03 '14 at 20:00
  • 9
    Changing passwords regularly is _not_ a good idea. It is a widespread practice which is detrimental to security, precisely because it is at odds with abilities of users to remember passwords. – Thomas Pornin Aug 03 '14 at 21:04
  • About poor_practice point 1, what if they hash combination of characters already and don't have to do a plain text match? although count=3 is too small and would be susceptible to poor_practice point 3. – TJ- Aug 04 '14 at 06:40
  • 1
    @ThomasPornin already gave an excellent answer. Just wanted to add another reason why this is a horrible idea: How quickly could you remember your password's 3rd, 9th, and 11th character right now? You need to look at the password in plain text! This specific policy just makes it a LOT more likely for people to have to write their passwords down, and/or keep them stored in plaintext somewhere (think gmail, plain text files in their hard drive, Post It, etc). And then, these can get lost, misplaced, or easily stolen. – mjuarez Aug 03 '14 at 17:57
  • It seems like Thomas Pornin already gave this reason. He said, in his answer, `asking for specific letters exercises distinct parts of the brain and is likely to induce dangerous behaviours, i.e. writing down the password`. This answer gives some context, but I do not believe it is a full answer in itself. – trysis Aug 03 '14 at 19:24
  • Correctly salted and hashed it is possible to safely store all three letter combinations instead of needing the password to be in plain text. For an 8 character password this would be 336 combinations, for 20 characters 6,480 - so you might not consider this practical. – David Spillett Aug 04 '14 at 08:21
2

This is very bad practice. Passwords today MUST be hashed to cover the possible loss of the password database. The fact that individual elements of the password can be used for authentication means that a reversible encryption is being used instead of hashing, as TP already indicated. This is bad because if both the database AND the encryption key is stolen, then ALL the passwords are lost. Hashing (with strong passwords) makes this impossible. At least the folks that USE strong passwords are safe if the passwords are hashed.

I believe that the reason that some institutions encrypt instead of hash is that the full password may be needed in the backend for some purpose, such as further authentication. Some sites use the last 4 digits of the password as a "security question" when the help desk is contacted. But this is a horrible reason, and is probably done since the security question approach that most reputable sites use has not yet been implemented.

I have even seen the actual password show up in my email when I have had to request a reset - it is more complicated to implement a password reset via email then request a new password, than just emailing the password! The bottom line is that it is easier to just keep the password encrypted (or even in the clear) and use it for other purposes than to just implement a password reset mechanism to prompt for a new password.

Another reason this is bad is that most folks that care about passwords today just use a password manager. Requiring individual elements of a strong password is error prone and much more difficult that just using a secure password manager.

Finally, in cases where weak passwords are commonly used, encryption with as strong key can be safer than hashing, since weak password hashes can quickly be cracked today. But in this case, hashing AND encrypting is preferred, not just encrypting.

Ken Clubb
  • 183
  • 1
  • 8
  • Correctly salted and hashed it is possible to safely store all three letter combinations instead of needing the password to be in plain text. For an 8 character password this would be 336 combinations, for 20 characters 6,480 - so you might not consider this practical. – David Spillett Aug 04 '14 at 08:22
  • @David: Storing hashes of combinations is of little to no benefit, because it allows a piece-by-piece brute forcing that defeats the purpose of hashing. For example for an 8-random-alphanums token there are 2**48 possibilities to guess, but for a 3-of-8 there are only 2**18 to guess one combo, and then knowing characters 1+2+3 you can break the hash for 1+2+4 (and all other adjacent combinations) trivially. With numbers as small as 2**18 you can't tune the hashing to be hard enough to defend usefully against offline cracking without also seriously degrading the performance of normal login. – bobince Aug 04 '14 at 22:58
  • @bobince: Doesn't guessing one of the parts through brute force still require access to knowledge of the salt and hashing procedure (which would invalidate the single full string encoded that way) or would it make that easier to infer? I'm assuming there is no practical way to guess the salting function+params from knowing that one of the results represents "a@1,b@5,c@8"? Either way it at least stops the password needing to be in plain which is worse. But also either way there are more secure approaches (banks here are moving towards OTP tokens and such) so maybe the point is moot anyway... – David Spillett Aug 05 '14 at 08:14
  • You have to know the hashing procedure whatever way you hash passwords; keeping that a secret would be a weak ‘security by obscurity’ approach. The salt has to be available with the hash to be able to check it so can't be secret. There can be additional secret material going into the hash (“pepper”) but then that material has to be protected just as strongly as a key for reversible encryption. The problem with knowing “a@1, b@5, c@8” is that it is then trivial to brute-force the hash for “2,5,8” (only one letter has to be guessed) and then “1,2,3” and so on to get the whole password. – bobince Aug 05 '14 at 12:48
  • As a first order of estimation the raw math behind the hashes should be used. Assume that the hash algorithm, salt, and pepper are known, as is the hash value. – Ken Clubb Aug 06 '14 at 10:28
  • A good explanation is here:http://security.stackexchange.com/questions/17421/how-to-store-salt . Now, take an extreme case of someone using a password manager and has a 16 character password of 62 letter charset. Possible combinations is 62^16 = 5E28 hashes to check brute force. Split the password into two halves this is 62^8 + 62^8 = 4E14 combinations. At approx 7E11 hashes/sec, first case takes 2E9 years, second takes 9 min to crack. – Ken Clubb Aug 06 '14 at 10:38