storing secure encrypted passwords

We recently got news that linkedin password hashes are hacked. Generally common practice in web development is to hash the user password and store the resulted hash string believing that chance of two distinct strings having the same hash string is so low that it’s deemed mathematically impossible but now computers are become so smart and SKYNET type computing power can change the story.



rainbow tables (http://en.wikipedia.org/wiki/Rainbow_table), the mapping function from hash strings to any possible combinations of keyboard characters. With trillions of records in rainbow tables, it takes only 160 seconds to crack the password “Fgpyyih804423” which we presume fairly  safe (http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html).




Finally What should we do ?


1. Avoide storing plain text password always use encrypted hashes.Storing text password is bad practice, infact "bad practice" is an understatement. "Irresponsible" might be more accurate.
Storing passwords in plain text is an embarrassing security breach waiting to happen. 
Reasonable efforts must be made to keep sensitive data secure. Storing passwords in plain-text will clearly violate this, and in turn potentially null any indemnity insurance you have in the event of a breach of security.

1. So create SALT randomly for each HASH string and store it into DB.
2. Avoid MD5 use SHA256 or blowfish algorithms.
3. Use strong algo to generate random key.
4. If you are using private key or something then store it in ENV or in file where no one can access it.

$salt = generate_random_salt()


$my_hash = sha1($salt.$secret);


cracker has no idea what the salt is, there’s no way he can create the right rainbow table to
perform the crack. Even if he does, he would have to specifically build a rainbow table to crack your database which can be time-consuming. Subsequently, to make this even more difficult for the cracker, you can use different salts for each of the password entries in the database.


2. At last, it is recommended (http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html) that generate the initial hash string (the one to be stored in database) by running 1000 iterations of hashing instead of just 1. The extra computing burden on your server is negligible while it will increase the time needed to crack a single password by 1000 times at the cracker’s end. The point is to make the hashing process as slow as possible rather than the other way around. As the cracking usually makes password guesses and trial logins at a much higher paced speed, the slowness will have a much more detrimental effect on the cracker than on your website.

Main Key Areas:

Data storage - Store the passwords far away from where an attacker can get in. 


Encryption - Any encryption technique is a delaying tactic - one the attacker has your data, they will eventually crack your encryption given an infinite amount of time. So mostly you're aiming to slow them down long enough for the rest of the system to discover you've been hacked, alert your users, and give the users time to change passwords or disable accounts.


Key storage - Encryption is only as good as your key storage. If the key is sitting right next
to the encrypted data, then it stands to reason that the attacker doesn't need to break your crypto, they just use the key. 


Intrusion detection - Have a good system in place that has a good chance of raising alarms if you should get hacked. If your password data is compromised, you want to get the word to your users well ahead of any threat.


Audit logging - Have really good records of who did what on the system - particularly in the
vicinity of your passwords.