I think the best way to have a salt is not to randomly generate one or store a fixed one. Often more than just a password is saved, so use the extra data. Use things like the username, signup date, user ID, anything which is saved in the same table. That way you save on space used by not storing the salt for each user.
Although your method can always be broken if the hacker gets access to your database AND your file, you can make it more difficult. Use different user data depending on random things, the code doesn't need to make sense, just produce the same result each time. For example:
if ((asc(username character 5) > asc(username character 2))
{
if (month the account created > 6)
salt = ddmmyyyy of account created date
else
salt = yyyyddmm of account created date
}
else
{
if (day of account created > 15)
salt = user id * asc(username character 3)
else
salt = user id + asc(username character 1) + asc(username character 4)
}
This wont prevent them from reading passwords when they have both database and file access, but it will confuse them and slow them up without much more processing power required to create a random salt
加密存储模型
SSL/SSH 能保护客户端和服务器端交换的数据，但 SSL/SSH 并不能保护数据库中已有的数据。SSL 只是一个加密网络数据流的协议。
如果攻击者取得了直接访问数据库的许可（绕过 web 服务器），敏感数据就可能暴露或者被滥用，除非数据库自己保护了这些信息。对数据库内的数据加密是减少这类风险的有效途径，但是只有很少的数据库提供这些加密功能。
对于这个问题，有一个简单的解决办法，就是创建自己的加密机制，然后把它用在 PHP 程序内。PHP 有几个扩展库可以完成这个工作，比如说 Mcrypt 和 Mhash 等，它们包含多种加密运算法则。脚本在插入数据库之前先把数据加密，以后提取出来时再解密。有关加密如何工作的例子请参考相关手册。
对某些真正隐蔽的数据，如果不需要以明文的形式存在（即不用显示），可以考虑用散列算法。使用散列算法最常见的例子就是把密码经过 MD5 加密后的散列存进数据库来代替原来的明文密码。参见 crypt() 和 md5()。
add a note
User Contributed Notes
Fairydave at the location of dodo.com.au
12-Feb-2006 10:58
12-Feb-2006 10:58
3M
06-Oct-2005 11:46
06-Oct-2005 11:46
Be smart and simple!
1. Hash a password once on twice! It's sufficient to use SHA-1 twice! (read no.3)
2. Limit the number of log-in trys per ip! This will be a hard hit for online brute force crackers!
3. The comments below that suggest using a SALT whit MD5 ar good as long as the length of the resulting string (password + SALT) is bigger then the output of the hashing algorithm. For example: SHA-1 has an output of 160 bits or 20 ASCII chars. If the password set has 8 chars then the salt would have to be of 12 chars or longer... the longer the better!
The idea here is that by trying to brute force a hash (second) that was computed from another hash (first) from a large string would result in many collisions that will make it impossible to distinguish between them and the first hash of the password!
4. If possible use HMAC for added security! This will prevent sending the same generated hash from a paswrod in the tcp/udp packets... each time the pasword field in tha data packets will contain a different hash (HMAC'ed) but on server side will be decoded to the real hash. For this you will need to design a solution for sending the password needed for HMAC!
blodo at poczta dot fm
07-Jul-2005 05:05
07-Jul-2005 05:05
You could always double hash the password, which might just be the easiest way to prevent a hash table crack which typically can only crack hashes that store about 8 characters in length (from what i know). For an additional amount of security you can always append a random salt, although you will need to store the salt to succesfully recover the password for checking. The code could look like this:
<?php
function createSalt ($charno = 5) {
for ($i = 0; $i < $charno; $i++;) {
$num = rand(48, 122); //This is roughly the ascii readable character range
$salt .= chr($num); //Convert the number to a real character
}
return $salt;
}
$randomsalt = createSalt();
$hash = md5(md5($string_to_hash.$randomsalt));
/* Now append this to your database, but remember to store the salt somewhere too, or else you wont be able to check the password later on */
?>
Easy as pie. Hope this helps.
Chris Ladd
06-Jun-2005 02:41
06-Jun-2005 02:41
Using a hard coded salt will only prevent a dictionary attack on the raw database and only if the attacker hasn't gained access to the file the salt is stored in. The attacker could still use the php login site to run a dictionary attack, since the php would be adding the hard coded salt to the password, md5ing it, and checking if it matches. The only real way to prevent a dictionary attack is to not allow weak passwords. There is no shortcuts in real security.
oguh at gmx dot net
12-May-2005 02:06
12-May-2005 02:06
Better use a random value for the salt and store it seperate in the database for every user.
So it is not possible to see if some users have the same password.
Jim Plush - jiminoc at gmail dot com
18-Mar-2005 05:45
18-Mar-2005 05:45
Another handy trick is to use MD5 with a "salt". Which basically means appending another static string to your $password variable to help prevent against dictionary attacks.
Example:
config.php - KEEP THIS OUTSIDE THE WEBROOT
define("PHP_SALT", "iLov3pHp5");
----------------------------------------------
and when you add your database query you would do:
// storing password hash
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
addslashes($username), md5($password.PHP_SALT));
This way if a user's password is "DOG" it can't be guessed easily because their password gets saved to the DB as the MD5 version of "DOGiLov3pHp5". Last time I checked, that wasn't in the dictionary :)