具有2048位和盐的哈希算法[重复]

Question

This question already has an answer here:

• Password hashing, salt and storage of hashed values 4 answers

How to implement an algorithm for storing and comparing hashes in 2048bits for passwords with random salt for each password with PHP?

EDIT 1:

I guess I was not clear enough in my question. What I mean is that I will not make my encryption algorithm. But how could store a password and salt. Being the random salt for each password. Well, it would not be sensible to store the salt along with the password in the database.

EDIT 2:

That would be a good approach?

1) user enters their password,
2) system generates a hash of the password,
3) system generates a password for this salt (I use time ()?)

Being the random salt, how and where could store the salt to the password? Please, I would not want to store the salt along with the password, because I think this is not so sure.

So after the stored password and the salt of the same when the user logs in, I get the password hashes stored along with the salt and compare it to the hash of the password supplied with the salt saved.

Where to save the salt? This would be a good approach to do this?

</div>

Answer 1

"Well, it would not be sensible to store the salt along with the password in the database."

"Because if my database is compromised and someone has access to this data, it will have the salt for each password with each password. And that is not correct. Well I think I just would not make sense to use a salt and give it to brute force along with the password. Because it would be correct?"

These core assumptions are wrong. The point of a salt is to add a unique element to each password so two identical passwords won't hash to the same hash value. The salt is not secret. I repeat: the salt is not secret. The secret is the password, the salt just adds the uniqueness. An attacker will have to brute-force a password by trying every possible combination of characters and comparing the result to the hash value. If he also knows the salt, he will still have to do exactly that.

If the attacker successfully brute-forced the password "foobar" without salt, he has brute-forced every password "foobar". If you add a unique salt and the attacker successfully brute-forced the password "foobar" + salt, he has only brute-forced that one password. He'll have to attack every other password "foobar" separately, since they all hash to a different value, thanks to the unique salt.

That is the point of a salt. Yes, it would be even better if you could keep the salt secret as well, since then the attacker would have to essentially brute-force a value many times longer. But that's infeasible, since you need access to the salt to confirm the password as well. If you need to have access to the hash and salt, then an attacker who has access to the hash likely also has the same access to the salt. It also does not detract from the security if the attacker has access to the salt.