Advanced Hashing

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Hannes2k
Forum Contributor
Posts: 102
Joined: Fri Oct 24, 2008 12:22 pm

Re: Advanced Hashing

Post by Hannes2k »

Hi,
Hannes2k wrote: The reason is, that the attacker have to calculate the hash multiple times to test one possible password, so if you call the hash function e.g. 2^16 times, the attack would be slowed down by the factor of ~65 000. Instead of 1 day the attacker than needs 65 000 days.
So you add 15/16 bit extra stength to the password.
By re-hashing the values all you're doing is introducing more collisions. The author you linked specifically said hes using a reversible permutation ( not double hashing! ) and states he cannot make any significant claims.
Which author do you mean?

Do you mean the paper Secure Applications of Low-Entropy Keys?
4.1 A Hash-Function-Based Key Stretching Algorithm
Let H() be a secure, collision-resistant one-way hash function, such as SHA1
[NIST93] or RIPE-MD160 [DBP96], and let S be a salt value.
The basic scheme works as follows:
X0 = H(Kshort; S).
For i = 1 to 2^t:
Xi = H(X{i-1}).
Klong = X{2^t} .
We are computing the 2^t-th iterate of H().
I do not see where you see a reversible permutation. And PBKDF1 uses also MD5 or SHA1 with the same schema: hash(hash(...(hash(salt+pw)...).

Maybe I misunderstood you.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Advanced Hashing

Post by josh »

I was referring to section 5. Regarding section 4 the author also points out several shortcomings. "it is difficult for us to make a statement about the security of this scheme against cherry picking. Because of the redundancy in the input to the has function, we believe it will be secure given a secure hash function, but cannot prove it.".

The section I was pointing out is "just as with ordinary keysearch attacks, one concern we have with attacks against a key-stretching algorithm is whether or not it is feasible for an attacker to build a special-purpose massively-parallel keysearch machine."

If I sat there and wrote a recurring formula and you were smart enough to make it linear and get the same output, and at the same time my "hard to compute recurring formula" shrank the co-domain of the checksum, all I did was screw myself and waste dev hours. In other words unless this is your major or something you're better off just getting ahold of a stronger checksum algorithm, rather than trying to doctor an existing one.

Indeed since hte title of the paper "low entropy", I'm assuming this would weaken you against dictionary attacks
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Advanced Hashing

Post by kaisellgren »

Mordred wrote:Hashing passwords is a mitigation measure against offline attacks.
Exactly.
Mordred wrote:Well done, but what you did was not finding a collision
Never said what I was trying to do. I explained why it is important to keep your hashes strong.
Mordred wrote:There are valid reasons to hash twice or to concat two hashes. Also, the notion that double-hashing reduces hash strength is only a theoretical one (I've fallen to that once as well). In practice, the reducement of strength is by a tiny fraction of a bit, it doesn't matter (nearly) at all.
No there are no valid reasons to double hash your passwords (or to concat, wtvr). Zero. If you need more "secure" hashes, use a more secure hash. There are lots of resources online that prove how different kind of hash value manipulation yields in weaker hashes. This, of course, depends how do you manipulate your hashes. In case of double hashing, well it is scientifically right, and does increase the time taken for attacks on passwords, but there is no need to manipulate your hashes, because we have many strong compressors out there. Take a look at Whirlpool and SHA-512, which both are available in PHP.

Funny thing is, that your arguments are in contraposition. You want everybody to double hash passwords, because otherwise they are easier to break - but still you claim that no one can break hashes, because they would require much firepower. So, in which side are you?
Last edited by kaisellgren on Sat Feb 14, 2009 1:36 pm, edited 1 time in total.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Advanced Hashing

Post by kaisellgren »

exesteam wrote:

Code: Select all

sha1($msg).md5($msg);
do not ever try to join other hashes. Use only one hash function and never touch the final output (the hash value). In the above situation, this is no better than the strongest hash in the set - at least not with the typical hash construction. Suppose M and M’ collide in SHA-1. Then, M . Q and M’ . Q will collide since their hash states collide after M (M’ respectively). This way an attacker would only have to ?nd a pair Ms and M’s and move forward to attack the second hash. It's feasible that two properly constructed hashes offer more security as a pair however with the common MD style hash this is not believed to be the case.

EDIT: @Hannes2k: If you run the same hashing method multiple times, you increase the time one needs to operate to brute force passwords. It is generally "an allowed" approach, however, it may increase the likelihood of other attacks (preimages,precs,among others). I would suggest just use better hash function, than sticking with md5 and looping several times or even sha1. SHA-256, for instance, is twice slower than SHA-1, but if you loop several times through SHA-1, you could use SHA-512 as well. Another thing to note, if I have the hash, I do not need to find out the original password, just another value having the same hash value. If you have added a strong salt to the password, it does not really help to multihash anymore. The salt will do it.

The funniest thing is, to my experince (that is - my excel report saying), that ~96% of websites vulnerable to SQL injections or any others that gave me an access to the database, allowed me to access the filesystem, too. We are arguing about a perfect secure hash function or approach which does not exist, yet more likely our database is most likely configured to access the filesystem or we are allowing nasty second level FA attacks on our system. E.g., modifying the database in order to mess up the script. That's, however, another topic. I'm not saying specifically that OUR applications are insecure, but in general people's systems are, which is bad, because many people are going to read this topic.
Last edited by kaisellgren on Sat Feb 14, 2009 1:52 pm, edited 1 time in total.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Advanced Hashing

Post by kaisellgren »

Hannes2k wrote:So if you use a secure hash algorithm, this methode could be used to increase the strength of the user passwords.
If your users do not use weak passwords, a key strengthing methode is senseless, but if not...
I second that.

I just want to note one thing. This is key strengthing. It does not add any protection on the underlying compressor. You can decide what is the best approach for you to key strength, but this approach Hannes2k is showing us, is not necessary. Whether it is the best approach in terms of performance, we can argue that in another nonsecurity related topic.

EDIT: Sorry, I wish I could merge my posts :cry: it's just ... I get too excited and active... and I didn't notice that I have three posts in a row 8O
User avatar
Apollo
Forum Regular
Posts: 794
Joined: Wed Apr 30, 2008 2:34 am

Re: Advanced Hashing

Post by Apollo »

Mordred wrote:How much higher?

In your setup for two random values with an N bit hash, the probability for a collision between h(s1) and h(s2) is 1 / 2^(N/2). Please make a guesstimate what will be the collision probability between h(h(s1)) and h(h(s2))
I have no idea, and I think neither do you - one reason being that h(s1) and h(s2) have fixed length and probably only contain 0-9a-f. Can you predict how much more vulnerable hashing algorithms are in general to collisions with inputs of such a specific format?

I'd say you cannot rule out for sure, that the collision probability could be significantly higher. I'm not saying it's likely, but if some Chinese guy invents an effective attack in 3 years from now, where it turns out the number of attempts are reduced exponentially when it's known that the inputs have a fixed length and consist of hex chars only, the assumption is screwed.
User avatar
Apollo
Forum Regular
Posts: 794
Joined: Wed Apr 30, 2008 2:34 am

Re: Advanced Hashing

Post by Apollo »

Hannes2k wrote:Hi,
Thats right, that the probability for hash(hash(s1)) == hash(hash(s2)) is higher, but you need the same time to find a collosion for hash(hash()) as for a single hash()-call (when you uses a secure hash algorithm).
Well,
I wrote: [about double hashing]
what would be a valid reason, other than increasing brute force time? (in which case you're MUCH better off by just using a longer hash, e.g. sha512 instead of sha256).
As I mentioned above, you are not sure how much the colission probability increases by nesting hashes. Even more so when hashing over and over many times.
That's wrong!
If you wanna find a string s so that hash(s) == hash(password), it's much harder to find such a string if you have called the hash function multiple times ( hash(hash(hash(...(pw)...) ), because in the most cases a bad password was selected (who uses a password with 20 random chars? No one, most users uses a password with a length of 8 and just a-z0-9) .

The reason is, that the attacker have to calculate the hash multiple times to test one possible password, so if you call the hash function e.g. 2^16 times, the attack would be slowed down by the factor of ~65 000. Instead of 1 day the attacker than needs 65 000 days.
So you add 15/16 bit extra stength to the password.
I agree it would be a security improvement if it takes significantly longer to calculate a hash.
Then again, if you nest hashes many times (even 65536 times) you are completely unsure of how exactly much more colission probability you actually introduce.

You can get the same security improvement (that is, longer hashing calculation time) by using a longer salt. And that comes without the possible colission flaw.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Advanced Hashing

Post by josh »

kaisellgren wrote:Funny thing is, that your arguments are in contraposition. You want everybody to double hash passwords, because otherwise they are easier to break - but still you claim that no one can break hashes, because they would require much firepower. So, in which side are you?
I agree with everything you wrote but I don't think he wants anyone to double hash their passwords
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Advanced Hashing

Post by kaisellgren »

josh wrote:
kaisellgren wrote:Funny thing is, that your arguments are in contraposition. You want everybody to double hash passwords, because otherwise they are easier to break - but still you claim that no one can break hashes, because they would require much firepower. So, in which side are you?
I agree with everything you wrote but I don't think he wants anyone to double hash their passwords
Yea maybe not. Maybe he wants to say that double hashing is a good approach in certain situations, but in password hashing it is not so great approach really.
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Advanced Hashing

Post by Mordred »

(Sorry for the long post, I haven't had the chance to sit and answer properly these several days)

As I reread the discussion, it appears that one of the major points of disagreement comes from speaking about several different applications of hashing. Maybe we should restart the conversation and assert which case we are talking about:
1. Hashing passwords or
2. Other usage of hashes - MAC, checksums, whatever

Since some properties oh hash functions are relevant only in some uses, the context is very important.
Claims as "X is better than Y" (if not universally true) can only be evaluated within the context that the claimant meant (but failed to specify)

For example, kaisellgren said:
SHA-2 among with other *newer* and stronger hash families are enough to prevent any attacks. There is zero need to complicate hashing by altering it or running it through series of string and data manipulations.
Within the context of password hashing it is more or less true, although not entirely.
Within the contaxt of general, cryptographic usage of hashes, it is not true, the hashes from MD5 and SHA families suffer from length-extension attacks, meaning they can't be used as MACs and similar usages.

md5(m).sha(m) is also valid - the concatenated hash is as strong as the strongest of the two hashes, which means that if finding collisions in one of the hashes becomes trivial, the attaker still has to fnd collisions on the other hash. It is fun to note that the strength of the concatenated hash is not stronger than the strongest of the two hashes, but just as strong.

hash(hash(m)) is also valid - it prevents length-extension attacks, although HMAC should be better (at least the experts say so)
Apollo wrote:Mordred wrote:
Offline attacks do not aim for generating collisions as well. Collisions matter when you use hashes for MAC/signatures.
Hashes are commonly used for password verification. By creating a collision, you can get a password that (regardless of whether the password is really correct) gives you unauthorized access. What's that got to do with (H)MAC/signatures?
Finding collisions in hashed salted passwords gives you nothing, unless the "collision" you find is in fact the preimage (i.e. the original password + salt). Good luck with that ;) With passwords, I think that "bruteforce resistance" is more important than collision-resistance. This is where password strengthening (as Hannes pointed out) and proper salting come in play.
Hannes wrote:To calculate this is easy. ... (math, math, math)
Apparently not, your math is wrong.
kaisellgren wrote:No there are no valid reasons to double hash your passwords (or to concat, wtvr). Zero. If you need more "secure" hashes, use a more secure hash.
Here's one such instance of context mismatch. I am talking in general, not about hashes. Arguments - above.
kaisellgren wrote:Funny thing is, that your arguments are in contraposition. You want everybody to double hash passwords, because otherwise they are easier to break - but still you claim that no one can break hashes, because they would require much firepower. So, in which side are you?
Putting words in the mouth of the other person isn't a conversation, it's a monologue ;) I never said either - just said doublehashing is valid technique sometimes, and that finding collisions requires much firepower. I still insist both statements are true, and am open for discussion on them (but not on extrapolated versions of them).
Yea maybe not. Maybe he wants to say that double hashing is a good approach in certain situations, but in password hashing it is not so great approach really.
Ah, I see that in the last posts it became clear that this is another case of context mismatch. Yes, I was talking about generic hashing, but you still misunderestimate key strengthening.
Apollo wrote:I have no idea, and I think neither do you - one reason being that h(s1) and h(s2) have fixed length and probably only contain 0-9a-f.
I'm with you on the first part - I have no idea really, just read other people's ideas about it.
For the second part - you're wrong. You're thinking about the textual representation of the hash value, which, while containing less possible characters, has double length than the binary representation. Since the output of the hash is usually the same size as the input block, it may be constructed in such a way that there are no collisions. Whether this is the case with MD5 and SHA*, I simply don't know. That's why I said the loss of entropy is probably only a fraction of a bit.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Advanced Hashing

Post by kaisellgren »

exesteam wrote:i am using hashing for passwords
That one sentence means that we are discussing password hashing here. At least this is the way I think, I try to stick with the OP's questions.
Mordred wrote:For example, kaisellgren said:
SHA-2 among with other *newer* and stronger hash families are enough to prevent any attacks. There is zero need to complicate hashing by altering it or running it through series of string and data manipulations.
Within the context of password hashing it is more or less true, although not entirely.
Within the contaxt of general, cryptographic usage of hashes, it is not true, the hashes from MD5 and SHA families suffer from length-extension attacks, meaning they can't be used as MACs and similar usages.
It was purely meant for password hashing. It is true that what I said is not entirely "true". I doubt that these algorithms (SHA-2 family among other newer) offer a good solution for the long term. Ultimately the key benefit they offer is a longer hash value. They may be vulnerable to the same kinds of attacks that may eventually make SHA-1 obsolete. People often think that a longer output yields in a stronger hash, but that is not always the case here. We have to keep in mind that cryptanalysts have not yet been dealing with these potential successors nearly as much as with SHA-1 and when that starts to change, new weaknesses may be discovered.

No hash is secure. That is the fact. The word "safe" can be used, but the word "secure" can not be used.
Mordred wrote: md5(m).sha(m) is also valid - the concatenated hash is as strong as the strongest of the two hashes, which means that if finding collisions in one of the hashes becomes trivial, the attaker still has to fnd collisions on the other hash. It is fun to note that the strength of the concatenated hash is not stronger than the strongest of the two hashes, but just as strong.

hash(hash(m)) is also valid - it prevents length-extension attacks, although HMAC should be better (at least the experts say so)
I already explained why concatenating like that is not good, in terms of password hashing:
do not ever try to join other hashes. Use only one hash function and never touch the final output (the hash value). In the above situation, this is no better than the strongest hash in the set - at least not with the typical hash construction. Suppose M and M’ collide in SHA-1. Then, M . Q and M’ . Q will collide since their hash states collide after M (M’ respectively). This way an attacker would only have to find a pair Ms and M’s and move forward to attack the second hash. It's feasible that two properly constructed hashes offer more security as a pair however with the common MD style hash this is not believed to be the case.
There are many ways to do mathematical attacks or cut down the time needed to run the compressor, etc and someone reading this topic may now think that creating his "own hash function" is a good idea. Hash functions have been designed to prevent many kind of mathematical, cryptographical, etc attacks. Leave hash function creation to the experts - do not make your own implementations (this is a suggestion to everyone who has no or little expertise in this area). Many people will read this topic, so I want to make it clear that hash value manipulation is not a clever idea in general when it comes to password hashing.

Playing around with hashes is the same as playing around with fire and 99% of people will put their home in fire.
Mordred wrote:
Apollo wrote:Mordred wrote:
Offline attacks do not aim for generating collisions as well. Collisions matter when you use hashes for MAC/signatures.
Hashes are commonly used for password verification. By creating a collision, you can get a password that (regardless of whether the password is really correct) gives you unauthorized access. What's that got to do with (H)MAC/signatures?
Finding collisions in hashed salted passwords gives you nothing, unless the "collision" you find is in fact the preimage (i.e. the original password + salt). Good luck with that ;) With passwords, I think that "bruteforce resistance" is more important than collision-resistance. This is where password strengthening (as Hannes pointed out) and proper salting come in play.
Many applications have weak salting, finding collisions is not that hard in case they are not using SHA-256, for instance. But in general, yes, finding collisions is very hard. The note about "brute force resistance" vs "collision resistance" is good, because ultimately hashes are what are supposed to prevent collisions - not our scripts.
Mordred wrote:
kaisellgren wrote:No there are no valid reasons to double hash your passwords (or to concat, wtvr). Zero. If you need more "secure" hashes, use a more secure hash.
Here's one such instance of context mismatch. I am talking in general, not about hashes. Arguments - above.
I noticed. I have been thinking about the topic starter's post.
Mordred wrote:
kaisellgren wrote:Funny thing is, that your arguments are in contraposition. You want everybody to double hash passwords, because otherwise they are easier to break - but still you claim that no one can break hashes, because they would require much firepower. So, in which side are you?
Putting words in the mouth of the other person isn't a conversation, it's a monologue ;) I never said either - just said doublehashing is valid technique sometimes, and that finding collisions requires much firepower. I still insist both statements are true, and am open for discussion on them (but not on extrapolated versions of them).
Yea, the same thing again, I was referring to password hashing. I think my word choice of "valid" was a bit vague. It is hard to define what is "valid". I claim that double hashing passwords is not the best approach to take, but it is not a "bad" approach either.
Mordred wrote:
Yea maybe not. Maybe he wants to say that double hashing is a good approach in certain situations, but in password hashing it is not so great approach really.
Ah, I see that in the last posts it became clear that this is another case of context mismatch. Yes, I was talking about generic hashing, but you still misunderestimate key strengthening.
The key, which I use to refer to the content you pass into the hash function, or the preimage, used among cryptologists, has to be strong. Double hashing is not the only way to strengthen a key, and that is why I do not recommend it. For instance, let us assume we have random binary data of 64 bytes where each byte has full 8-bits of entropy and that we are concatenating your password "hello" into the end of it - isn't the key quite strong, don't you think? Is there really a need to start double hashing it? Also in terms of performance, using W cipher numerous times is expensive. Whirlpool is a great alternative to SHA family. (Like I earlier stated that SHA-2 family may not be that good choice).

There is no right answer, just good or quite good approaches which depend on the context like you said.

There is, however, one thing that almost no one ever thinks about. The ultimate solution to perfect hashing is to build a system that accepts dynamical hash switching. I can use, for instance, HAVAL-256 with some passes to hash my passwords safely, because when it becomes clear that HAVAL is not that safe anymore, I just switch my hash algorithm. That's it. I do know that it (the approach of switching hash algorithms) might be very hard to achieve in practise.
Mordred wrote:
Apollo wrote:I have no idea, and I think neither do you - one reason being that h(s1) and h(s2) have fixed length and probably only contain 0-9a-f.
I'm with you on the first part - I have no idea really, just read other people's ideas about it.
For the second part - you're wrong. You're thinking about the textual representation of the hash value, which, while containing less possible characters, has double length than the binary representation. Since the output of the hash is usually the same size as the input block, it may be constructed in such a way that there are no collisions. Whether this is the case with MD5 and SHA*, I simply don't know. That's why I said the loss of entropy is probably only a fraction of a bit.
You are right. Two weeks ago I was in a university of Tampere with a cryptologist talking about these kind of stuff. We tried to measure the amount of entropy lost in these kind of cases - and I can tell you that is nearly impossible to measure because there are so many factors in the game, and after all, the amount of entropy loss is very insignificant. If and when I double hash, I do not care about losing entropy, I care about losing performance, because it is what you are about to lose more of the two.

Still, though, we are discussing security - and any additional strength or entropy is welcome. ;)

