Password Storage Mistakes

Passwords are suppose to be a secure way for authenticating users of a system. 
Every developer must provide a secure and reliable way for storing passwords. There are quiet a number of ways to go about it.

Storing passwords using reversible encryption means that my password may be decrypted. Someone who has access to the application's system and key, may also readily access my password and the thousands of users at this site. One compromise of the key and ALL passwords are toast.




Hashing

So passwords are not to be stored in plain text, they are not to be stored in encrypted form. Well, password can be hashed, Lets review this.

Hashing, which results in a message digest, is a one-way operation. When a hash table is calculated the input is provided and the result is a fixed length output. The SHA-512 algorithm has a 64 bit output, The SHA-256 has a fixed 32 bit output and bcrypt algorithm has a fixed 60 byte output. For each of these algorithms there is an infinite number of potential inputs, but a finite number of potential outputs, this is called collision. Good cryptographic algorithms make it difficult to find collisions.

So by hashing a password, we've solved the password storage problem. But the problem isn't solved yet. People do crack passwords. Unfortunately, while hashing is irreversible, passwords that have been hashed can still be cracked. A number of cracking methods can be used, including brute force, rainbow tables or password dictionaries. During a password attack, looking up hash value in rainbow table is much faster than hashing and comparing each value in the password dictionary.

Salting

Sometimes you need a little something special to make storing passwords better. Lets say I have a password "abcde". This would easily be cracked, any rainbow table or dictionary attack could be used to find this password. but suppose the developers before they hash the password, append a large random string (aka salt). So rather than calculating the hash for abcde, they instead store the large random character string (salt) along with the password. When the application developers decided to use salts when hashing, they effectively made my trivially simple password much more complex and made it very unlikely that someone could crack the password on a pre-computed dictionary attack or through the use of a pre-computed rainbow table. Rather, with a sufficiently large random salt, an attacker must create a separate dictionary or rainbow table for each user's password they are trying to crack. This is extraordinarily expensive and that is why strong salts effectively break dictionary attacks and rainbow tables.

Well there are several other ways for storing passwords. Feel free to explore them.