Password Security – Don’t hash and don’t salt!

Now the title is a little of gears, but please read through to better understand my contention.

Many of us in security, when coding and simply reading around the internet, are thinking of writing your own password security code; but if you are don’t and here’s why.

  • Unless you have great experience or a PHD in cryptography, good luck
  • So it’s way too easy to make mistakes
  • Others can do it way better than us
  • Core implementations in most or all languages already, and finally
  • Don’t waste your time doing it, solution other problems instead!

I don’t know how many times I’ve witnessed bad code, bad implementations, bad configurations and even worst; total lack of knowledge when it comes to securing passwords.

But if you’re curious, here’s a little background I find interesting, especially after the latest news about password leaks from LinkedIn, Myspace and so many others.

Password Hashing

I’ll keep this very simple. Hashing a password consists in hiding its true identity. So instead of sending a password in clear directly into a database or structured data system, you need to first find a way to make it harder for a malicious user.

Leaving passwords in clear is so 1980’s, but you’d be surprised as to how many times is see this in systems and solutions (in code, in configurations files, etc.).

In its simplest form, hashing is a method of taking data, encrypting it, and creating an unpredictable, irreversible output.

Here are a few basic examples for hashing words using SHA-512:

bonjour

Hash result:

3041edbcdd46190c0acc504ed195f8a90129efcab173a7b9ac4646b92d04cc80005acaa3554f4b1df839eacadc2491cb623bf3aa6f9eb44f6ea8ca005821d25d

bonjour123

Hash result:

e9a45f802b3c463d980da22d5c9c908ebd19aa282cb62fbdbb4ee6178aa72ff4043f388e058a1236ded1c0887255af0b05bcec022c48d65fa8f27e36589f2e98

Thisisalongstringtosimulateacomplexpassword!@#$%

Hash result:

e54a8e244daa447edc49cfb56f79d069276eaf88cdca7f8d9e8f6a70f9b528d25844090a68eb138987ff85fbd303cc5824a9bc0b7ec72ac57a2abeeda112be52

As you can clearly see, the resulting hash is always the same length when using, of course, the same algorithm and function. So whether your password has 10 characters or 25, a hash function will generate a specified length result; such as shown above.

But a potential risk arises with simply hashing passwords. If a malicious user “knows” or finds the single associated hash function; your password security has been most probably breached. How?

Well a malicious user could look up pre generated SHA-512 tables, and eventually find the perfect combination, thus finding the password. Using predefined tables greatly accelerates the process; these are known a “rainbow tables”. If you’re curious on the subject, I highly recommend searching online for this subject as it is an extremely powerful tool.

In this specific case, a malicious user would then look up the hash in hand, and find the corresponding password… for example:

0395f42f1b1f0677510a4ff7dbd886b0f2ba46dd707ee546367d59b22ca0dc815ea18c761b327491eb7b84297d5f12bc1f3f3eaa66fbd0bdcb8b62a099b18cce = bonjo

2b37b6c82f890786a1686f84c7512adc091ab6299cbe6597050e17aa3780dd59111d4552418f2425fdcbe402175baa67d47fd8c0eeaf98164093343cd3d71e1d = bonjou

3041edbcdd46190c0acc504ed195f8a90129efcab173a7b9ac4646b92d04cc80005acaa3554f4b1df839eacadc2491cb623bf3aa6f9eb44f6ea8ca005821d25d = bonjour

Boom. The last sequence is directly one of the strings we had earlier. Having the hash result in hand, the idea is just to compare that hash to other hashes until they match!

Now you’re starting to see that creating a password hash is not the best security for passwords. As such, it becomes interesting to add a bit of flavor in the mix and make things more complicated for malicious users.

Don’t get me wrong, hashes are great to confirm and verify the integrity of a string or password, but isn’t necessarily very secure when it comes to sensitive information; so what if we add a bit of information to our string and hash?

This technique is based on adding a salt. Yes salt! The idea behind salting is that generated hash tables used by malicious users only truly work when each password is hashed the exact same way.

Keeping things very simple, a salt is random information used as an additional input when you’re hashing.

Remember from our examples, if two strings are hashed the same way or if two users have the same password, they’ll have the same hashes! This is not great. So a salt minimizes table attacks by randomizing each hash, of course, making sure that each salt is different for every string or password you want to encrypt.

With this technique, the same strings will have different hashes! Here’s the very general idea using one of our strings:

String = bonjour

Random Salt = yr2016

Then the idea in its simplest form is to add the random salt to the string and then hash them!

bonjour + yr2016 = bonjouryr2016 (now let’s hash the combination) =

db305fde604b14286b8dd9ab88acdb2990a0bd078847075637c5cf8b8be1e656262f5e96c954d65b0784dff6fbcd5e3585ce35137eb9cfd750e4e7ee6be26a6d

Again! This is a very high level to explain the idea of hashing and salting. My goal isn’t to present a PHD in cryptography, but just to give you a sense of what salts do when combined with hashing functions.

Key things to remember here… Securing hashes and salts is key! That’s why you should store this information into separate places, so that even if a malicious user gets all of your hashes, it becomes practically impossible to find the strings or passwords without the salts (especially if every salt is random).

Another example I want to show is using the same password with a different salt solves duplication.

String = bonjour

Random Salt = 2016yr

bonjour + 2016yr = bonjour2016yr (now let’s hash the combination) =

777a1dcdd84bf7d4e11325c05fbb114cccc9760d068fab29fb7dfdc0c95c32f9f5b62471371b028f5e3d1b1bdf7084262b41cbaf65a98ff9de64111c89ee582d

Et voilà! As you can clearly see above, combining a random salt with the same password will always create a different hash; fantastic.

Now to verify that users are entering the right password, you simply compare the result of the inputted string and associated salt, and without ever looking at the password, know that the correct or wrong information has been entered by a user.

Using similar solutions, a malicious user would then have to know many things to attack such as:

  • What are the key requirements for your passwords (complexity, length…)
  • What hashing functions is used for passwords and salts (could be different if you like)
  • What is the process of creation of the hashes
  • Where are hashes and salts stored
  • How are the salts created and so on…

Now, can you see the value?

It becomes very complex for one person to have all this information, code, access, knowledge, etc.

But the point of my article wasn’t to explain the process itself but the potential complexities that come when managing hashes, salts, functions, algorithms and so on. If by any chance you misplace or misuse the concepts above, the solution you provide will never be secure.

So do you understand my point and title now? Use tried and true crypto solutions.

Don’t go bake some half cooked cake and then live the consequences of bad decisions. Cryptography is complex and necessitates years of studying and experience and may greatly vary from one solution to another.

Instead, take the time to search for solutions – depending on the language or solution you’re using. Every platform has great solutions for this, so read, ask questions and always… Have fun doing it.

Leave a Reply

%d bloggers like this: