Test the strength of your password policy

Most password-cracking scenarios focus on attacks that convert a captured hash to its plain-text password equivalent using an offline attack and hash or rainbow table database. Capturing password hashes assumes a lot. In most cases, the attacker must have highly privileged access (admin or root) to get to the hashes; if they do, they can inflict much more other damage. So why just discuss password cracking?

Further, in the Windows world, a remote attacker must have local administrator access on a computer and NetBIOS access, which is often blocked by the perimeter firewall. Despite popular belief, today’s Windows logon password hashes cannot be sniffed off the wire. Plus, if an attacker can get the hash, he or she can conduct a “pass-the-hash” attack and not worry about converting it in the first place.

[ Roger shares more advice on managing passwords in these Security Adviser posts: “Password size does matter” | “Getting a grip on better password hashes” | “Ask better password questions” ]

Don’t be lulled into a false sense of security, though: A complex, six- to eight-character password may have been sufficient 10 years ago, but it’s certainly not today. Most of the Linux/Unix systems I’ve reviewed do not enable their account lockout policy. In the Windows world, the true administrator account cannot be locked out, and some software programs don’t log against the account lockout policy. Many companies are disabling the account lockout policy to prevent automated worms, such as Conficker, from locking out all the user accounts and causing an indirect DoS event.

Moreover, most companies still lack a sufficiently adequate auditing system to alert admins of repeated failed logon attempts — even if the number exceeds the hundreds of thousands. So a remote attacker can enumerate all of your external access points (Outlook for Web Access, Terminal Server, SharePoint, FTP, SSH, RDP, Telnet, and so on) and guess away against your administrator account until he or she breaks it.

Still,without performing password-penetration tests against them, I have a hard time demonstrating to clients how weak mere six- to eight-character passwords really are. I enjoy performing these tests (usually I’m able to break most passwords in under three days, if not in hours), but my contract often prevents me from attempting them. Thus, I decided the next best thing was to create a spreadsheet-based calculator in which you can key in your current password policy and see how your passwords might hold up against the number of guesses an attacker can make in a given minute. Download the spreadsheet.

Cracking open passwords As far as I know, this is the only password calculator that shows the success rate of real-world password-guessing attacks. A password’s pure strength lies in its length, the number of possible characters or symbols it contains (called the character set), and the randomness of character selection. If you want to determine the number of possible passwords for a given length and character set, just calculate the number of possible characters in the character set to the power of its length (characters^length). This will give you all the possible password choices or password space.

However, this theoretical number assumes that users will avail themselves of all possible password choices (called perfect randomization). This is usually a horrible assumption unless a very good random generator creates the user’s password. Most users pick passwords that contain portions, if not complete, words and names from their language. In fact, for a large majority of users, portions of their password can be ascertained with pretty good accuracy by the average password guesser.

Most professional password guessers know there is a 50 percent chance that a user’s password will contain one or more vowels. If it contains a number, it will usually be a 1 or a 2, and it will be at the end. If it contains a capital letter, it will be at the beginning, followed by a vowel. The average person has a working vocabulary of 50,000 to 150,000 words, and they are likely to be used in the password. Women are famous for using personal names in their passwords, and men opt for their hobbies. “Tigergolf” is not as unique as CEOs think. Even if you use a symbol, an attacker knows which are most likely to appear: ~, !, @, #, $, %, &, and ?.

Dr. Jesper Johannson, in his series of “Great Debates: Passwords vs. Passphrases” papers, found that 80 percent of passwords he surveyed shared the same 32 characters. Using these sorts of rules, which have been validated by every password guesser writing on the subject the last decade, a very large password space can be broken down into a much smaller set of likely nearly non-random passwords. (My friend Mark Burnett, author of “Perfect Passwords,” conducted a great study on password character distribution.) Bruce Schneier and I did a similar study on tens of thousands of passwords stolen from MySpace, which you can read about in an earlier Security Adviser post and on Bruce Schneier’s site.

The randomness of a password is called its entropy. Reading about password entropy in detail will almost hurt your brain. To simplify, a password such as “password” or “12345678” has almost no entropy; a password such as “vB%&7P” has a higher-than-average entropy. However, it’s nearly impossible to calculate a password’s true entropy without examining it along with every other choice in the password space. But several people have made intelligent guesses, and the password entropy model you rely on will have a significant impact on the overall success of your password policy defense.

Enter the spreadsheet In the password-guessing calculator spreadsheet, I allow the user to choose among four different password entropy models: one developed by NIST (National Institute of Standards and Technology); one developed by C.E. Shannon, noted language entropy researcher; one developed by Johannson; and the Perfect Entropy model. I think the most accurate password entropy model comes from NIST (NIST Publication 800-63, Appendix A, Table A.1, p.53), but I include other models for reference, and there is room defined for more. It’s important to point out that all the included password entropy models are probably flawed, but they are the best we can do without knowing all the real-life passwords in a given password space. In my experience, I think even the NIST model is too conservative, overestimating guessing effort.

In the spreadsheet, the user inputs his or her password policy (length, character set, maximum age, and whether complexity is enabled), selects an entropy model, and enters the number of guesses per minute that an attacker can attempt.

The question I get most often is, “How many attack guesses per minute is realistic?” That depends on a whole host of factors, including bandwidth from source to destination, source and destination resource utilization, the application being attacked, lockout rules, the type of system being attacked, other defenses, and the number of attack threads generated.

There are many attack tools (including Brutus and THC’s Hydra) that allow multiple threads to be started simultaneously. Add to it that the attacker can attack from multiple origination points at once, and the number of attack threads can increase quickly. When I conduct a penetration test, I can routinely generate several hundred password-guessing threads a minute, but more than that, most systems start to bog down, and many crash completely. You’ll have to conduct your own real-life password guessing tests using an automated tool to determine the valid ranges you should input enter the spreadsheet.

You can use the password guessing spreadsheet to simulate all sorts of attack scenarios, but the one I often demonstrate assumes the following inputs: eight-character password, complexity enabled, 94-symbol character set, with 90 days between password changes. On average, the attacker could break passwords under that policy with only 65 guesses per minute — not at all hard to accomplish.

I accept no responsibility for the errors in my spreadsheet. It likely contains significant errors and should not be relied upon. Do your own password audit testing to make decisions. And this exercise absolutely ignores all other factors that make up true password strength (system controls, other defenses, physical security, end-user’s brain) and all other sorts of password attacks, such as keystroke logging, side-channel attacks, social engineering, phishing, sniffing, and dumpster diving.

That said, it’s an interesting spreadsheet to play with. I plan to update it as better information, corrections, and improved entropy models become available.

This column would not be complete without mentioning the password policy I strongly recommend. Regular user passwords should be a minimum of 10 to 12 characters long (preferably 12 or more); privileged accounts should have passwords of at least 15 characters, and they should be changed every 90 to 120 days. Disable weak hashes to prevent password hash cracking. I’m not a big fan of complexity — it doesn’t provide as much protection as people think — but you’ll usually have to include it to satisfy auditing requirements.

Enjoy!