This week, we saw a Russian blackhat hacker post 6.5 million LinkedIn password hashes on a forum. It has led to a few questionable apps like LeakedIn.org, which takes users credentials and tells if you are a victim of this attack. Observing the hack’s disclosure highlights the fact that LinkedIn stored passwords using the SHA-1 encryption that comes with SSL and TLS protocols. What does this mean? Let’s see an example:
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
If you observe the above table, the passwords of User1 and User3 have similar hashes. This clearly informs hackers that these must be common words which can be cracked using dictionary attacks, brute-forcing, lookup tables or rainbow tables. This means that even if a rainbow table does not have our actual password, it retains a matching hash value which is sufficient to compromise the account. This is the most fundamental aspect of challenge response authentication, which any developer should implement. It’s strange that the LinkedIn Team missed this aspect of password security.
We will now look into the possible solutions available for such systems, as well as aspects that a developer should understand when developing a relatively secure challenge response system.
Are hashes enough to store passwords?
Usernames and passwords from the login form must be stored safely in the database. Storing passwords in clear text are lethal. Storing hashes of passwords would make life relatively happier for users, but is that enough?
As we have seen in the LinkedIn attacks, passwords that were thought to be hashed could be easily cracked using readily available lookup tables or rainbow tables. There are methodologies that developers can implement to make password storage more secure and make it difficult for the attacker to crack.
Salting of hashes
In the above scenario, the password was stored using only SHA-1 hash, and they were unsalted hashes. This means that more than one user can have similar unsalted hashes. Lookup tables and Rainbow tables can be readily used against them.
The concept of salting is simple. Salting is a process of adding salt (like a random integer, string or alphanumeric) to your password before computing the hash. This ensures randomness in the final hashed password.
During its storage in the database, the salt should be stored with the corresponding salted hash. This ensures that attackers don’t use the readily available tools. It challenges them (hackers) to write a more complicated and time consuming piece of code. He is very likely avoid this target and look for an easier alternative to breach.
In the above table, the password remains the same. However, the salt value is random, which in turn makes the hashes unique. So, this renders lookup tables and rainbow tables useless.
Possible errors in salting hashes
Typically, the errors in salting hashes are:
- Use of same salt value for all passwords
- Use of very short salts
The first approach’s issue is that attackers have to create a new lookup table to crack all salted hashes. The latter approach means that a large collection with millions of passwords has a set of passwords associated for each salt. It’s always better to have random salts generated using specific algorithms than rely on system defined random functions.
Tip: The length of the salt should be as long as the length of the output hash.
Since the system uses salted hashes, sending password reminders to the user in case he/she forgets the password is out of question. The only way to reset passwords is to send a rest link and create a new salt for each changed password. Thus the authentication system can be made more secure.
A salted authentication system can be cracked using a brute force attack. However, a strong salt with a strong hashing function can make cracking using brute force algorithms a nightmare for attackers.
Make attacks difficult with key stretching
Even if the attacker uses dictionary attacks and brute force on the salted hashes, life can be still made difficult for attackers, using a concept called key stretching. This technique makes relatively weak passwords (referred as key) difficult to crack using brute force attacks by increasing the time taken to crack each case. The final result is termed as the enhanced key. This should be at least 128 bit long to make brute-forcing the least feasible form of attack. A common technique in key stretching is to apply a cryptographic hash function or a block cipher function repeatedly using a loop.
Many a time, Web developers neglect fundamental aspects of authentication systems, which can have lethal effect on the life of common users. It’s the responsibility of vendors to provide maximum security to common users. At the end of the day, every organization’s success is its user base. It’s our utmost responsibility to keep them safe and secure against such malicious attacks.
- Keystretching - https://secure.wikimedia.org/wikipedia/en/wiki/Key_stretching
- An Article By Defuse Cyber Security on Crackstation.net