I recently received a recommandation for setting my password to above 20 characters. The algorithm used for encryption is AES with a 256 bit primary key. How secure is a, let's say, 8 char password against brute force attacks for deciphering encrypted files?

I know that this is considered a good password size on most websites. One reason of this is that they can stop an attack after 3 attemps or so.


This is an interesting article http://www.lockdown.co.uk/?pg=combi&s=articles it details how long it would theoretically take to brute force a password for differnt lengths and symbol sets.

  • Ok, this is a very interesting link. It gives a good ideea of what type of force you need for what time frame. So, given enough resources, it's also possible to break an 8 character password, especially if it's not a good one. – cmserv Jul 21 '09 at 8:25
  • It's still going to take 83.5 days at 100,000 passwords/second. That's not really possible for most attacks. Especially if you're talking about a server password, rather than a pgp passphrase. If they don't have the hash, 8 (random) chars is essentially unbreakable. – Cian Jul 21 '09 at 8:25
  • I wasn't talking about server passwords because I know there you can use much simpler passwords because servers offer extra protection against attacks. I was meaning in other cases, e.g. file encryption. – cmserv Jul 21 '09 at 8:48
  • It'd be good to update this answer. The link is no longer useful, offering a "Closed permanently". For anyone who wants to see the content, wayback machine has your back: web.archive.org/web/20180412051235/http://www.lockdown.co.uk/… – Howard Lince III Dec 3 '18 at 2:02

You might want to point whoever wrote that policy at this blog post from Bruce Schneier.

It's a good writeup of why the strength of passwords are the least of anyone's problems on the web.

  • +1 Because Bruce Schneier is the king of security his word is law. – Mark Davidson Jul 21 '09 at 8:03

Look at the accepted answer in this post. Shows that even an 8 character password using the full range of characters can take ~10,000 years to crack!

  • 1
    I suppose that your referring to a class A attack (10,000 Passwords/sec). If I look at this table and think about a large institution than it just might be doable for 86 Characters, 8 char password, class E or F attack: from 34 to 346 Days. This is not 10000 years ;) – cmserv Jul 21 '09 at 13:29
  • To be honest I didn't check the maths in the post! – Marko Carter Jul 21 '09 at 13:43

If you count the use of rainbow tables as brute force (opinions vary) then for 8 characters, using rainbow tables that include all the characters in the password, about 10 seconds. 20 character password (same characters, same rainbow tables), less than 30 seconds. The catch is that it takes a long time to generate the tables. Mine took about a month to generate on a 3GHz machine processing only at night. On the other hand, you only need to do that once.

The issue of trying to remember long passwords is easily solved by a combination of character substitution and using a phrase. Even something as simple a "#Fr3ddy M3rcury#" is complex enough for most uses, yet is remarkably easy to remember.

  • MD5 passwords use a pretty big salt. I don't think your rainbow tables are going to be big enough to have both all 8 character passwords and all salts for each possible password. – chris Jul 21 '09 at 12:59
  • Would you risk your security on that? My tables are a total of 25GB. That's 40 tables at 650MB each. One day I'll generate a large set. :) – John Gardeniers Jul 21 '09 at 13:49
  • 1
    Um, aren't there 2^32 salts for an MD5 password? That's 2^32*650mb. Good luck with that. – chris Jul 21 '09 at 21:02
  • I did the rainbows tables for all ASCII character LM hashes 64Gb took almost a week using 20 nodes my universities cluster. Take about 3 minutes to go through quite mental. Allows for cracking of all windows passwords <= 16 characters. – Mark Davidson Jul 22 '09 at 8:00
  • 2
    According to wikipedia, the LM hashes don't have a salt. MD5 passwords do have a salt, which means that any single password may have (saltspace*password) hashes, which means you need to have 1 rainbow table per salt. – chris Jul 23 '09 at 12:21

Consider that an eight-character password may be remembered. A 20-character password will be written down.

And then someone can read it.

  • You're right. And there can also be many other factors that will influence the type of security for encrypted files. – cmserv Jul 21 '09 at 8:53
  • A very long password may not necessarily be written down if it is a set of 5 normal english/your language words. Brains are good at remembering them and there are a lot of them out there. – chris Jul 21 '09 at 13:03
  • 1
    Speak for your own brain. Mine shuts right down at the thought of remembering 20 characters. – John Saunders Jul 21 '09 at 13:09
  • If your password were "bowels dungeon metaphysical pierce stagnates" you'd probably be able to remember it after using it a couple times. – chris Jul 21 '09 at 21:08
  • Nope. No relationship between the words. No story to tell myself that I'd remember to tell myself the next time I need the password. I use a password generator program to generate random passwords (I use at least eight characters at all times). I keep generating until I see a password that I can make into a word I can remember, like "cinnademo" = "cinnamon" + "demonstration". That, I can handle. – John Saunders Jul 22 '09 at 6:35

