10

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.

9 Answers 9

5

This is an interesting article (see PDF print if web archive unavailable). It details how long it would theoretically take to brute force a password for different lengths and symbol sets.

5
  • 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, 2009 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, 2009 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, 2009 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/… Dec 3, 2018 at 2:02
  • Conclusion I see: mix little and capital alphabets and numbers. Length > 15 is good.
    – Student
    Mar 18, 2020 at 23:46
6

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
  • +1 Because Bruce Schneier is the king of security his word is law. Jul 21, 2009 at 8:03
4

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!

2
  • 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, 2009 at 13:29
  • To be honest I didn't check the maths in the post! Jul 21, 2009 at 13:43
3

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.

5
  • 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, 2009 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. :) Jul 21, 2009 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, 2009 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. Jul 22, 2009 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, 2009 at 12:21
2

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

And then someone can read it.

7
  • You're right. And there can also be many other factors that will influence the type of security for encrypted files.
    – cmserv
    Jul 21, 2009 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, 2009 at 13:03
  • 1
    Speak for your own brain. Mine shuts right down at the thought of remembering 20 characters. Jul 21, 2009 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, 2009 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. Jul 22, 2009 at 6:35
2

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.

1

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
    15601
  • 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.

1

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).

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .