What’s the best alternative to the Md5 algorithm for PHP for encrypting user data like passwords and other secure data, stored in MySQL databases?
What’s the best alternative to the Md5 algorithm for PHP for encrypting user data
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
What’s the best alternative to the Md5 algorithm for PHP for encrypting user data like passwords and other secure data, stored in MySQL databases?
SHA512 is not a terrible choice. But it won’t be long before it is cracked for most lengths of passwords. Take Jeff’s Advice. Use bcrypt or PBKDF2. They are resistant to EC2 or other parallel processing techniques. Probably not immune, but resistant.
The reason a better hash isn’t better in this case is
ABCin MD5 becomes one value andABCin SHA512 becomes one value. Calculating all the 3 letter passwords is actually easier for SHA512 than it was for MD5. The key is to be hard to do. That means a slow hash, one that uses a lot of RAM, and/or one that can’t be easily done on EC2.The best choice is to NOT use passwords alone anymore at all. Decide if login is really needed for your site, and if it is, try to use a 3rd party provider first. If that’s not an option consider a password + token from RSA. Only use a password alone if you have no other viable options.
When hashing a password the key is to hash(password + salt) and the salt needs to be unique per user, and should also be difficult or impossible to guess. Using the Username meets the first criteria and is better than no salt or the same salt for each user, but a unique random salt for each user is a better choice. Ideally in a separate database, if not location, with its own credentials. It should also be keyed not on the username, but on the user_id or even a hash of the user_id. You want that database to be SQL injection proof. Accepting no input from the user that isn’t hashed is a good way to do that. And you would be wise to let the query itself do the hashing. Slow? Yes, and that’s ALSO a good thing.
The salt itself should contain all the hard to predict data it can get. Username + User Id + Timestamp + garbage from dev/urandom + the latest tweet with the word taco in it. Longer the better. SHA512 is a good choice of hash here.
Summary: hash = bcrypt(password + salt), salt = sha512(username + user_id + timestamp + microtimestamp + dev/urandom bits + other noise).
If you are still worried after all of that. Feel free to SHA512 the bcrypted password. You’ll gain the strength of SHA512, which when cracked only reveals a much harder to brute force bcrypted hash.