A bit more on “3 letters from your password”

(Before you read this: If you don’t know what a “Password hash” is, read up on it. In essence, it is a way to hide the password forever, using a neat algorithm that ensures that “1”, “2”, or “password”, “Password” & “Password1” are all essentially random looking strings that give no clue what the original info was.)

(Also:

Twitter is a wonderful place – you can pick arguments with people the world over, especially renowned experts!

So, last night this happened:

A friend posted his shock at the fact that a UK ISP, for customer verification, simply asks them the password, which means the rep can see the full plaintext password on screen!

Needless to explain that this is a terrible idea – despite the clear disastrous consequences, using the same password everywhere means that once discovered it can be tried on all your online accounts. And so, I commented that the “3 (or 2) letters from your password” is a much better way to do things (explained in my previous blog post.) Which is plainly true.

I got so much flak for this statement. But it gets better! Apparently, hashing those letters so that a trivial SQLi attack can’t reveal them with a trivial bit of decoding is all sorts of wrong, because it isn’t completely bulletproof against an attacker who has total access to the server. Needless to say, I’m arguing with people who should know better, but who apparently haven’t the wit to see that Better is better than nothing at all.

So, what do I propose for storage of the otherwise plaintext password? Quite simple.

We have a limited range of possible characters that someone would put into a second level password. 26 lowercase, 26 uppercase (which are usually converted to lowercase anyway!) and 0-9 for the digits. Even adding in special characters that are keyboard friendly you barely get to 100. So hashing these directly wouldn’t be very useful. So we use what is called a “salt”. A salt is a word, or, better, a complex random string, that is used to add entrophy to what you are hashing. (Entrophy is basically disorder. There are things called “Rainbow tables” that hold the results of millions of hashed passwords, and can look them up rather fast, and since “Password1” is pretty common, it will be in there, along with every other password that has ever been leaked online. “Password1-45ffw*” is far less likely to be in there. The salt is “-45ffw*” in this case.)

So, back to our problem. It seems that InfoSec (Information Security) hasn’t yet caught up with PhySec (Physical Security) in some respects. When a user goes to a safety deposit box, how does the facility stop people trying random keys? Or from opening another person’s box with a stolen key? They use what is called a Guard Key. This is what the guard holds. This is analogous to a salt for the facility – without it, you aren’t getting anywhere.

So, we have a salt for the facility, another for the user (and only the latter is stored in the high-risk database tables!) and a secondary password that is between (say) 7 and 15 characters long. So, take “Password1” as our typical “Has a capital, a number and is over 6 letters” password. We break it into P a s s w o r d 1, and combine with the salts. (You can make the salts more complex, or add other factors into it too – you could get really crazy and daisychain the hashes as salts, and so on. Be warned that most simple ideas have long since been built into password crackers and rainbow tables though!)

The next step is to run the whole lot through a one-way hashing function. In the same way that a clock can say 11.03 every day no matter the date, a hash function can have the same value for more than one file, but a good hashing function will have a huge number (trillions at least) of possible values, and the chance that any two of your rows, or different users, have the same hash should be vanishingly small. (For example, the pretty much broken MD5 has a 32 bit length, so the naive odds of a collision* is 1 in 2^32 -> 4,294,967,296 or 4.2 billion. With modern hardware, that’s simply not enough, so use (a non-broken) Bcrypt function with 64 bits – 2^64 -> 18,446,744,073,709,551,616 (or 4.2 billion x 4.2 billion!) (I’m not going to go into how many rounds used {hashes of the hash!} or the built-in salt inside Bcrypt here – needless to say, it is currently about the best hash function to use as far as I know, and is found on most *nix systems)

The result? A database table with lots of impossible to recover individual letters from that second-level password. Yes, it would take a good half a day to code this. Yes, it would require a little extra CPU to check.

Now, on log-in, much like many banks and on-line applications, or when calling customer support, you would be asked not for your full password, but for 3 characters from it, positions chosen at random (but not adjacent) and on entry, those 3 entries would be hashed in exactly the same way as the original password, and if the result was the same then you would be granted authorisation. For “second level” online authorisation, you have that first password – or you could do it the other way around. Either way, the odds of someone guessing the correct 3 letters is, as I pointed out last time, 26^3 -> 17,576  to 1 – and, of course, you could use the numbers, special characters, or even Unicode, to increase that 26 up to 36+. And 36^3 -> 46,656 to 1.

That’s approximately 17,000 times better than asking what your mother’s maiden name is, which anyone on Facebook (and especially if your mom is on Facebook!) can find out in a few moments. (Security questions are totally rubbish for security, and simply lead to Social Engineering attacks and DOXing. Lie about the answers, which you must do for security, and they are simply another password!)

Other advantages: If someone steals the database through an SQL injection attack, they will have fun working anything out. A keyboard logger will only get the characters used, not the whole password, limiting re-use attacks (and a drop-down selection menu could stop that too). Customer services can’t learn the entire password (unless the customer tells them it – and that’s hard to stop) but it would help. Fishing attacks with cloned websites would be harder to pull off – customers who were fooled would have to enter the 3 letters several times for it to be likely anyone could guess the whole thing to then successfully log-in, and it would also make automated attacks slightly harder. (Yes, of course you would need some form of lock-out penalty, but you need that anyway!) And, best of all, “Password1” becomes an almost tolerable password! It stops the user defeating their own security, as far as possible.

Ok, who out there spotted the “old school” cyptographic attack? Hashing isn’t the only thing in the world that can crack open a password! Back before the days of computers, there were lots of people who wrote and broke ciphers. If you’ve read this far, it is likely you have, too. The Caesar Shift is a simple one, where you bump each character on by, e.g. three. “Hello” becomes “Khoow”. Removing three from each letter reveals the original word. The most famous on the internet, from the “olden days” was ROT13, which shifted it 13 places. Shifting it 13 places again, in either direction, reveals the plaintext.

So, what’s that to do with this? Well, if you use the same salt for the entire database, you would easily be able to determine, from letter frequency analysis, what certain letters were. And by feeding those in again, and making some guesses, you could determine what the weaker passwords were, and large parts of the more secure passwords. This, of course, would be bad. So, we have to use a salt that changes for each person/password, otherwise all our hard work would be trivially undone! In fact, it would also be worth using, although slightly more technically difficult, a different salt for each of our broken-out characters we are hashing. This would prevent someone even taking a guess at a terrible “password” like “aaaaaaaaaa1” from the database table. That’s because, as previously explained, the hashes are all almost completely different, even if only a single character (in this case, the salt) has changed.

Anyway, this all came from that crazy argument on Twitter. Can you imagine explaining all this coherently in chunks of 140 characters? Yes, that was my first mistake…

Comments below, please.

*If you are wondering about the whole “Hash collision” thing:

Imagine you had a simple hashing that only returned any input as a single letter of the alphabet. You can see that although you might not be able to figure out the letter directly, you could try all the letters, and then the numbers, and the capital letters, and you will then find that, because there are only 26 possible results, some inputs give the same outputs. What this means is that if you typed in a long, strong password with lots of special characters, the hash that the computer sees would be a single letter (because you don’t want to be sending a plaintext password, and that plaintext password wouldn’t match the single letter hash anyway) If you knew the result of the hashing for the word “Fish” was the same as that super secure password, you could just type “Fish” at the password prompt, and the hash would match, letting you in with a completely different (weak) password. Indeed, with a single letter hash, that super password, and the weak password Fish would both boil down to the same result as a single character input!

So basically, they are bad.

As an aside, there is a mechanical lock from Master, the Speed Dial. This allows an arbitrary (any length) combination of movements as the passcode. However, it acts as a sort of hash function. As the most trivial example, pushing left 5 or 9 times is the same as pushing left once, left 6 or 10 times is the same as pushing left twice, and so on. It loops after 4 pushes in any one direction. (It is more complex than this though, it’s a clever design) but what this means is that a long and complex code might well be replaced by pushing left once!

2 Comments

  1. Pat on 9 November, 2015 at 1:46 pm

    If an attacker gains access to the system, they have access to the database and the salts. Or even easier, the web site developer may be disgruntled and take/reveal the salts.

    This offers very little protection.

    Security questions (yes, fake answers are recommended) are “just another password” but offer a whole lot more protection than individual characters.



  2. Nigel Tolley on 18 November, 2016 at 11:15 pm

    If an attacker gains access to the server side system, and the salts, then you’ve already lost. They’ve got everything already – breaking the salted passwords just means they can try them elsewhere too.

    Client side hijacking is far more likely in my opinion – millions of barely secured baskets with a few hundred eggs in each, versus a far more secure basket (with, hopefully, professional IDS and staff) that holds perhaps millions of eggs, but only one for each person. Things like wifi power gain analysis (the slight movement of your hands changes the wifi power slightly during text input) can reveal keyboard input from your smart phone without any idea what is shown on the screen. In that case, or if CCTV or good old shoulder surfing were used to monitor the input (as found in so many places now) then the attacker has to repeatedly monitor you to recover the entire password. That, to me, is worth far more than it reducing the time for an attacker to break the individual characters in a secondary auth which still isn’t useful without the other password. Indeed, I would still prefer this over nothing. Remember – it is an extra step, but far better than simply using two passwords (or a security question) that are both exposed entirely and fully each time they are used.

    Yes, an attacker could watch for potentially weeks or months to get the password, but they are more likely to steal the cookie/session from a person if they can’t directly get the entire password trivially. But that, like the server side attacker, isn’t what this is protecting against.



Leave a Comment





*