And Mordred, apologizing for long posts is irrelevant, because you are allowed to post up to X bytes. If you post a longer post, then you get an irritating message saying that you have to shorten your message :)
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Advanced Hashing

Post by Mordred »

Glad we cleared things, it's just that you used such strong words with little indication on what you meaned.

Changing the hashing scheme would require all users to change/update their passwords, not very user-friendly, for a not-so-central feature. On the other hand, using a longer hash would allow us, even after significant decreases in it's collision resistance, to have adequate strength. SHA512 has 256-bit strength against collisions while for modern crypto use 128 bits of "strength" are deemed enough, so hopefully that will allow you to postpone the need of changing the scheme for quite some time.

Some more things, in the context of password hashing:

Hashes do not magically protect things without consideration of their use. They do not work out of the box, with zero effort. With passwords, which usually have very little entropy, it is very important to strengthen them before hashing, salts are one well-known mechanism. With that in mind, let's reiterate some of the ideas mentioned up to now.

Consider this scheme:

hash(password + user salt + global salt)

compared to this scheme:

hash(hash(password + user salt + global salt))

Is there a difference? Is one of them better? Is it better always, or only in some (what?) circumstances?
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Advanced Hashing

Post by kaisellgren »

Mordred wrote:Changing the hashing scheme would require all users to change/update their passwords, not very user-friendly, for a not-so-central feature. On the other hand, using a longer hash would allow us, even after significant decreases in it's collision resistance, to have adequate strength. SHA512 has 256-bit strength against collisions while for modern crypto use 128 bits of "strength" are deemed enough, so hopefully that will allow you to postpone the need of changing the scheme for quite some time.
Just always remember that X bits of strength is not the same in symmetric, in asymmetric and in password hashing. Password hashing key strength is very near to symmetric encryption key strength. Also, we have come (again) to the same situation: your claim of adequate strength depends on the situations. I myself am working on websites that operate easily e.g. 15 years. Can you guarantee SHA-256 is completely safe in year 2025, for instance? No one can. Eventually you have to switch your hashes. That's the life. Sad.

