Best way to encrypt passwords in PHP

[BobMann]

I am curious to what everyone thinks the bast way is.

Code: Select all

$salt1 = 'ds453656p79jufghveot8ahg';
$salt2 = 'ew9rf75nwmhDYLSk5rhb';
hash('sha512', $salt . $string . $salt2)

Any one that still uses md5 deserves to have their data stolen.

[Jackolantern]

The SHAs are good, and usually what I use.

[Elvar]

I do like dis!

Code: Select all

    // Lets generate a salt for the password.
    $salt = rand(0, 10000000) . $user->getUsername() . rand(0, 10000000);
    $salt = hash('sha512', $salt);

    // Hash users password, with our salt.
    $password = hash('sha512', $paramFetcher->get('password') . $salt);

[vitinho444]

I use md5

What kind of encryption should i use then?

[Xaleph]

First of, SHA and MD5 are not encryptions. They are hashes.

Second, Sha family is pretty decent but starting to show its age. MD5 is not really safe anymore. There are plenty of bruteforce and rainbow tables out there to retrieve passwords using md5. Same goes for SHA families.

However, the SHA512 or even the 256 in combination with a random salt and pepper are pretty decent. As long as the salts are randomized and stored seperately. I tend to use the Bcrypt algorithm since i t takes quite a lot of hardware to generate and furthermore, to bruteforce it. Bcrypt is quite strong in combinations with salt and pepper, but you can also look at Mcrypt.

Some pretty strong encryption algorithms are Blowfish, AES(256, 512) or the all famous RSA encryption. But remember, these are encryption algorithms, not hashing algorithms.

[a_bertrand]

You must think about what is exactly the goal. Is the goal to avoid that if the db is hacked all the user passwords are hacked as well? Or is it something a bit different of this?

Now, if the goal is to avoid that the passwords get hacked if the db is hacked, even a MD5 with salts will mostly do the trick. Why? Let me explain the problem from start:
- As long as nobody hacks your DB, you could as well store the password in plain text in the database. Nobody will know it, and beside you, nobody will have access to it. Maybe your customers / players will not be all that pleased to know it, if they ever learn about it, but beside that the issue is a non issue.
- Yet one day, maybe, or maybe never, somebody will have access to your user database, and grab all the passwords. They could then try to log on other popular sites and hope to hack into some of those accounts. That's the main issue of the whole story. So how would you avoid that? Well for example you could store the password encrypted or hashed, such that it is not in plain text within the table and therefore improve the privacy of your players in case the user table is hacked.

What's the difference between encrypted and hashed?
Encryption allows to read back the original data if you know how to do it, and usually know the encryption key. Think about a simple text "aaaaa" where you replace all "a" with "b", you will find "bbbbb" now, to go back, you replace all "b" with "a" and you get back your original text. This is the most simple (and stupid) form of encryption.

Hash on the other side are more or less derived of "CRC" which basically takes an undefined (and potentially unlimited) sized text and produce a fixed size... calculation of it. For example, you sum the dec value of all characters, and then make a modulo 255, and you will have your first CRC. Of course this is a one way process, otherwise you would have found the ultimate compression algorithm, from 10gb to 2 char! It has also the side effect that multiple texts will yield the same CRC. MD5, SHA1, etc are all hash algorithm. More or less complex, delivering more or less bits at the end, but they do share all the same idea: whatever text and whatever size of it you pass to, you will get a fixed size output. Pass 2 times the same text and you will get 2 times the same hash of course.

So why not use encryption instead of hashing for a password? Well it would have the advantage of being able to recover the password in case somebody lost it, yet it would leave the door open to hackers to decrypt the passwords and get access to it. Therefore an hash algorithm is better.

Why MD5 is not secure then as you CANNOT "de-md5" it? Well, cannot is the word... You can actually use what's called a rainbow table, or... brute force it. How does that work? Simply you store on a database all possible passwords, and their MD5, and of course, from there you could search for a pre-calculated MD5 and get back the original value. Or at least one possible value, but that would be enough to hack into the account.

So is SHA-X more secure than MD5? No, if you don't use a salt, all those would have the same security risk, as long as you can build a database big enough to contain most of the possible passwords, then you will be able to decrypt those. Think also that there is a trick called dictionary attack which uses a list of words people most likely use as password, and therefore reduce drastically what needs to be checked.

What is a salt and how does that save us then? Well a salt is nothing more than a piece of text added to the password BEFORE going through the hashing code. That increase the difficulty to make a rainbow table, as you would have to create a rainbow table for all the possible salts. So what should you put there? Could be a static string (not really smart), or something which is like the ID of the user, or something else even stored on a different table. It's up to you. Here the difference is relatively small. You could even do something like hash(salt+hash(password)) or whatever you want to do. Think that at this point, beside using a dictionary attack and or a brute force attack (and you know both the algorithm and the salt used) you cannot find back the password. So is MD5 all that worse? Not really, simply there is many more rainbow tables for MD5 than we have on others algorithm and there is some tricks to reduce the number of trials needed to brute force hack a password saved with MD5. So take something a bit newer even if MD5+salt in most case could do the trick too.

BTW, it's worse nothing that you store the password in a secure way, if after you send the password in plain text over internet while registring and loggin in! Best option would be to use https, poor man solution would be to do the hashing on the browser side via JS and send it pre-hashed... maybe including the IP of the computer calling it.

[vitinho444]

bertrand, you just made my day!
It was worth to read it and i learnt much from your explanation.

I'm building a game, browser based, using PHP and Mysql, now, in the end i will release it as a engine, that you can alter to make your own game, or just pick some code from it to use on your game. The problem is.. the security will be exposed.. what should i do? Maybe not release the engine to the public but only for indie-resource and trusted people?

[a_bertrand]

Security by hiding (which basically means, not share your code / algorithm with the hope to increase the security), is actually not a good practice, nor it gives any real security advantage. Why? Because when you share your code, people are more keen to report your errors and it's easier to find holes. When you hide your code, the only way for people to discover bugs / holes is to actually trying to hack your site. So if you want to share your code as open source, it may result in a better secured code at the end.

BTW you may look at my free version of NWE as basis to give you ideas. Common security issues are SQL injection, XSS, and CSRF. As first security rule you should keep in mind the following sentence: "never trust user input" which on the browser world means, anything coming from the browser, being cookie, post, get or whatever else is to be trusted and therefore must be checked.

[Jackolantern]

The typical way to give out code that has hashing in it is to make setting a custom salt part of the installation process. This is the way most PHP frameworks work. It doesn't really matter if they know you are using SHA512. Once a salt has been added to that, they are pretty much out of luck (I would never say never, but this is the method that works fine for major PHP frameworks and other source-distributed libraries and applications).

[Xaleph]

Betrand, very nice and easy to understand explanation! Love how you took the time to really explain how it works. I ( and with me, others) tend to just call it by name and explain the context, without ever really checking if what we say makes any sense to someone who`s new to this particular field. I hope you dont me copying your text for later refference? Because it truly summarizes exactly what hashing and encryption is, what the best practices are and most importantly, that you should never trust user input.

Really like it.