Since the introduction of Rainbow tables, and using only hashed passwords (e.x: MD5) to stored passwords in database is not the best secured way.
When people talk about salted hashes, the always use it in this way hash(password . salt)
or even hash(hash(password) . salt)
.
I don't know why to use salt, and add extra entry for each password to store the salt?
Why don't we just use hash(hash(password))
, or even hash(hash(hash(password)))
?
Is it more secure to put salt? or just the sense of being more complex?
If you don't use a salt then an attacker can build a single rainbow table can be used to attack every password in your database. Hashing multiple times does not protect you without a salt, because rainbow tables work by chaining hashes together in exactly the way you describe:
hash(hash(password))
.If you add a random salt for each user then the attacker cannot re-use the same table to crack two passwords so their work becomes much harder. As an added benefit, two users with the same password will hash to different values if a salt is used.
Your idea of iterating the hash is still good, but you need the salt too. If you do this:
then you make the attacker's work 1000 times harder with a negligible effect on legitimate users. Note that attackers can test millions of candidate passwords each second on a single, low-end computer - hash functions are designed to be fast. This 1000 iteration loop can change a feasible attack into one that will take 100 years or more. When computers speed up in 18 months time just change the number of iterations to 2000.
The salt, hashing algorithm and iteration count do not need to be secret and can be stored in your database alongside the computed hash. You can choose a fixed iteration count and hash algorithm, but the salt must be randomly generated for each user.
The salt is a site- or user-specific value. That means that in order to retrieve the passwords, an attacker must have both access to the database AND know the salt.
In addition, the attacker could additionally generate a table once and then use it against multiple sites. However, with salts, attackers must generate one table per site or even once per user(making the attacks slower).
Site-specific salts add very little to the security of a website. As said in comments, having a combination of site-specific and user-specific salts can significantly improve security over just a site-specific salt.
A few years ago I asked here on stackoverflow a question about password storage which might be helpful to you. See Secure hash and salt for PHP passwords.