And by the way, it is not unuser-friendly at all. The user has to enter a new password and that's all. How often? Maybe every 10-20 years? And that's it.
Mordred wrote:Hashes do not magically protect things without consideration of their use. They do not work out of the box, with zero effort. With passwords, which usually have very little entropy, it is very important to strengthen them before hashing, salts are one well-known mechanism. With that in mind, let's reiterate some of the ideas mentioned up to now.
Of course. I hope that is clear to everyone.
Mordred wrote:hash(password + user salt + global salt)
compared to this scheme:
hash(hash(password + user salt + global salt))
Is there a difference? Is one of them better? Is it better always, or only in some (what?) circumstances?
Assuming that the concatenated key parts are strong, the second approach barely makes any difference at all. It strengthens the key a bit depending on the key parts and it will make us lose tiny portion of entropy. Either way, the differences are futile. The speed, however, might be too slow in the second approach (basically 2x slower, but not exactly).

A strong password hashing system has to take care of two factors: the underlying hashing algorithm and the key strength. Provided that our user salt and global salt were strong, the key part is well implemented. Now the rest is up to the hash algorithm that we chose. If it is SHA-256, for instance, there is nothing we need to do anymore in the first approach - it is "perfect". After that, we need to ensure that our system is capable of hash algorithm switching.

One dangerous mistake of implementing hash switcher is that you do not ask your users to renew the original passwords. If you switch a hash algorithm, it means that it is no longer safe - so you also must regenerate your original plaintext password (ask the user to make a new password).
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Advanced Hashing

Post by Mordred »

Mordred wrote:Is there a difference? Is one of them better? Is it better always, or only in some (what?) circumstances?
Assume nothing, analyze all scenarios.
User avatar
Apollo
Forum Regular
Posts: 794
Joined: Wed Apr 30, 2008 2:34 am

Re: Advanced Hashing

Post by Apollo »

Mordred wrote:Consider this scheme:

hash(password + user salt + global salt)

compared to this scheme:

hash(hash(password + user salt + global salt))

Is there a difference? Is one of them better? Is it better always, or only in some (what?) circumstances?
I can't possibly think of any practical, theoretical or imaginary situation where the 2nd would be better in any way than just using the 1st with longer salts.
Post Reply