How much pre-hashing a password increase security against brute force attack?

Question

I am wondering how much hashing a password used as key for a symmetric key algorithm helps preventing brute force attack on crypted text.

Let's assume I want to crypt text A using key B using AES-256. I expect user to input not secure keys, such as: ['apple', '22march', 'newyork']. So I hash these keys with PBKDF2 using many iterations, and I got the key B. That is long and fixed length key I will use for crypting the text with AES.

AES(TEXT, PBKDF2(KEY))

Would this help preventing brute force attacks?

The attackers should also hash each input (for example from a dictionary, where they'll match 'apple') to get the key B for trying decrypting the text A using AES? Or alternatively, they should trying brute forcing directly the AES crypted text, but the keys are always output from PBKDF2 and so they are really difficult to be cracked.

Answer 1

Would this help preventing brute force attacks?

It would slow down an attacker and prevent them from trying as many password guesses. E.g. if you used 1000 rounds like in RFC 2898, you would reduce the number of guesses by a factor of 1000.

Assuming you count dictionary attacks under brute force attacks, such attacks would definitely not be completely prevented. Simplest passwords like your example of 'apple' could be cracked regardless of which (practical) number you choose for iterations. You can't make the work factor large enough that the attacker can't still make hundreds or thousands of guesses in a feasible time, or you can't yourself use it.

But yes, your use of PBKDF2 makes sense and is essentially the purpose of having it in a key generation context. It's just that there is no way to make as simple passwords as 'apple' secure under any circumstances. (At least unless there's another authentication factor.)

Answer 2

KDFs like PBKDF2 are a work multiplier but they can't get blood from a stone. A PBKDF2 using 10,000 rounds "slows" the attacker down by requiring each "guess" to take 10,000 hashes instead of 1. The problem is that passwords like the ones you described are so weak a 10,000x increase in cracking time is like going from 1 ms to 10 seconds. It really isn't going to do much.

If we assume you are using 10,000 rounds of SHA-256. A modern GPU can perform 1 to 2 billion hashes per second. So yes PBKDF2 slows it down. Instead of that meaning 1 to 2 billion password attempts per second it means "only" 100,000 attempts per second.

Still 100,000 attempts per second means very weak passwords will still die quickly. Hashing a list of 1M most common passwords would still only take 5-10 seconds. That is just with a single GPU. With a team of hackers who collectively have dozens of GPUs they can crunch through much larger lists in the same amount of time.

So yes you should use a strong algorithm, use a multiround KDF, use a large per record random salt but just keep in mind none of that can make "p@ssword" secure.