Taking password letters not whole one, is this secure?

Question

I found a site which is taking password letters from their users not the whole password. screenshot

Is this secure? Or do they have saved password as salted hash (MD5)?

This might be the most stupid authentication scheme I ever saw. You should avoid this site. — Denys Séguret, Jul 11 '13 at 08:26
Is this the normal login form? Even if it isn't, there's no excuse. — , Jul 11 '13 at 08:26
Any link to the page in question? I'd like to see what exactly their HTML / JavaScript looks like, there are probably more insecurities waiting under the "hood". — , Jul 11 '13 at 08:39
@DaveChen No, it will appear after taking username then redirected to this screen — Ahsan, Jul 11 '13 at 09:35
Normally sites like the ones displayed will use multiple layers, like a user ID, then a password which you type in full, then a secondary password that you type partial which is very secure if its just one layer then its not secure - but they could have additional security questions when you get it wrong, which might make it a little more secure than displayed. Depends on what its protecting really :) — Simon Hayter, Jul 11 '13 at 09:56
@PeeHaa this is perfectly reasonable practice. The *only* problem here is a shoulder-surfer gets the password length. This is very common practice for bank web portals around the world. — lynks, Jul 11 '13 at 10:43
Well... as it was presented in the Q. The possible attacker would know the length of the password and the location of the characters to "guess" (if it is only a username before that). Thanks for the HSM link btw. — PeeHaa, Jul 11 '13 at 10:48
@PeeHaa there is a trade-off, as always. Now you only have to 'brute-force a subset of the password, but in reality, keyloggers are a much bigger threat, which is what this mechanism is designed to counter. — lynks, Jul 11 '13 at 10:51
This reminded me of the following challenge https://projecteuler.net/problem=79 — HamZa, Jul 11 '13 at 12:58
This is not secure of course. Only logical explanation could be that they get your password via HTTP instead of HTTPS which causes other lots of security issues... — ibrahim, Jul 12 '13 at 12:22

PeeHaa · Accepted Answer · 2013-07-12T12:43:39.577

20

This is just really terrible. The only way this can work is if they encrypt your password instead of hashing it. Or even worse just store it as plain text. I would never sign up for that service ever. <update>As @lynks stated the above is probably not true when using HMS. However if only a username is asked before this step. And the password is a fixed password of the user the rest of my answer should still stand.</update>

Also the fact that you only have to guess 4 characters (instead an entire password) is just stupid. Also those blocks may indicate the length of the password which is also really crap (if that indeed is the case).

Not only that, but they also show you on what place the characters should be added which is even more stupid, because you can now make better guessing of the characters being used based on the distribution of characters in words / sentences.

All in all what you have there is mega crap and should not be used... ever. I would go as far as saying that the person who tought this would be a good idea should stop doing stuff like this and start looking for another job.

In fact it is so bad it wouldn't surprise me if the actual characters that are hidden by those blue blocks are just hidden and stored in the source of the page ;-)

As a side note based on the last paragraph of your question:

or do they have saved password in salted hash (MD5)?

MD5 should never be used for hashing passwords. It is waaaaay too fast for that purpose.

edited Jul 12 '13 at 12:43

answered Jul 11 '13 at 08:09

PeeHaa

599
1
4
15

4

`characters hidden by those blue blocks` just killed me – Jul 11 '13 at 08:22
Would you believe its on a BANK site ;) – Ahsan Jul 11 '13 at 08:23
9

**Most banks in the UK seem to adopt this** — I wonder who is advising them – Baumr Jul 11 '13 at 10:07
8

No - most banks in the UK require you **full** password, then ask for selected characters from a secret word. That's different, and constitutes *good* security practice. – Polynomial Jul 11 '13 at 10:13
4

@Polynomial not all, NatWest for example asks characters x, y and z from password and digits n, m and o from a separate pin. The idea is to stop key loggers getting the pass, but it is total fail for multiple reasons. 1) it doesn't take many logs to piece together most or the whole of the pass, 2) even using black box hardware storage, the pass needs to be either encrypted, plaintext or individual characters hashed. How long does it take to generate hash for all characters of 7 bit ANSI at 2.75 million sha1 hashes a second? – ewanm89 Jul 11 '13 at 10:32
2

