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

  • 4
    Not one single part of this mechanism is secure.
    – DaveRandom
    Jul 11, 2013 at 8:09
  • 18
    This might be the most stupid authentication scheme I ever saw. You should avoid this site. Jul 11, 2013 at 8:26
  • 4
    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 :) Jul 11, 2013 at 9:56
  • 2
    @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, 2013 at 10:51
  • 2
    This implies that they're storing passwords in plain text.
    – lily
    Jul 11, 2013 at 11:27

7 Answers 7


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.

  • 4
    characters hidden by those blue blocks just killed me
    – Dave Chen
    Jul 11, 2013 at 8:22
  • 9
    Most banks in the UK seem to adopt this — I wonder who is advising them
    – Baumr
    Jul 11, 2013 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, 2013 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, 2013 at 10:32
  • 2
    The passwords are stored in an HSM, not in a reversible software format. See here for an explanation of why you can't do it in software alone.
    – lynks
    Jul 11, 2013 at 10: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.


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

  • Santander also does this - I'm guessing the banks may do this so they can interoperate with Visa?
    – jackweirdy
    Jul 11, 2013 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, 2013 at 12:58

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:

Actual actual reality: nobody cares about his secrets. (Also, I would be hard-pressed to find that wrench for $5.)

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 good1, 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.

  • 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, 2013 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. Jul 11, 2013 at 11:37
  • @lynks Also, I don't see how this could be hone without having some way of retrieving the plaintext. Jul 11, 2013 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, 2013 at 11:41
  • 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, 2013 at 11:49

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!


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?


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.

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