So is using a long passphrase generally better than using a complex password? And even if passphrases are better, how would you convince your colleagues and managers of this fact? The above spreadsheet can help settle the issue and convince others that it's time to leave passwords to the dustbin of history. The spreadsheet is in the public domain and can be obtained in the Downloads area of this blog. The spreadsheet is in the SEC505 zip file along with many other folders and files. The spreadsheet is named "Passphrase_Length_vs_Complexity.xls" and is located in the Extras folder of the SEC505 zip file (scripts.zip) here.
This spreadsheet can be added to the "passphrase vs. password debate" that's been around for some time now (see here, here and here) and earlier versions of this spreadsheet have been a part of the Windows Track at SANS for many years.
How To Use The SpreadSheet In Your Presentation
In the red cells of the spreadsheet you enter your assumptions about your adversaries and your users: How many machines are they running in parallel to crack your passwords? What is the brute-force guessing rate of each machine, e.g., are they using the GPUs from multiple video cards to accelerate the cracking? How many non-alphanumeric characters are your users likely (or required) to use? Do your adversaries know what your minimum password length policy is? And, finally, what percentage of the total number of possibilities (the keyspace) will your adversaries have to search before they crack the password?
That last assumption is intended to account for expert systems or AI password crackers which can use information about your demographics, interests, credit card purchases, psychology, etc. to help improve the guessing. We don't need to know the details of how such systems work, but the net result of using them must be a reduction in the time/space necessary to crack the password or else the AI system would be counter-productive, hence, the spreadsheet tries to accomodate for this by allowing you to reduce the number of password guesses to hash as a percentage of the total possible. For example, if you set the "Percentage Of Keyspace To Be Searched" to 1%, then the AI system will not need to hash 99% of the possible passwords in order to crack your password hash. Of course, we're not talking about popular password cracking tools like L0phtCrack, Cain or John The Ripper, we're talking about cracking systems designed by governments or large corporations for their own "internal" use. If you want to be generous to the popular off-the-shelf crackers, set the percentage to 50% (the smaller the percentage number the more optimistic you are about the effectiveness of the AI and the shorter the amount of time necessary to successfully complete the cracking).
As you move down the rows, the number of characters or words in your password increases. As you move horizontally across the columns, the complexity of your password increases. In the cells in the middle are the maximum number of days, given your cracking assumptions in the red boxes, it would take to perform a 100% exhaustive brute-force crack of the password. To estimate the average number of days, then, cut that number in half. (If I get around to it, I'll make a different spreadsheet for the space requirements for a rainbow tables attack instead of time requirements like this one, but this has already been pretty well worked over.)
If you scroll to the far right, you'll find a collumn for "Dictionary of Words" and another red assumption box. If the unit of combination is the word instead of the character, then you might argue that the math is different (but this could be debated). In this red cell, enter the size of the imagined mental dictionary from which a user would draw to create a passphrase. But remember that you must include the mizpelled words too, so the default of 100k words in the spreadsheet far underestimates the size. (Part of your user security training program should be to tell users to "Choose a funny or outrageous passphrase you'll remember easily, but make sure to misspell at least one of the words!" — this is the one case where bad spelling is good!)
So What Does The Spreadsheet Show Us?
Password complexity is good, no doubt about it, but passphrase length is much better. For any given set of assumptions in the red cells of the spreadsheet, as you move horizontally across the spreadsheet to the right (as we increase complexity) the number of days necessary to crack increases, which is good, but as you move down the spreadsheet (as we increase length) the rate of increase in cracking days required grows even faster. In general, then, adding more length is better than adding more complexity. Passphrase hashes are generally much more resilient against cracking than complex-password hashes.
Other Passphrase Benefits
The other benefits of passphrases have been discussed for some time, but a summary bears repeating here.
If your password or passphrase is 15 characters in length or longer, the LanManager hash of your password is no longer stored in Active Directory or in the local SAM accounts database (there is also a Group Policy option to enforce this, no matter what the length). LanManager hashes are easy to crack, so getting rid of them is good.
A passphrase which is funny, shocking, outrageous, etc. is much easier to memorize than a random-looking password, hence, random passwords are more likely to be written down on a piece of paper kept near the computer or in the laptop case. A passphrase which looks like a regular note to oneself, like "dont farget to buy choc Milk", isn't obviously a secret passphrase, so if it is written down and kept in the laptop case (not recommended) then it's less likely that a thief will figure out what the note is for, especially if you add some distractors to the note like a doodle, a meeting date, phone number, etc. Also, I personally always make the last character of my passphrases a space character, which is not indicated on any piece of paper I might write that passphrase on (or, if I'm feeling paranoid, I make it a non-western Unicode character).
In general, it takes less time to type a 20-character passphrase than a 10-character random password. I can't prove this, it's not like I've done controlled experiments at conferences, but try it yourself: do you hunt-and-peck, look at the keyboard or simply type slower when typing in a string of random non-alphanumeric symbols? Even if you are an expert typist, most regular users are not.
Other things in Windows are secured by your password. For example, the strength of the encryption on your PPTP VPN is partly a function of the quality of your password, so use a long passphrase with misspellings instead of a short randomish password (even better, user certificate-based authentication, or better still, use smart card authentication with IPSec). Your private keys to your public key certificates, such as for S/MIME e-mail, EAP-TLS WPA wireless and EFS files, are encrypted with your passphrase and other bits, so the longer the passphrase the better the encryption on your private keys. If you're using a boot-up System Key (managed with SYSKEY.EXE) then a passphrase will be harder to crack than a password, and the System Key encrypts other password hashes in the local or Active Directory database, the LSA secrets in the registry, private keys to digital certificates, and some other stuff. And what about cached browser passwords, wireless WPA-PSK passwords, passwords for scheduled jobs, locally cached credentials for domain logon, and all the other ways in which Windows interacts with passwords? In general, we often don't know the details of how well or poorly Windows secures these secrets, so in general it's probably better to use a passphrase instead of password whenever we can.
Users will often use the same password to log onto their desktops as they use to log into Amazon, eBay, PayPal and everywhere else they have to type in a password (phishing issues then become problems for your corporate network). If you require a passphrase at work, then most users will probably go back to choosing a different short non-random password for everything else, which is good for you, bad for them. On the other hand, include in your security awareness training program an exercise on how to use free password manager applications like KeePass, and then train them to use a good passphrase to secure the KeePass database.
You can enforce different passphrase policies for different groups of users. You do not have to enforce one uniform password policy for everyone in the domain. This capability is built into Server 2008 for free and you can buy commercial add-ons for Server 2003 domain controllers to do the same thing. So if regular users can't handle it without freaking out, you can at least enforce a sound passphrase policy for the administrators.
Passphrase Problems
Your users will freak out if you simply announce that "all passwords must be 15+ characters long from now on" without any other preparation. Instead, as a part of your security awareness training program and in your monthly Security Reminder e-mails to users, start with gentle hints like "Passwords are hard to memorize so use a funny or outrageous passphrase instead..." and give them some fun examples. Later you can cut a deal with your users and say, "You don't like random-looking passwords? Neither do we, so let's compromise and remove the complexity requirement, but that means you'll need to use a 15+ character passphrase instead, but at least these take less time to type, are easier to remember and don't have to be changed as often..."
And which users might you start with? Start with the other administrators since they are the ones you'll need to convince first and their user accounts are the most powerful and so require the most protection. The problem is that other administrators have been repeating "Random Passwords! Random Passwords!" for so long, it'll be difficult for them to change their tunes in mid-song, but hopefully the spreadsheet will help with that.
You might also have older applications, unpatched operating systems or off-the-shelf web applications which can't handle passphrases. Maybe it's time to upgrade, but there is sometimes another solution if the OS or application isn't authenticating against your Active Directory and there's no automatic synchronization between the password databases. If you type in a 15-character passphrase to authenticate to an OS or application which only uses, say, the first 8 characters of the password, the remaining characters might just be ignored. But the user doesn't have to be told this...
Often there will be command-line tools that can't handle space characters in a passphrase. See if you can put the passphrase inside quotes to get it to work, and if it still doesn't work, you may have to eliminate the space characters from your passphrase or replace those spaces with periods or dashes. Hopefully this problem will not affect line-of-business applications for regular users since those users rarely work at the command line.
In the end, you may simply not be able to enforce a passphrase policy for everyone for political and/or technical reasons, but at least try to secure the accounts of the administrators. These are the accounts your adversaries would most love to compromise because they are the most powerful, and, again, you can enforce different password policies for different groups in the domain.
Conclusion
In short, I hope you find the spreadsheet useful in pushing for passphrases generally in your organization, and maybe industry-wide we can just replace the word "password" with "passphrase" in all of our checklists, policy documents and recommendations. And if this spreadsheet helps to drive a project at your company to migrate to a PKI with smart cards, even better!