The passwords are stored in an HSM, not in a reversible software format. See [here](http://security.stackexchange.com/a/34688/9377) for an explanation of why you can't do it in software alone. – lynks Jul 11 '13 at 10:43
1

@lynks, and you can guarantee 100% that there is no physical way to extract them. In fact, my experience of these things is that the manufacturers keep it secret how they actually store the data. However the point of the system is to stop keylogger getting password fails anyway, one just has to log multiple login attempts. – ewanm89 Jul 11 '13 at 10:57
Whats wrong with md5 hashing? passwords should be hashed in the database.. To the next main point, with todays mobile technology, do you really want people to see you typing the pass when you are on the train or bus? It is okay to display the password length (it might not be the real one anyway, which would confuse the hacker). You dont see the point of the square placements, they might change frequently, making the brute force harder. It depends on the frequency of the change and the randomness of the change. – BlackFire27 Jul 11 '13 at 10:57
2

@ewanm89 there are various technologies in place to prevent forensic reverse engineering of secure hardware, generally including *zeroing* secrets when a tamper attempt is detected. @BlackFire27 MD5 is a secure hash algorithm, and is designed to be fast. It has no place as a password storage format. Instead, one should opt for a slow mechanism such as `bcrypt`, or `scrypt` if you are worried about GPU attacks. – lynks Jul 11 '13 at 11:01
1

@lynks Yet you still have failed to show it is any better than crypto at stopping keylogging attacks, which is what such systems banks are using pretend to do. – ewanm89 Jul 11 '13 at 11:06
1

@ewanm89 I'm not sure I follow you. Neither "crypto" or HSM's "stop keylogging" they provide storage of cryptographic material. This is useful in this case because it allows decryption of the user's passwords within the HSM under a private key that is never known. – lynks Jul 11 '13 at 11:11
1

@lynks HSM is one part of a system as a whole. asking for individual characters to stop keylogging, then having to use a HSM as it's the only maybe secure method to store the password so it can still be broken into individual parts, I have nothing against HSMs in general. What I am against is using one as the only means of any defence to fix another problem and failing to fix that original problem anyway. – ewanm89 Jul 11 '13 at 12:05
@BlackFire27 MD5 is too fast to safely store passwords. Brute force attacks can and do break a large fraction of leaked MD5 passwords in a very short time. – Dan Is Fiddling By Firelight Jul 11 '13 at 13:39
@BlackFire27 There's a great writeup of why MD5 is inferior for password hashing at [How to securely hash passwords?](http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) – apsillers Jul 11 '13 at 14:01

score 13 · Answer 2 · edited Sep 01 '15 at 11:43

As others have pointed out making use of a "type character x and y from your password" mechanism requires that the passwords are stored on the server either in the clear or in a reversibly encrypted format (there is the other option of hashing every pair of characters but that would be a daft idea).

Whether this mechanism improves or decreases the overall security of the solution depends on prevalence and severity of the attacks that each approach works well against and also security controls in place on the server side storage of the passwords.

It's likely that there are more instances of keylogging software (this is very common in banking trojans for example) than there are instances of password databases being hacked, but this leaves aside the concept of impact where one password database breach is much more serious than an individual keylogging instance on a customer.

That leads on to controls. Several of the answers and their attendant comments have made the point about HSM. Where this kind of scenario is in use in a UK bank I'd think it extremely likely that an HSM is in use and, hopefully, well managed.

It's unfortunate that the truism of security "only store passwords in hashed formats, reversible encryption is bad" often misses the add-on "well you can store them in reversible format but key management is a bugger".

It is possible to do this securely and indeed the ATM network in the UK used to use (and may still I guess) symmetric encryption for all it's data transfers, but the key management round this was extensive (at least in the cases I looked at) and involved things like dual control of keys.

so the answer to the question is, like a lot of things in security, that it depends. It may be secure and indeed this approach is better in some scenarios that hashing and asking for the whole password, but it depends on a number of factors that can't be assessed without more information.

Mars Robertson · Answer 3 · 2013-07-20T09:40:34.327

7

First Direct - is using this way of requesting password. In some other cases - Halifax, Lloyds - after presenting password prompt there are letters are requested via dropdown. On top of that login has 5 random digits appended.

Verified by Visa - http://www.visaeurope.com/en/cardholders/verified_by_visa.aspx - also uses this form of confirmation when paying by card online.

I believe this is to prevent key-loggers from obtaining the whole password. I believe banks and Visa have their own very strict policies making the whole system reasonably secure.

(at the end of the day it is us who are paying for all their security breaches)

@Hyp's comment is right (updated my answer). Lloyds and Halifax after password have this: enter image description here

edited Jul 20 '13 at 09:40

answered Jul 11 '13 at 11:04

Mars Robertson

555
4
14

Santander also does this - I'm guessing the banks may do this so they can interoperate with Visa? – jackweirdy Jul 11 '13 at 11:25
1

I'm not sure about the rest but I know that Lloyds require the full password first and then some characters from the "pin". It's absolutely different to a 1-stage process. – hyp Jul 11 '13 at 12:58

score 4 · Answer 4 · edited Mar 27 '18 at 16:37

4

Is this secure?

No, this is not secure. This is much more easily brute forced than the full password. However, note that usually there are IP blocks on brute forcing, so it's usually not the best way to get access to someone's account.

This is in place to prevent keylogging, which is in reality a much greater threat than brute forcing. It's a situation similar to this:

Even brute forcing a 4-character subset of a password is hard (I assume that they shuffle the boxes on refresh, this adds some more complexity). There still are at least 26^4 passwords that can be tried out (and with a CAPTCHA and all, it could be tough). Of course, given that the total length is exposed, dictionary attacks may become viable. But there still are a lot of phrases to try, and we're assuming that the IP doesn't get blocked in that time. Another attack that could be made on this system is to log the 4-key password snippet that is typed in, and then keep refreshing the page until the same box order is received. Or they can just match up the password snippet against a dictionary, you'd get a very small set of words.

The more serious issue here is that they're storing passwords in plaintext. It would not be too hard for a sysad or someone with read only database access (there ought to be enough such people) to extract the password and use it to make something that looks like a legit transfer done online). A secure system would hash the passwords (SHA-256 or SHA-512 is good¹, don't use MD5) with a salt, and promptly forget the plaintexts. They should compare the hashes on receiving a password. Of course, in this case you can't do any gymnastics with the password form.