You may be interested in the article "Passwords vs Passphrases". Their conclusion is that a 9 character totally random password is about equivalent to a 6 word pass phrase. But they feel a 6 word phrase would be easier to remember.


It all depends on the characters you use, as this changes the number of combinations you have. Assuming 8 characters:

  • Dictionary word:

    egrep "^.{8}$" /usr/share/dict/words | wc -l
  • Lower case letters: 268 or 208827064576

  • Lower and upper case letters: 528 or 53459728531456

  • Lower, upper and numbers: 628 or 218340105584896

Add punctuation and other symbols and brute forcing is going to take some time.

Those numbers are the total combinations that are going to have to be tried. Obviously, a hacker isn't going to try every combination after they've got the password, so divide by two to get the average number of combinations required.

Harder hashes result in longer cpu time to calculate the hash, so the total time is longer. An example from john:

Benchmarking: Traditional DES [64/64 BS]... DONE
Many salts: 819187 c/s real, 828901 c/s virtual
Only one salt:  874717 c/s real, 877462 c/s virtual

Benchmarking: BSDI DES (x725) [64/64 BS]... DONE
Many salts: 29986 c/s real, 30581 c/s virtual
Only one salt:  29952 c/s real, 30055 c/s virtual

Benchmarking: FreeBSD MD5 [32/64 X2]... DONE
Raw:    8761 c/s real, 8796 c/s virtual

Benchmarking: OpenBSD Blowfish (x32) [32/64]... DONE
Raw:    354 c/s real, 356 c/s virtual

Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short:  294507 c/s real, 295754 c/s virtual
Long:   858582 c/s real, 863887 c/s virtual

Benchmarking: NT LM DES [64/64 BS]... DONE
Raw:    6379K c/s real, 6428K c/s virtual

Benchmarking: NT MD4 [Generic 1x]... DONE
Raw:    7270K c/s real, 7979K c/s virtual

Benchmarking: M$ Cache Hash [Generic 1x]... DONE
Many salts: 12201K c/s real, 12662K c/s virtual
Only one salt:  4862K c/s real, 4870K c/s virtual

Benchmarking: LM C/R DES [netlm]... DONE
Many salts: 358487 c/s real, 358487 c/s virtual
Only one salt:  348363 c/s real, 348943 c/s virtual

Benchmarking: NTLMv1 C/R MD4 DES [netntlm]... DONE
Many salts: 510255 c/s real, 512124 c/s virtual
Only one salt:  488277 c/s real, 489416 c/s virtual

Of course this is all completely academic, because hackers will just phone up your secretary telling them that they are from IT and they need their password for something and your strong password is worthless.


I use non-trivial passphrases to protect

* assets that are important
* stuff that's not subject to anti-hammering (lock-out after repeated attempts)
* stuff that can conceivably be exposed to brute-forced/dictionary-based/hybrid attacks

I'm less concerned with my gmail account, since brute-force attempts at cracking that password will simply lock the account (and anyone with access to the server would just replace the hash with one of their choosing, not try to crack it).

The best passphrase is long (>12 chars) and cryptographically random. However, those are more difficult to remember. So, a passphrase that combines multiple words with seemingly random characters might be a good compromise (perhaps the first 1 or 2 letters of the first couple lines of your favorite song lyric).


There's the security you get from communicating client/server, e.g. as you said, when you're able to stop attackers after 3 attempts (when they attack over the network, as with web applications). With this scenario, almost any length of password can be argued as sufficient.

If however an insider grabs this database with hashed short passwords and is able to bypass the "over the net" limitation of 3 attempts, the game changes.

Caveat with limiting the number of attempts per account is that this will suffice only for targeted attempts at one specific account. You also need to protect against the attack on all accounts with a given (or permutated) password - this will not trigger any alarm when you just limit the number of attempts per account. Given todays NAT and botnets, you can't even argue that limiting the number of attempts per IP is a good way of thinking security.

Good resources for reading have already been given in other answers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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