Tag Info

New answers tagged

0

There are two possibilities -- either the attacker has found the actual password, or the attacker has found a hash collision. In the former case, changing the salt is pointless, in the later case it might help. Whether it would help depends largely on whether they found the match by brute forcing the password (starting with "", and ending up with ...


1

Great answers so far, but something that I think should also be mentioned because its not very clear from the article you referenced. The hashing function is run against the salt concatenated along with the password and then the salt is concatenated again with the resulting hash from the function and that string is what is stored in the password database ...


2

The user always submits the actual password to the server and the server stores the salt and hash values. The point of a salt is simply to make sure that if the DB is compromised, an attacker can't try brute forcing all the passwords at once. It also prevents identifying reused passwords. It doesn't matter if the salt becomes public knowledge because it ...


9

When you hash the password the first time (when the user registers), you use a salt and store both the salt and the resulting hash in the database. The second time (when they try to log in again), you use your username to pull the salt and the hash out of the database. You use the salt to hash their password input, and compare the two hashes. You may be ...


3

The salt is stored with the hash, for example in a separate database field or it is tagged onto the end of the hash or the username is used as the salt. The purpose is so that even if two users have the same password, their salts will be different and therefor their hashes will not be the same. This is useful if someone manages to steal the database, they ...


1

It is always a good idea to salt since you don't want a pre-established table against that algorithm to be beneficial in attacking the password. If your password gets compromised because a rainbow table was built against the previous salt, then changing the password wouldn't be effective. You need to choose a new salt in order to render any existing effort ...


2

When you do not salt (or pepper) the password, the password isn't very strong and an attacker obtains the hash, it can be cracked by just looking up the hash in a rainbow table (a precomputed list of the hashes of the most common passwords which can be found online). But when you add some additional data to the password, a precomputed rainbow table is ...


3

Both using a random salt and several hash computations or another delaying strategy (bcrypt, scrypt, whichever) make sense not only for many users, but certainly also for one user. Salt prevents an attacker from trivially entering your hash into Google to get an instant password without even using a tool. A good random salt makes it less likely that you've ...


-1

If I am implementing an application that will only ever be used by one user per database, is there any point in having a randomly generated salt? Yes, salting passwords is always a good idea. It doesn't matter how many users there are. If an attacker gets hold of your database and your hashes are not salted, he has an enormous advantage, because there ...



Top 50 recent answers are included