Mordred wrote:Is there a situation where variant 1 provides better security than variant 2? What are the conditions / parameters that make it so?
Is there a situation where variant 2 provides better security than variant 1? What are the conditions / parameters that make it so?
The questions you gave us are kind of multidimensional. Generally speaking, there are two things: defenses and protections. They both are different. A defense prevents something bad from happening while a protection decreases the likelihood of something bad from happening. The word "security" holds those two words within, so it would be clearer to ask "Is there a situation where ... provides better
protection". While there is nothing wrong with the word "security", it includes the "defense" -part, which is kind of irrelevant in this situation unless that is what you explicitly wanted to ask for.
These questions you asked are hard to answer. I am not even sure what you wanted to exactly ask (I am sorry

). Are we looking for maximal protection or maximal security? Theoretically speaking, we can always make our protections stronger if we keep using stronger preimages. Instead of using a salt of 64-bits of strength, we use one with 65-bits of strength. Now we could use 66-bits to further increase our protection. And so forth... we can continue this again and again endlessly (theoretically). In practise, there are limits, of course. How much can your hardware handle (or the software you are using). I have no answer to that.
Further more, there is a dilemma. Defenses are good guys, they defend us and increase the security as a whole. We always aim to add defenses into our application (Defense in Depth). Protections, however, are witches. When you increase protection of some part of your code, most likely you are decreasing the security of other parts of your whole security design. For instance, the password situation that I described earlier, belongs to this category. Typically a website asks for a username and a password. To make our protection stronger, we could ask for 100 different login values that construct the final login equation. This, however, will reduce the overall security design in many ways, namely, the users start being logged in, they start to save their form field values, they start to put the details into files on the desktop, and so forth. The likelihood of programming level mistakes also increases.
So, what do we aim for? Maximal security? Or maximal protection of the hashed passwords?
Let 's think about a situation where we are doing something like:
Code: Select all
$xss_safe = htmlspecialchars($data,ENT_QUOTES);
Let's also forget XSS for now since it's irrelevant to our problem. Now, what if the function we called fails and it returns the original string? Obviously we are screwed. Look at this code:
Code: Select all
$xss_safe = htmlspecialchars($data,ENT_QUOTES);
if (strlen($xss_safe) == strlen($data))
$xss_safe = htmlspecialchars($data,ENT_QUOTES);
What that code does is that it checks if the size of the data has changed. If it has not, call the function again. This adds protection into our application, but is silly and useless. The coder has to trust its code. If you can not trust something, do not use it. That code does increase the protection level of that part of the program, but the amount of protection it adds is minimal. It is more likely to win one million dollars in a lottery than to gain some use of this implementation. At least nearly as likely.
This is the reason why security is not that simple. Security is complex. You have to make decisions. How much strength do you want? The more strength our hashed passwords have, the greater the protection of our hashes, but this does not apply to defenses. It applies to protections.
What I have been talking about is the overall security. Therefore,
Mordred wrote:Is there a situation where variant 1 provides better security than variant 2? What are the conditions / parameters that make it so?
Yes variant 1 provides better security in a condition where the protection level of our hashed password is not weak. Not weak means that it is strong. Being strong implies that it is practically not breakable at the moment. It may be broken later, which is the reason why it is important to have dynamic hash switching system as well as being able to accept longer salts, etc. Our hash is supposed to be safe, not secure. Safety is the condition of being safe while security is the condition of being secure. Our hash is safe at the moment, but will be eventually obsolete and therefore it can not be secure. For this reason, neither of these variants can be secure, but you can still use the word "security" in that sentence, because you said "better security". It is a comparative.
Mordred wrote:Is there a situation where variant 2 provides better security than variant 1? What are the conditions / parameters that make it so?
Yes variant 2 can provide greater security than variant 1 in a condition where the hash value is weak, which means the hash value is not strong, which leads us into the situation that our protection of hashed passwords is not strong. This means, that the security will neither be great, but with variant 2, the multinous hashing will add more strength into our application, so the protection level is greater than with variant 1. The protection we add is higher than any possible protection we might lose somewhere else in our overall security design.
But if we are talking about protection, then:
Mordred wrote:Is there a situation where variant 1 provides better security than variant 2? What are the conditions / parameters that make it so?
Yes in a condition where the preimage is enough strong. If you are asking me to determine the "enough"-level, then forget it. I will not try to throw exact values. There is a line somewhere, which no one can decide for general use. It does not only depend on the strength of the preimage, but also on the underlying hash function and the overall security design of your application.
Mordred wrote:Is there a situation where variant 2 provides better security than variant 1? What are the conditions / parameters that make it so?
Yes and the condition is that the strength of the preimage must be enough low so that the entropy lost in addition to multihash key strengthening of multinuous hashing is covered by it. It is again, impossible to give exact values not just because of practically very hard mathematical expressions, but also because it depends on the hash function and on the salt.
Mordred wrote:Is variant 1 exactly as secure as variant 2 in all possible circumstances? (In that case, security being equal, we may start discussing a secondary property such as performance or something else)
Again, are we talking about security or protections? In case of protections, there might be a situation where both are equally as strength and in case of security, there might be a situation where both equally add up in the overall security (but that would require us to implement some sort of quality determining system). When should we consider performance over extra security? That comes far earlier than at the point where these two variants are as equal in strength. For security, that point does not come as soon as for strength, but in both cases it is up to the coder to draw the line. It is practically impossible in many cases to predict how safe our hash function is, for instance. It makes little sense to find the perfect situation where both variants are as equal in strength (or in security - in which case we need to define how we determine the security level).
In case someone does not understand the difference between safe and secure, let me explain that:
Safe: Not exposed to and is protected from danger or risk.
Secure: Is certain to remain safe and unharmed.
Safety: The condition of being safe.
Security: The condition of being secure.
While these two words seem similar, they are not. The word “safe” is used often in cases when we are talking about human lives, health and other things in general. The word “secure”, however, is more used in cases when we are talking about criminals or crimes. Imagine a weather storm outside your home. Staying at home keeps you safe from getting wet. After the weather storm has faded out and the sun is shining, using sunscreen will make sure your skin is safe. Now, think about banks. They keep your money inside a safe. Why is it called “a safe” and not “a secure”? This is because the safe does not just protect from criminals, but also from environmental hazards and so on
In web environments, using the word “secure” is more likely the right word choice, because we are trying to protect from attackers who are more or less criminals. Another difference between the two is that being safe does not mean that it remains safe. It only describes the current situation. For instance, the sunscreen discussed earlier keeps you safe, for a while. After certain amount of time, it will not help you anymore, because of the durability of sunscreens. More over, claiming that a system is secure means that it is secure at the very moment and will stay like that. A computer hard drive may crash at any moment. Therefore, claiming that a hard drive is secure is bollocks.
Right now I feel a bit tired, I'll probably answer next time tomorrow.