There are much saner ways of preventing keyloggers. Many banks implement a "virtual keyboard", which has randomly-distributed keys on it. Eventually, this can be "logged" too (Something akin to a screencap can be done), however text keyloggers are pretty helpless here as the user doesn't type. (Usually the option to type is given, but the user can use the virtual keyboard if s/he wishes to enter their password in a cyber cafe or other public computer). As mentioned in the comments, this is not a good investment of time for many reasons, instead, use 2 factor authentication:

2 factor authentication is probably one of the most secure ways to get past keyloggers. Those time-based key fobs or the "confirmation code has been sent to you by SMS" would be quite effective as the password is near worthless (useful for account recovery though) without the associated device.

^{1. A better idea would be to use an HSM with RSA and encrypt the passwords. Or use bcrypt or a similar slow algorithm.}

edited Mar 27 '18 at 16:37

Benoit Esnard

13,942
7
65
65

answered Jul 11 '13 at 11:25

Manishearth

8,237
5
34
56

2

SHA-256 and SHA512 are no better than MD5, and systems like this are unlikely to be implemented without an HSM. If they care enough about security to implement something like this, then they have probably researched how to do it (we hope). – lynks Jul 11 '13 at 11:33
@lynks Hadn't thought of HSMs. Good point. Why is SHA "no better than" MD5? Sure, it's not foolproof, but it's no MD5 either. – Manishearth Jul 11 '13 at 11:37
@lynks Also, I don't see how this could be hone without having some way of retrieving the plaintext. – Manishearth Jul 11 '13 at 11:38
3

So the SHA family is designed to be fast. They are great for indexing and lookups for that reason. Password hashing needs to be *slow*, like maxed-out CPU for 3 seconds kind of slow. This makes brute-forcing prohibitively expensive even if the attacker has access to a full database of hashes. Password hashing should be done with something like `bcrypt`, `PBKDF2` or `scrypt`. – lynks Jul 11 '13 at 11:41
An HSM is able to store a private key, perform decryptions internally, and even perform some arbitrary computations. All without ever revealing the private key or the plaintext. The database stores the passwords, encrypted under a public key. To check a password, you feed the encrypted version and the letters to the HSM, and it spits back a yes or a no. This process can be made to be slow also. The point is, nobody ever knows the plaintext password - nobody ever even knows the private key! – lynks Jul 11 '13 at 11:43
1

