Enough protection for storing passwords?

[zid]

Hi, running my page at a hosting provider that does not support PHP 5.5 so I cannot use the new hashing feature.

As of now Im using sha256 with a pretty long and complex salt, the salt is the same for every user which is not the best approach I know but this is for a hoppy project of mine, but still some sort of security thinking in the correct direction.

 

The salt is not stored within the database, its just stored in a variable in a PHP file.

 

Is this sufficient? If my database get hacked they don't get the salt. They have to hack the server itself to be able to get the PHP file containing this salt.

[trq]

https://github.com/ircmaxell/password_compat

[Ch0cu3r]

Is this sufficient? If my database get hacked they don't get the salt. They have to hack the server itself to be able to get the PHP file containing this salt.

They wont need the salt, they'll just spam your login form.

[ttocskcaj]

This package is quite good for hashing passwords and checking them.

http://www.openwall.com/phpass/

[Jacques1]

Hi,

 

trq's answer is the correct one, but I think there are couple of dangerous misconceptions which should be cleared up.

 

Using SHA-256 to hash passwords is completely and utterly wrong. It's so sad that everybody perpetuates this myth of SHA-2 being the “good” algorithm while MD5 is the “bad” one. Both are just as bad for this task. The brute-force tool oclHashcat can calculate 1.5 billion SHA-256 hashes per second on an old gamer PC. That means trying out every single alphanumeric password (lowercase and uppercase) with a length between 6 and 8 characters takes less than 2 days. By then, pretty much all passwords should be broken. And this is only the computing power of some script kiddie. A professional attacker could buy an ASIC for a few hundred dollars and get hundreds of billions of hashes per second.

 

It's easy to see that using a general-purpose hash algorithm like MD5 or SHA-2 is simply pointless given the performance of current hardware. None of those algorithms was ever meant for hashing passwords. They're designed for digital signatures, which means they need to run very efficiently on very poor hardware like smartcards. When dealing with passwords, efficiency is the last thing you want, because this only helps the attacker.

 

A single value which gets mixed into all passwords is not a salt at all. The whole purpose of a salt is to be globally unique so that each hash must be attacked separately. When you only have one value for all hashes, you defeat that purpose entirely.

 

So all you got is the “secrecy” of your constant value. But how secret is it really? It's right in your application, readable by the webserver. What makes you so sure that an attacker who just broke into your database is unable to get the string? I wouldn't bet on that.

 

Given those two major mistakes, I strong, strongly recommend that you keep away from any home-made hashing scheme. There are proven solutions which actually work and don't depend on questionable assumptions.

 

The current de-facto standard is the bcrypt algorithm. It was specifically designed to be computationally expensive and has a variable “cost factor” which can be increased as hardware becomes better. There are no secret values involved apart from the password itself. Even if an attacker knows everything about your system, they still haven't gained anything with regard to the hashes.

 

So, yes, the password_compat library is the way to go if you don't have PHP 5.5 yet. Note, however, that you need at least PHP 5.3.7, because previous versions have a critical bug in the bcrypt implementation. Besides password_compat, there's also PHPass, but it's somewhat obsolete.