Best Practices for Passphrase Strength

Article:TECH149400  |  Created: 2009-04-28  |  Updated: 2013-11-05  |  Article URL http://www.symantec.com/docs/TECH149400
Article Type
Technical Solution


Subject

Issue



This article details the best practices for ensuring passphrase strength.

 


Solution



You Might Need a Longer Passphrase

There are plenty of password crackers out there. There are open source crackers, commercial crackers, and private ones.  One of the companies that publishes a commercial product has recently released a new version that uses graphics cards as parallel computers to speed it up.

This is pretty cool last week, I wrote an essay explaining how parallel computing is going to speed up disk encryption by 100x over the next few years, so it shouldn't be surprising that the same technology is going to speed up password cracking as well. Sadly, there is no way to arrange the math so that a CPU can only encrypt data and not be instructed (presumably by someone else) to attempt to break the crypto.

We've implemented some countermeasures against this trend. First, I want to discuss what these tools mean to you directly.

If the existence of password crackers worries you, theres a simple thing you should do: get a longer passphrase. Fortunately for those of us who have passphrases, the complexity of breaking them increases exponentially with the length of of the passphrase. A relatively small increase in passphrase length gives a huge benefit against someone trying to brute force the passphrase.

Let's look at some numbers. The math in this present announcement is a bit dodgy,  they say that each graphics card can increase the password cracking speed by 15x, and with four cards in a computer, that increases speed by 100x. When I went to school, 4 times 15 wasnt 100, but whatever. Maybe it is in countries that use the metric system. Let's just accept their numbers, that they can execute 40,000 tries per second with one card.

I'm going to assume that there are 37 possible characters in a passphrase, 26 letters, 10 numerals, and a space. Here is a table showing how long it would take a computer to try all possible passphrases of a given length.

Length Time
1 About a millisecond
2 About a third of a second
3 Over a second
4 Not quite a minute
5 About a half-hour
6 Almost eighteen hours
7 Not quite a month
8 Two years, nine months, and a bit
9 A bit over a century
10 Close to four millennia
20 18,317,682,322,690,222,582 years or thereabouts

Again, note that this is highly parallelizable, so if you have five computers with four cards each in it, that nine character passphrase will fall in less than five years assuming that 4×5 is 20 and not 33 1/3. If you include upper and lower case and some punctuation, then it gets harder, but the real message is that long passphrases are your friend.

Adding a very few more characters to a passphrase makes it harder to crack because of exponential growth. The linear growth that adding more processors gives is completely defeated by modest increases in passphrase length.

The take-away lesson here is that if your passphrase is less than ten characters, you should be concerned, but if it is twenty or more, don't worry about it. I will also add that there are searching techniques that make cracking easier than the straightforward brute force that I outline here, such as using dictionaries. But the obvious way to defeat a dictionary attack is to use words not in a dictionary.

You will, however, want to do something better than the usual leet- speek that uses '3' for 'E', '4' for 'A', and so on. The dictionary searchers know that trick, too.

So what about other countermeasures?

The best one you can use for PGP Virtual Disk or PGP WDE is to have a user that is based on a public key, rather than a passphrase. To you, the end user, this is almost the same. You type the passphrase of a public key pair rather than a passphrase on the disk. The security improvement comes about because the disk's key is encrypted to that public key, not to a passphrase, and thus no password cracker can crack the disk (This technique assumes they don't have your private key file; which would be the case if you are also using a strong system password forcing them to remove the drive from your computer to attack the public key directly).

The other major one is in the software, using the function that we use to convert a passphrase to a key. We don't merely grind up your passphrase. We do two other things. First we add some extra bytes called 'salt' bytes. The salt prevents pre-computed dictionary attacks and rainbow tables. The other thing we do is to hash the passphrase many times.

In PGP 9.5, we changed the number of iterations of the hash function on public keys. We time your CPU and pick a number that is approximately 1/10 of a CPU-second. All you have to do to enable that is to change your passphrase. We're are always implementing new and stronger countermeasures into our products based on our security research and you can expect more of these in upcoming releases.

The downside of the bigger iteration counts is that it takes longer on slower machines. If you set it on a fast desktop computer and migrate that key to a smartphone, it will take a lot longer. You can reset it by changing the passphrase again, but it's still not perfect. We're discussing having a tunable parameter, but that's a ways away as the UI on that will be interesting.

Finally, enterprises that deploy PGP Desktop that are managed via PGP Universal can require passphrases meet certain requirements for both length and quality (a measure of how difficult it would be for a brute force cracker to determine the correct passphrase).

No matter what, though, the best thing for you to do is to have a longer passphrase. You get better resistance to cracking by using a long passphrase. It's much better than anything we can do in the software. So if you are at all worried about password crackers, get a longer passphrase.
 

CTO Corner
Jon Callas, Chief Technology Officer
PGP Corporation
Friday, April 24th, 2009



Legacy ID



1367


Article URL http://www.symantec.com/docs/TECH149400


Terms of use for this information are found in Legal Notices