Bank with a sensible approach to security will not use cheap tricks such as the one described by the OP or even that virtual keyboard of yours (which seems a spectacularly bad investment of time and money to me). They use a proper 2-factor authentication system including a challenge-response component to mitigate replay attacks. – Stephane Jul 11 '13 at 11:49
@stephane good point, I'll add that. – Manishearth Jul 11 '13 at 12:24
@lynks I know what an HSM is. I see, you're individually checking the hash of each letter. Isn't storing individual letter hashes just as bad? – Manishearth Jul 11 '13 at 12:27
On second thoughts, you could have a randomly generated salt for each user, and salt their letters with that. That could work. – Manishearth Jul 11 '13 at 12:28
@Stephane Why would a virtual keyboard be a bad invetment of time and money? They're easy to make, and not that easy to log. I agree that 2factor auth is better, though, – Manishearth Jul 11 '13 at 12:32
@lynks oh, no denying that bcrypt is better. I got confused when you mentioned that it was just as bad as md5. – Manishearth Jul 11 '13 at 12:32
@Manishearth Many reasons: first they are actually not that cheap to implement and you have to add the cost for the user (lost of time using them). Second, they are trivially easy to break. Third, they mitigate the wrong problem: once the client has been compromised, no security mechanism built into the client will help you. Fourth, once your password has been stolen, they offer no protection at all. Fifth, they make the use of reasonable password management technique harder for the user, actually encouraging the use of weak passwords. I'll stop there, but that's only a start. – Stephane Jul 11 '13 at 13:03
@stephane I see what you mean now ... – Manishearth Jul 11 '13 at 13:08
One thing though: in my experience, 2factor (sms based or fob based) takes just as long as a virtual keypad for the user. Ymmv – Manishearth Jul 11 '13 at 13:11
@Manishearth That is correct, but at least the do really add some security to the setup: that is time well invested. – Stephane Jul 12 '13 at 12:59

score 2 · Answer 5 · answered Jul 11 '13 at 10:51

There is such a way of password making/encryption it is called concealment cipher. That is when you have a message inside a message. But this is not it. I think it is meant to be secure in terms of privacy, so there is no one looking behind your shoulder or there is no bot trying to brute force the password..because the places of letters of the password would always change..hmm.. Need a more complete picture on how easy it is to brute force that password.

Does the challenge ,the letter placements, change often, how random is the challenge change?

Does the password mechanism requires you a strong password? with alphanumeric/non-alphanumeric letters, long enough and not containing a word from the dictionary?

Does the password mechanism allows maximum times of attempts?

That is a nice password way to be more secure in my opinion, because if it is random enough with its challenges and allows minimum times of attempts per a given time, then it should be considered as more safe compare to the regular password field we see today on all other sites!

score 1 · Answer 6 · answered Jul 11 '13 at 08:23

Is this secure?

Probably not. Or better said: Most likely not. It seems that some folks have went to town on doing it very secure (tm) this time. And as it happens so often when running your own shoppe alone: You fail.

Or do they have saved password in salted hash (MD5)?

Well, I can not see into their code, but by the level of "cleverness" (irony intended) they show with their user-interface, they most likely have created an MD5 hash of every single character of the password. Yeah, good joke in the morning, right?

But what puzzles me more is that you're really concerned about security here. Look at that user-interface. Isn't it totally awkward for a user to deal with? Right? So now think twice: I which state of mind do those folks need to be to a) suggest that and b) get it through all processing until production. Rest assured that when your UI has such big deficiencies, the security is most likely a total joke as well.

Okay, what is wrong here? The benefit the creator of that form thinks to be is that never the whole password is transferred over the wire. Instead only a part of the password is transferred. So when an attacker eavesdrops the transfer of the password, the attacker couldn't get the whole password at once but would need to collect many login-ins with the same password to then build the whole one.

The problem with this is that it's not the right method to protect against eavesdroping. Instead a secure connection should be used.

If now the bank has introduced this because they think their connection is not secure any longer, well then they need to close the login until they have fixed that.

Additionally it shows a very common misconception about security. It needs to be useable otherwise you will shoot into your foot. Here customers of that bank are trained to use passwords they can read out loud so that they can say which letter is at which position.

Taken the length of that password and knowing a little about the user while having a good dictionary should make it really simple to guess those 4 letters asked for because the length of the password has already been provided to an attacker for free.

Next to that for this pattern to work, a username must have been provided already before the password form can be shown. This means that such a system can be easily exploited to test usernames first.

Why not contact the authorities that are responsible to regulate this banking-house that you have good reason to believe that this bank does frivolous handling of customer data and money in electronic transactions over the internet?

score 1 · Answer 7 · answered Jul 11 '13 at 13:41

I don't see why asking for only certain letters from a password is inherently bad practice.

Sure, if a hacker only has to know 3 of the 10 letters in your password, a "brute force" approach has more chance of succeeding. But that may be a small price to pay for other benefits.

So far as I know, all UK telephone banking systems do this. And it seems pretty obvious to me that's so the bank's own telephone staff never see the entire password. I'd guess that means the server holding that password can be set up more securely, since it never has to reveal the whole password to anyone.

Taking password letters not whole one, is this secure?

7 Answers7

Linked