current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.
up vote 9 down vote favorite
1

I understand why a hashing algorithm should be slow but is the method that makes it slow important to the strength of the hash? Everything I've read says that the algorithm should be computationally slow - hash the thing over thousands of iterations or concatenating it with huge strings to slow it down. This seems like it would put unnecessary strain on the CPU. Couldn't you just hash the password once with a good random salt and then just pause the thread for a set amount of time?

share|improve this question

1 Answer 1

up vote 22 down vote accepted

The goal isn't to make the hash slow for you to compute. The goal is to make the hash slow for an attacker to compute. An attacker with fast hardware and a copy of the hash and salt, giving him the ability to mount an offline attack, to be specific. The attacker need not pause a thread during his computations just because you added that to your software. He is going to compute the hashes as quickly and efficiently as he possibly can. Therefore, in order to make it computationally hard for him, with all of his fast hardware and his efficient hashing software, the hash must be computationally hard for you to compute as well.

share|improve this answer
    
That makes sense, thanks. Given that there is an infinite number of strings that can be hashed but only a finite amount of hash values (though very large) does it really matter that I hash the string over and over? No matter how many times I hash something it's still going to be in that set of hash values. Couldn't an attacker just hash a thing once compare it to the hash that he stole and move on if it doesn't match? –  Matthew 13 hours ago
    
@Matthew No, because if he is not using the same mechanism you are, then his input will not result in the same hash when he attempts to use it as the input for your mechanism. Remember, he's not trying to find the hash. He already has that. He's trying to find the password that generated that hash, and to do that he must use the same mechanism (including the same number of iterations) that you are using. –  Xander 13 hours ago
4  
@Matthew Simple example. Suppose my password is "pwd" and the hash of that using 1,000,000 iterations of hash_algo_1 is "123". The attacker has "123". If he attempts to generate that hash using 1 iteration of hash_algo_1, and suppose he found that "abcd" resulted in the same hash of "123". That's fine, but when he tries to use "abcd" as the password to access my account, it will be using my mechanism with 1,000,000 iterations, and at the end of that process the has will be something else entirely, like "456", there will be no match, and he will have learned nothing. –  Xander 13 hours ago
    
Now I understand. Thankyou. –  Matthew 13 hours ago
    
I should add to the discussion that there may be a reason to artificially slow down your hashing to prevent online attacks, where the attacker is supplying multiple plaintext passwords in succession to brute-force login. Here you could simply pause the thread before returning a result in order to slow down their progress. But this is different to slowing down the hashing algorithm itself which is used to prevent offline attacks as mentioned in this very well-written answer. –  lc. 3 hours ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.