I'm using PHP. I want a safe and fast password encryption system. Hashing a password a million times may be safer, but also slower. How to achieve a good balance between speed and safety?
I want to know the best encryption method in php and how to apply it.

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3

Wow, so many awful answers, people saying MD5 is bad without providing a resource explaining why. Encryption is not what hashing is. If you encrypt something, you can decrypt it. Meaning, you can obtain the original text. Point of the hashing is that no one knows what original text was. Every single hashing algorithm is susceptible to rainbow table attack, it's just not feasible for some algorithms since sufficient computing power doesn't exist for that. Also, slower hashing algorithms = good. If it's slow for you, it's slow for the attacker as well. That's what you want.
–
N.B.Jul 9 '13 at 11:21

@Tarik - unless you provide the source explaining that MD5 is broken, please refrain from advising people not to use it. It's absolutely pointless repeating what nearly everyone here so far said, unless you can back your statement with a credible source.
–
N.B.Jul 9 '13 at 11:35

2

Source from Wikipedia: en.wikipedia.org/wiki/MD5#Collision_vulnerabilities :- "In 2005, researchers were able to create pairs of PostScript documents[24] and X.509 certificates[25] with the same hash. Later that year, MD5's designer Ron Rivest wrote, "md5 and sha1 are both clearly broken (in terms of collision-resistance)."[26]"
–
TarikJul 9 '13 at 11:57

Use SHA512 http://php.net/manual/en/function.hash.php.
SHA512 is not cracked. I suggest to use a salt: Some random string that you append to the password before hashing. This can protect against precomputed rainbow tables but not against dictionary attacks if the attacker gains access to the database containing passwords and salts.
SHA512(password + salt) --> hash
Store hash and salt in the DB
When checking password, retrieve salt corresponding to user, concatenate it with password, hash it and compare it with stored hash.
Read here: How long to brute force a salted SHA-512 hash? (salt provided)

Thinking back about your question and particularly about your statement "Hashing a password a million times may be safer, but also slower. How to achieve a good balance between speed and safety". Indeed, repeatedly hashing will protect you against dictionary attacks by making it computationally prohibitively expensive to compute all hashes in a dictionary. I am not teaching you anything here. From the first link I gave you, it took around 46 milliseconds to calculate a SHA512 hash, which is relatively long. Out of hand I can think of the following factors that could influence your decision as you are in an arms race setting:
- Increasing computing power (more CPU cores and GPU computations)
- Improved Algorithms over time
- Amount of money available to the attacker
- The value to get out of your site if cracked (if low, it would not be worth the effort)
against
- Amount of CPU power you have at your disposal
As a rule of thumb, I would hash as many times as possible so as to not impact my web site performance. Taking into account the number of logins per seconds, you can roughly calculate the amount of CPU power you can afford to spend without impacting your site performance.

One last comment: Assuming hackers already have access to the table containing the user names and hashed passwords, you might at that point be more worried about all the bad things they can do on your site.

Yes, indeed, you could use any strong hashing algorithm.
–
TarikJul 9 '13 at 11:34

Exactly. So why advise a specific one if there's tens of algorithms that are slow, big and secure? Why SHA512 and not some other? If you specify that ONE, then what's the reason behind it? Personal preference, it's really good in web environment etc.? Yes, sha512 is great, but there are similar ones. Why limit your answer to 1 algorithm?
–
N.B.Jul 9 '13 at 11:37

I proposed A solution but did not claim that it is THE only solution. When you pointed this out, I immediately acknowledged that you indeed were right. Now, I really have no hidden agenda, preference or any personal benefit from proposing SHA512 over any other algorithm. The most I could do to satisfy your inquiry is to admit that I intellectually neglected to mention alternatives. I guess the purpose of this site is to help, correct each other when we err but not scrutinize peoples' defects and failures, especially when they have the honesty to acknowledge their mistakes.
–
TarikJul 9 '13 at 14:58

I'm not native English speaker so my comments might come off as rude, which isn't my intention. I really thought you had a personal preference or something similar when choosing an algorithm.
–
N.B.Jul 9 '13 at 15:00

MD5 (salt-less) has been used for a while a large number of lookup lists are around, Combined with modern hardware getting 700K + passwords per second it wont take long at all to "reverse" the password.