(PHP) SHA1 vs md5 vs SHA256: which to use for a PHP login?

Neither. You should use bcrypt The hashes you mention are all optimized to be quick and easy on hardware, and so cracking them share the same qualities. If you have no other choice, at least be sure to use a long salt and re-hash multiple times.

Neither. You should use bcrypt. The hashes you mention are all optimized to be quick and easy on hardware, and so cracking them share the same qualities.

If you have no other choice, at least be sure to use a long salt and re-hash multiple times.

– NMoney Feb 10 '10 at 7:50 2 Yes. I'm referring to SHA1, SHA256 and MD5 and a series of other hashes that are optimized for speed. You don't want to use a hash optimized for speed to secure a password.

There are many good articles discussing why, and I like this one in particular: chargen.matasano. Com/chargen/2007/9/7/… – Johannes Gorset Feb 10 '10 at 7:51 2 It's included in the "crypt" function since PHP 5.3. If you have an earlier version, I'd look into the "phpass" framework for the next best thing. – Johannes Gorset Feb 10 '10 at 8:03 1 @Stanislav Palatnik SHA512 is a good alternative.

Don't get me wrong; I'm not saying a stretched and salted SHA512 hash is insecure. It's secure. Even so, the fact remains that bcrypt is more secure, and so I see no reason not to use it.

– Johannes Gorset 5.3.1 at 6:41.

Use SHA256. It is not perfect, as SHA512 would be ideal for a fast hash, but out of the options, its the definite choice. As per any hashing technology, be sure to salt the hash for added security.As an added note, FRKT, please show me where someone can easily crack a salted SHA256 hash?

I am truly very interested to see this. Important Edit: Moving forward please use bcrypt as a hardened hash. More information can be found here.

Edit on Salting: Use a random number, or random byte stream etc. You can use the unique field of the record in your database as the salt too, this way the salt is different per user.

1 But their optimized for speed, meaning that they enable brute-force hacking. – arbales Feb 10 '10 at 8:07 4 Fact remains, this is to secure a password. By using a hash with a salt, then add a 3 attempt limit on the website, you substantially slow down the hackers attempts (even brute forcers).

Using any pure encryption, you now have another problem - securing the key. If the key is found, your entire database is compromised (if no salt is added). Hashes however, you will never get the original password out of the system, and thats how it should be.

– Kyle Rozendo Feb 10 '10 at 8:11 1 As noted, the problem with the MD and SHA-series is that they are optimized for speed. It is inevietable that hashes of this nature become increasingly insecure as computing evolves. – Johannes Gorset Feb 10 '10 at 8:13 1 Anything becomes increasingly bad/insecure/etc as computing evolves.By the time SHA512 etc. Are hacked, there will be more secure algorithms available.

This is the nature of computing in any case. – Kyle Rozendo Feb 10 '10 at 8:15 1 what is a good way to make a salt in php? Have example code?

I imagine I shouldn't just pick something like 'giraffe' – NMoney Feb 10 '10 at 8:18.

I think using md5 or sha256 or any hash optimized for speed is perfectly fine and am very curious to hear any rebuttle other users might have. Here are my reasons If you allow users to use weak passwords such as God, love, war, peace then no matter the encryption you will still be allowing the user to type in the password not the hash and these passwords are often used first, thus this is NOT going to have anything to do with encryption. If your not using SSL or do not have a certificate then attackers listening to the traffic will be able to pull the password and any attempts at encrypting with javascript or the like is client side and easily cracked and overcome.

Again this is NOT going to have anything to do with data encryption on server side. Brute force attacks will take advantage weak passwords and again because you allow the user to enter the data if you do not have the login limitation of 3 or even a little more then the problem will again NOT have anything to do with data encryption. If your database becomes compromised then most likely everything has been compromised including your hashing techniques no matter how cryptic you've made it.

Again this could be a disgruntled employee XSS attack or sql injection or some other attack that has nothing to do with your password encryption. I do believe you should still encrypt but the only thing I can see the encryption does is prevent people that already have or somehow gained access to the database from just reading out loud the password. If it is someone unauthorized to on the database then you have bigger issues to worry about that's why Sony got took because they thought an encrypted password protected everything including credit card numbers all it does is protect that one field that's it.

