Tag Info

New answers tagged

9

Salts are not meant to be private anyway. They are meant to avoid dictionary / rainbow tables attacks on your hashes (see Why are salted hashes more secure? for more details). hashed_pwd = hash_function(salt + password) So using two salts serves the same purpose as using one salt. hashed_pwd = hash_function(salt1 + salt2 + password) If salt1 + salt2 ...


3

Assuming that you're using per-user salts (i.e. a different salt for each user account), rainbow tables are already an impractical means of attacking the hashed passwords (rainbow tables are typically used where there is either no salt or a salt which is common to all accounts and preferably known to the attacker ahead of time). Where you're using a ...


3

First: Salts are not meant to be secret. So, I'm not sure what is accomplished by this approach. Second: if you have to brute-force the salt, then the attacker can too. What I'm assuming is that your approach depends on the attacker not knowing your custom encryption scheme, and this is a bad idea. The strength of encryption is that it is secure even if an ...


2

Obviously, preventing access by an attacker to the stored hashes is preferable. Hashes are the next line of defense after access denial fails; when the attacker dumps your database, he has to run a dictionary attack on the hash to discover the plaintext. What salts prevent is the use of a pre-compiled "dictionary", aka a "rainbow table". Without a salt, or ...


1

The assumption is that if the attacker can get the hash (of salt + password) then they can get the salt as well, as they're usually stored in the same location, either in a separate column in the same database table, for instance, or as a single compound value as you might see, for instance, from the *Nix crypt function. So yes, the attacker will get bot ...


0

Performing the card lookups against a hash rather than against an encrypted value is done for speed so it is for performance, rather than security, benefit. In terms of security and the limited number of values required to create an effective rainbow table against hashes, a salt should be used. A simple, relatively unique salt per card number would be the ...


0

PRNG(seed)=a string of random numbers hash(salt+password)=hashed password The random number generator highlights the fundamental nature of computers. They are not random. Even the perceived randomness is not random, but close to random, though one might eventually pull out that old hat example of walking half distances towards a goal and never really ...


4

The simplest terms I can think of: A seed is a random value which generally has to be kept secret or the encryption is broken A salt is a random value that is generally not a secret, which is used to make some precomputed attacks harder I like to use those because the idea of keeping things secret or not is something meaningful to anyone.


-1

The encryption seed is used to help generate a pseudo-random number. The seed is used to initiate the generation of a series of pseudo random numbers and increase the statistical randomness of the algorithm used. You can never really generate a truly random number via computation alone which allows some skewness on a probability curve showing the ...


5

Your friend is actually justified in his confusion, because there isn't a big difference. At a high level, each is used as input to modify the output of a scrambling function. Try emphasizing the difference between a hash function and a random number generator, and what they are typically used for. Also, be able to distinguish between a regular random ...


1

As you and schroeder said, a salt is used along with some message as input to some one-way function so that the unsalted message can't be deduced. That is usually done by means of cross-referencing the digest (output) with a rainbow table: if my password is god and stored by a service as md5(god), then an attacker would require virtually no computing power ...


27

Seed: Encryption is powered by random numbers, but how do you generate a truly random number? The current millisecond? The number of processor threads in use? You need a starting point. This is called a seed: it kicks off a random number. Salt: When you hash a string, it will always end up with the same hash. foo = acbd18db4cc2f85cedef654fccc4a4d8 ...


1

There is another way to do this that has not be mentioned so far that seem to me to be more secure. I like to think that such a large corporation would not store our passwords in any of the ways mentioned by StackzofZtuff but you never know. My proposal is that when you attempt to signup, they find all other accounts with some identical piece of personally ...



Top 50 recent answers are included