Salt and passwords [duplicate]

Answer 1

You are using the salt totally incorrectly. Salts should be unpredictable; your salt is the exact opposite of that (fixed). Since a fixed hash is of absolutely no benefit, it also seems that you are counting on the salt not being known by the attacker. This is the definition of security through obscurity, which is another bad practice.

What you should be doing is:

1. Use an unpredictable string of reasonable length as the salt. Randomly generated 8-character strings from a pool such as lower/upper case letters and digits are fine.
2. Use a different salt for each user, and change it every time they change their password.
3. Move from MD5 (which is considered broken) to another hash function better suited to this application. SHA-1 is better because it's not considered broken; bcrypt is the best because it has a configurable load factor.

Answer 2

Salts are meant to be completely random, and unrelated to the actual password you are storing a hash of.

What you should really do is generate a completely random salt, then do

$password = md5($salt.$password);

and store the user's username, salt and hashed password.

Answer 3

You should change the salt so that it is specific to each user, not a system wide constant. This will make rainbow table attacks against your password hashes much more inconvenient.

There is a good write up on the evolution of salting in this article by Troy Hunt.

Edit

$salt something unique to each password record, which adds much entropy to it. This is usually a random sequence of bytes, stored with the user account.

Hashing is traditionally done on the concatenation of salt + password.

$passwordHash = hash($salt.$password);

As others have said, don't use MD5 for hashing. It is broken.

Applying additional proprietary algorithms to password or salt prior to hashing is not recommended. Instead, look at an industry strength solution such as PBKDF2, which, in addition to salting, also requires many (typically > 10k) repeated iterations which will further slow down an attacker.

If you adopt OWASP guidelines, the number of hashes performed should be increased regularly (to counteract Moore's Law). The number of hashes should also be persisted per user, meaning you will need to store the triple of hashed password, salt, and number of iterations.

Answer 4

First of all you should never store md5 directly, which you regognized already. PHP 5.5 will bring new methods to easily create and verify passwords in 1 line, until then you can use https://github.com/ircmaxell/password_compat (forward-compatible) to generate & verify safe password hashes.

Answer 5

1. Don't use MD5 as your hashing algorithm, use something more secure such as SHA256 or even bcrypt.

2. Definately salt the password, if someone did gain entry to your database they would not be able to reverse the passwords for common hashes or using techniques such as rainbow attacks.

http://michaelwright.me/php-password-storage

http://en.wikipedia.org/wiki/Bcrypt

Answer 6

I think salt is understood here incorrectly. The idea of salt is that it should be unique per hash. The reason is that when you create hash some different strings may have the same hash.

In your example you're hashing password too so it won't look like: 145ac26ff093c6e1317f7d5fb4c9fd11c77be975password

P.S. Use bcrypt. It's much more reliable.