Say no to plain passwords: Secure Password Hashing

DARMSTADT, Germany - Nov. 17, 2015 - PRLog -- Plaintext passwords should not be used anymore. But be advised: You should not implement password hashing “by hand” if you have no idea what you are doing. Use a proper framework.

Why hashing Passwords?

Simple question, easy answer: Passwords are still the most common authentication attribute for all kinds of applications and the average user tends to reuse “good” passwords. Hence, to protect the confidentiality of your user's passwords, passwords should not be stored in plain but only cryptographically secured. Password hashes are the most simple way to do this. As I said, most software frameworks dealing with passwords take already care of this. Other examples are account passwords used in operating systems like Linux, Windows or mobile systems. Secure hashing has become state-of-the-art.

I heard password hashes are being cracked, how is that possible?

Over the years, crypto experts and system developers have learned from hackers and how they attempt to crack hashes by optimized brute-force-attacks. A brute-force-attack is an attempt to try out all possible input combinations of a certain mathematical function. The attacker compares the result with an expected result. This could, for instance, be an intercepted password hash. If both match the attacker has found the original plain text. How could a password hash be “intercepted”? Hackers attack web applications through all kinds of security holes, so simply imagine an attacker had gained access to a web shop's database backend.

This is why a secure hash function is not enough to create a secure hash in all cases. If you would hash credit card numbers (or IP addresses) without further measures, the input space for the hash function would be very small. Hashing all possible credit card numbers and storing their hashes into a database would be possible. A brute-force-attack to restore the input values from the hash values would be successful. Additionally, there are optimized brute-force-attacks like “rainbow tables” which reduce the necessary computational effort dramatically.

Passwords are also relatively “small”. Moreover, since most passwords chosen by users are based on normal words, dictionary-attacks can be used for optimized brute-force-attacks. A dictionary-attack by the way does not mean that only words from dictionaries or other word collections are directly used but also variations and permutations based on these words. For instance, let's say “cat” is the next word in the list. A clever brute-force-attack would now ran all kinds of permutations against the hash function (this could include 1000s of variations), like “cat1”, “cat2”, “cat1!”, “cat2015”, “c4t” etc.

CrococryptLib

In the context of password hashing, have you ever heard of “salt” and “iteration count”? These terms provide the state-of-the-art of password hashing today. The iteration count is simply said the number of times which the hash function is used on a single password. Your password is not only hashed once, the hash value itself is hashed again and again. If we use an iteration count of 100000, every attacker has to hash all passwords that are being attacked 100000 times which enlarges the computational effort. However, rainbow tables, for instance, reduce the computational effort in these cases as well.

An additional, individual salt per password makes attacks like rainbow tables infeasible. A salt is a long random value that is added to the password each time its hash has to be calculated. In practice, that means an application has to store additional values to create and verify passwords: the iteration count (globally or per password), the salt (per password) and the password hash value. That applies, if a single hash function is used. Otherwise, the hash function has to be stored per password as well.

The iteration count and the length of the salt utilize a secure hash function actually secure!

That being said, how to implement all these attributes for a secure hashing algorithm? The answer: Use a standard implementation!

CrococryptLib (http://www.frankhissen.de/clib) provides the most easiest way to use proper hashing in your own enterprise application. Have a look at the free trial SDK and profit from the professional experience instead of investing custom development time.