Password best practice: If someone asks you for random characters, they’re doing it wrong

Time for a rant. I recently rang two financial institutions, who of course need to check that I am the genuine account holder. Which is all good. They both asked for random characters from my password: “Please give me the third and seventh letters”. Which is all bad.

In the first case, I sighed and muttered that this is a bad system. The next time, I tried to explain why it was a bad idea to check identity in this way. In both cases the call handler explained that it’s entirely secure and they can’t see the whole password. Besides, they have security like MFA.

Now, I’m fully aware that the call handler isn’t the person I should be raising this with. So, to get it out of my system and so that in future I can point the call handler to this piece and ask them to send to their internal security team, I am going to rant here.

The first rule of password security is…

The first rule of password is so important that I’m going to type it in all caps. YOU NEVER STORE THE PASSWORD. 

It’s a simple rule, but I can see it’s broken when the call handler asks for random letters from my password. You see, to tell if my offered letters is correct, the system must have stored the password in what we call “the clear”. Clear text is this article, it can be read, there is no encryption or obfuscation. If you can access the record you can read the text. 

In this case, it means that somewhere in the institutions’ databases sits a record with my login name and a password. This is what’s used to let me log in and it is in the clear.

Why shouldn’t you store passwords? Because people reuse passwords. If company A is broken into and the bad guys grab the username and passwords, they try all of them against company B. It’s annoying to get that email saying “we have lost your personal details, so sorry, please go change your passwords”, especially when there is a better way.

At this point you might be thinking along these lines. “Okay, but they have to store the password…. otherwise how can they check that the password is correct?” 

Welcome to the world of authentication and authorisation, something that I have previously written about. 

Authentication and authorisation

Let me explain. There is a mathematical function called a “one way hash” that turns data into a fixed length value. The way it’s done means that it’s practically impossible to reverse. 

To give an example, “Hello” goes into this one way hash function (or hash) and it produces a fixed length output of 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. The hash will always make “Hello” into this same 256-bit output.

However, “hello” won’t produce the same output, because “H” and “h” are different. Using something called the avalanche effect actually means that a tiny change makes a large difference in the output. 

Whilst this looks like encryption, it isn’t. It also doesn’t matter how long the input is: if someone hashed this article, it will still produce a 256-bit output.

Using this you can store a hash of a password, when created, next to the username. When the user tried to login, you take the password given and hash it and then compare the results: if they match then the password inputted is the same as the one originally setup and you can let them into the system. Magic!

You now have a system to let people in and you aren’t storing their passwords.

The downsides of hash functions

The downside of this system are twofold. 

One, you can’t ask over-simplistic questions like “what is the third letter of your password”. The second, as I’m sure you have already thought of, if two people have the same password they get the same hash. Which is true, but that’s also the case if you’re storing the password in clear text.

However, we can improve this situation to make people more secure and ensure the same password has a different hash., This is a process known as adding salt.

At the moment, we have a table in a database with username and a hash to let people log in. But from this point we’re going to add a third item to this list: a salt. 

This can be as simple as a date stamp of when the record was created. Computers store time and dates as the number of seconds since 1 January 1970, so we have this constantly changing number going in the record. When creating the hash, you also use the extra data: for example, Password+DateStamp. This new value is is hashed rather than the password alone.

Every hash is now unique. And even with the same password used multiple times, you can check that the original password matches what has been handed over on login, because you compare PasswordGiven+DateStamp when you make the comparison hash.

Password best practice: Extra salt please

This salting has a secondary benefit. Hashing is time consuming, so if someone did steal our table of usernames and passwords and salts, they still have to try and break every single one separately. If they throw a dictionary at the system to work out the password, they can’t just go “password1” and compare against the whole table. They have to do it with every salt and then move on to “password2”.

This is a simple system that means no passwords can be lost. If the worst happens and you do lose the usernames and passwords, the bad guys can’t easily reverse the system to get them back. In effect, they have to guess the password and try them again and again.

There is no excuse for not implementing this for your usernames and passwords. Next time you’re asked for the letter from your password, you will know that they aren’t using best practice. Feel free to point them to this article.

Rant end. But you’re reading this at your workplace, please forward it on to your security team and ask them to update your systems. Deep breaths. And thank you.