Salt and passwords

 

Possible Duplicate:
Secure hash and salt for PHP passwords

For my passwords should I use salt like this (the salt will be unique to each user and not stored directly with the password)... 

$salt = sha1(md5("coders gonna code"));
$password = md5($salt.$password);

or would it be okay if I just used: 

$password = md5($password);

because if I used salt, even if the user makes up a bad password like password it won't matter because the salt (in this case) would be 145ac26ff093c6e1317f7d5fb4c9fd11c77be975 so the entry for there password would be 145ac26ff093c6e1317f7d5fb4c9fd11c77be975password which according to http://howsecureismypassword.net/ it would take 3 octodecillion years to crack.... so opinions? Or should I be even worse and go 

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

If the person has gone far enough to get the salt hash, would anything be able to stop then going futher? < More of a statement this last password

To everyone who said I should do it per user... I know, this is just an example.

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.

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:

  • 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.
  • Use a different salt for each user, and change it every time they change their password.
  • 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.

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

  • 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

    链接地址: http://www.djcxy.com/p/21844.html

    上一篇: 密码哈希和PHP中的盐

    下一篇: 盐和密码