1

There seems to be an agreement that when it comes to offline password brute-forcing, long but simple passwords are better than short complex ones. I recently saw a question related to increasing the number of encryption iterations in GPG and some people seemed to suggest to just come up with a strong password instead, for example because the other option would involve slowing down ARM implementations. Are there any other arguments for not increasing the number of iterations and shortening the password?

Community
  • 1
d33tah
  • 6,514
  • 8
  • 39
  • 61

3 Answers3

3

Increasing the number of iterations makes the function more expensive to compute, both for the attacker (that's the point) but also for the defender. Thus, it feeds on the very scarce resource known as "user's patience"; the number of iteration cannot be made arbitrarily high. This is in particular true if one of the systems on which the password shall be hashed is under-powered (e.g. a cheap smartphone).

Using a more random password usually means using a longer password (the password is not made stronger through its length, but because of its randomness; however, you need more length to make room for extra randomness). A longer password implies extra typing efforts, so again user's patience is an issue, but at least this is an active user: human users are more tolerant of security procedures when they are doing something during the procedure.

Conceptually you need both a high number of iterations, and a strong password full of randomness. The randomness is what defeats the attacker; the iterations are there to counter the effects of Moore's law.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
1

One sample idea: because by definition the algorithm is publicly know there is no problem to build rainbow tables and use them to decrypt the message. From other side building such tables for long password is not feasible/possible in most of the cases

Romeo Ninov
  • 648
  • 5
  • 11
1

Brute forcing revolves around guessing the type of characters in the string. Lets assume a password with 5 characters in the following classes: - lowercase english letters (26) - uppercase english letters (26) - Digits from 0 to 9 (10)

That gives us a total of 62 options for each position, meaning:

62 x 62 x 62 x 62 x 62 = 916 132 832

916 132 832 Possible combinations. Now lets add one more character:

62 x 62 x 62 x 62 x 62 x 62 = 56 800 235 584

It increases logarithmically with every character added. In this case we are not counting symbols which would make it an even steeper jump. Instead of needing 10 hours to guess a 7 character password it might need 40 days to guess an 8 character password.

When you are guessing a password by means of brute force you usually dont know the length, or the classes involved, so you have to try for symbols as well, (and hopefully not accentuated characters). Even with the processing power of today, on a desktop computer the time consumed to try all these combinations is usually just too much. (I posted more about password cracking here if you are interested).

Hashing a password more times will increase the time consumed per round, for example instead of needing 1 second per password it would take 1.5 (again, this is just an example), so it effectively mitigates the attack. However it also adds resource consumptions to the system, in a busy service it might be considerable enough to accept the risk of implementing a lesser authentication mechanism.

Purefan
  • 3,570
  • 19
  • 26