The only pure benefit I can see to complex encryptions of passwords in a database is to delay employees or other people that have access to the database from just reading out the passwords. So if it's a small project or something I wouldn't worry to much about security on the server side instead I would worry more about securing anything a client might send to the server such as sql injection, XSS attacks or the plethora of other ways you could be compromised. If someone disagrees I look forward to reading a way that a super encrypted password is a must from the client side.

The reason I wanted to try and make this clear is because too often people believe an encrypted password means they don't have to worry about it being compromised and they quit worrying about securing the website.

As FRKT pointed out, the post by Thomas Ptacek at chargen.matasano. Com explains why simple, general-purpose hashing functions such as MD5, SHA1, SHA256 and SHA512 are poor password hashing choices. Why?

They are too fast--you can calculate 1,000,000 MD5 hashes a second per core with a modern computer, so brute force is feasible against most passwords people use. Salting without key stretching only means that you cannot precompute the rainbow table, you need to build it ad hoc for that specific salt. So the choice for PHP is either Crypt/Blowfish (BCrypt), Crypt/SHA256 or Crypt/SHA512.

Or at least Crypt/MD5 (PHK). See www.php.net/manual/en/function.crypt.php.

Out of this three algorythms the sha256 is way more safer, than the other two. But the good salting is much more important then the good choice of hash method. You should use a fix salt, wich is long enough to prevent its cracking by brute force.

You should also use a random salt, wich can be stored as plain text in the db beside the hashed password. It can be quite short, it's main aim to prevent the attacker to find the common passwords(without random salt their hashes would be the same) and (if the attacker gets the fix salt) to prevent building site specific rainbow tables. Sample code: define('FIX_SALT','DVlDR%UZFdsf%!

GfjSEFsz5ghdf'); (..) $hashed_pass = hash('sha256',FIX_SALT. $plain_pass. $random_salt); $random_salt should be a short random string, and can be stored as a plain text, as I mentioned above.

You shouldn't worry about the good speed of SHA256. There is no way that any attacker can generate even 2^128 hashes, it will be impossible in the next 20 years...

Everyone is talking about this like they can be hacked over the internet. As already stated, limiting attempts makes it impossible to crack a password over the Internet and has nothing to do with the hash. The salt is a must, but the complexity or multiple salts doesn't even matter.

Any salt alone stops the attacker from using a premade rainbow table. A unique salt per user stops the attacker from creating a new rainbow table to use against your entire user base. The security really comes into play when the entire database is compromised and a hacker can then perform 100 million password attempts per second against the md5 hash.

SHA512 is about 10,000 times slower. A complex password with today's power could still take 100 years to bruteforce with md5 and would take 10,000 times as long with SHA512. The salts don't stop a bruteforce at all as they always have to be known, which if the attacker downloaded your database, he probably was in your system anyway.

It is not possible when you don't know anything about the original string. It is possible when it is a password - people use weak passwords, you just have to take a dictionary, and try its words in various combination with each other and numbers, and see if one hashes to the same value. The cryptographic properties of the hash function do not matter for such an attack - the only thing that counts is how fast `md5('some_password_guess)' can be calculated; the faster it is, the more passwords the attacker can try in the same time.

And md5 is very fast. Bcrypt OTOH was designed to be slow. – Tgr May 9 '10 at 7:42 But if I use for example function which was brought up here createSalt() and make it even harder, then it should be ok, doesn't it?

– Eugene May 9 '10 at 8:07 Whoever wrote createSalt() didn't have much idea what he is doing. He is using the high bits of the random number and the uniqid call has no effect; more importantly, the salt is way too short. Most importantly though, salting does not protect you against a bruteforce or dictionary attack; that is not its purpose.

Never mind how hard it is to calculate a hash function backwards, the attacker only has to calculate forwards, and calculating a salted md5 hash is fast. You need to have a hash function that is slow. – Tgr May 9 '10 at 10:31.