How to deal with passwords?

It is important to plan meticulously how you deal with passwords in your application. Passwords are one of the most sensitive entities of a system, which can pause major issues if compromised.

First, we must know passwords can be compromised in two ways:

1. Over client side - Various attacks like phishing, etc. can steal the passwords even before they reach the server for processing. Passwords are often passed as plaintext over the network, therefore if an attackers get their hands on these plaintext, they can enter the system and modify resources. But, often these attacks are ignored while securing passwords as the impact is low. Few compromised passwords don’t affect the system significantly.

2. Over the server side - When database storing all the passwords gets compromised, it pauses significant impact on system’s security. Therefore, we usually deal with how to store the passwords, so that even if the DB gets attacked, attackers are not able to retrieve the original passwords.

   

Below are some techniques which helps deal with passwords securely:

• No plaintext, No encryption: Never store passwords in plaintext. Do not encrypt the passwords as it is reversible. If attacker gets hold of the key used for encryption and database, he can easily decrypt them.

  

• Always hash the passwords: Use hashing techniques to convert your passwords in hash strings. This process is irreversible, so your system only remembers the hash and not the original password. When password needs to be verified during login, it recalculates the hash using the password entered by user and match it with hash stored in DB. This way, even if attacker hacks the DB, he won’t be able to extract password from it which is actually needed to login a system.

  

Hashing alone is not sufficient. Rainbow tables are the problem. These tables consists of hashes of some popular and common passwords. Hashses are precomputed so all attacker has to do is to search these hashes in compromised DB. This way, if a DB gets attacked, all the weak passwords gets hacked and these are a lot in practice.

• Use a salt: Salt is an extra ingredient to your hashing technique. Salts are added with the passwords to make them less common and then hashed to store in DB. Example, “abc” is common but “abc69b238cb9f1d3844942d9b30e0a131ae” is not. Always use unique salt for each password and DO NOT use common salts like username, etc. You can store these salts with hashes in the DB.

  

Salts avoid rainbow table attacks, as now size of rainbow table increases significantly. Lets say there are n common hashes and 16 bit salt (2^16 possible salts) - imagine generating n * 2^16 hashes, practically infeasbile as their can be millions of leaked passwords(n). There will be 2^16 possible hashes for a single password.

But what if attacker combines rainbow table with brute force, target a user, get the salt from DB and generate the rainbow table using the targeted salt. To avoid this we need to make rainbow table precomputation infeasible.

• Always use slow hashing algorithm: For hashing, slower the algorithm, more secure it will be. Avoid using MD5, SHA, etc. algorithms, use bcrypt, argon2, scrypt, PBKDF2, etc. instead. This makes precomputation of hashes harder.

• Stretching: It is process of hashing a password repetitively for a number of times making the algorithm even more slower.

• Use an existing algorithm rather than trying to reinvent the wheel, these algorithms are widely used and more secure.

Above techniques make it infeasible for an attacker to hack the passwords with precomputed rainbow tables or precompute the table himself.

Rainbow Tables

OWASP Cheatsheet