New answers tagged

0

Out in the wild we have a users table. A users table is usually ID | username | salt | encrypted_password | horridly_insecure_reset_key =========================================================================== 1 | user1 | foo | 09b6d39aa22fcb8698687e1af09a3af9 | NULL 2 | user2 | bar | 6c07c60f4b02c644ea1037575eb40005 | ...


1

To answer the question you specifically asked...No, hashing the Int32 value to use as the salt is not significantly stronger than using the Int32 directly. It would, as you already suspect, be more obscurity than security. As Martin pointed out in his answer, the key property of a salt is that it be globally unique. You do not get this property with ...


1

What does salting give you? Attackers have pre-calculated databases of hash values for passwords, common and not. If they capture your database and have the hash of the passwords for every user, it's simple to check their hashes against those values without a salt. With a random salt that is stored along with the password, this insanely quick method is no ...


0

There seems to be some merit in the idea of not storing some controlled number of bits of the salt, which is independently configured and is independent of the salt size. Suppose we have 32 bit salts. We could choose to store only 22 bits, and brute-force through the remaining 10 when we authenticate. The effect of this is as if more rounds were added to ...


3

You could use the salt in this way. It would be a sort of hash-stretching process. Typically you stretch a hash by repeating the algorithm several thousand times, which slows attackers and users by 1000fold, but users typically don't mind the slowdown. Using a salt in this way would have the effect of doing a hash stretching algorithm by having to repeat ...


2

Rather than thinking of salt in terms of brute-forcing, I like to think of it in terms of saying that it makes it impossible to tell anything about a password, including its relationship with other passwords, by looking at it. If the system uses no salting, looking at two users' hashed passwords would indicate whether their real passwords matched. If a ...


117

A 'secret' salt is known as a pepper. From Wikipedia: A pepper can be added to a password in addition to a salt value. A pepper performs a similar role to a salt, however whereas a salt is commonly stored alongside the value being hashed, for something to be defined as a pepper, it should meet one of the following criteria that define it a more ...


19

Background: You should be using a Slow Password Hash. (i.e. bcrypt) By 'slow' I mean computationally expensive, taking more than 100ms (on your hardware) with DoS protection * to test a single password. This is to increase the processing power needed (on attacker hardware) to find the password by brute force, should the hash be stolen. Per-user unique salt ...


15

Your professor isn't correct. The point of a salt is to increase the entropy of the hashed passwords to prevent any sort of pre-computation attack on them as well as preventing the same password from different users from having the same hashed value. Being able to try all possible salt values means that you must have a very LOW amount of entropy in the ...


167

Not storing the salt is bad advice. The main purpose of a salt is that each user password has to be attacked individually. If you do not store the salt then, as you said, you need to try every single salt combination in order to validate the password. If you need to check every single salt combination, this means that the salt cannot be too long (you ...


0

Keep things simple, if you want anonymity, don't use email for logins. Make your user generate an asymmetric key pair to authenticate to your system, call this the login key. When the user want to post a message to your system, the user generates a new asymmetric key pair, call this the data key. The user would then sign their message with the data key and ...


0

The salt has to be stored someplace that's easily accessible given a user ID. That means a database table. The hacker who can get the hashed passwords can get the salts in the same way, often using SQL injection. As others have already written, the salt stops precomputation attacks. There is an approach called a keyed hash in which the hash is generated ...


0

Others have clarified the purpose of Salt, which is to require a separate brute-force process per-user to crack, which would take much longer than a single brute-force process finding matches for every user at once. Salt is not needed to be secret, just unique. A good way to improve on this is to include Pepper, which is secret. Pepper is just some random ...


3

The purpose of salting is, that one cannot build a rainbow table to get several passwords at once. Without salting: An attacker could search the internet for precalculated rainbow-tables and find the passwords with no effort. With a constant salt: The attacker has to build one rainbow-table for this specific salt, and can then get all the passwords with ...


0

You answered your question, just did not saw it. why all people say on SO or Internet anyway that putting the salt in the database is good practice or safe The answer is: if I hack to a database (...) I will take the salt of the first record for example and make a dictionary of all hashes of all english words ( rainbow table ) and then I ...


2

Actually most implementations of algorithms like BCrypt will generate a salt on their own, from the random source of the operating system. This is the best one can do and there is no need to derrive a salt from other parameters. A salt should be globally unique for each password, so an attacker cannot find any precalculated rainbow-tables, and would have to ...



Top 50 recent answers are included