SecurityDude, CISSP-ISSAP is an IT consultant, Security & Privacy Advocate and blogger at large with over 20 years IT experience. SecurityDude shares tips, tricks, and info that the average networking professional will find interesting and indispensable.
Over the years, I have read many articles that recommend enforcing complexity as the solution to poor user-selected passwords. Some operating systems like Microsoft Windows Server 2003 enforce password complexity by default.
The conventional wisdom dictates that a password must be at least 8 characters and include both upper and lower case. It should also include at least one number and a “special” character such as “#”.
UTTER RUBBISH.
I would not make such a strong statement without the research of much smarter people than me, and of course “math”. I like to think of “math” as a good synonym for “reality”. First, how does one quantify the difficulty in “breaking” a password? This of course, ‘depends’.
If you are sitting at a Starbucks sipping a Venti, decaf Carmel Macchiato and enter your cleartext password into your unencrypted webmail portal over an unencrypted wireless HotSpot, the difficulty level is about zero. All the attacker requires is a protocol analyzer (like Network Instruments Observer 12) and a wireless card. If you surf to a naughty web site and inadvertently download a software keystroke logger, the difficulty of breaking your password is again “about zero”.
On enterprise networks, passwords are usually stored (and transferred over the wire) in the form of a cryptographic HASH or challenge-response transaction. The strength of hashed passwords are generally rated by the number of hours it would take an arbitrary computer to run through all of the possible input values of cleartext through a given HASH function until it yields a match on the hashed password (via a compare function).
Using the BFTcalc.xls spreadsheet created by Mandylion Labs a few years back, let’s compare the security of a password using the 8 character complexity rule espoused above. For the test, we use an 8-character password consisting of 1 special character, one number, one upper-case character and five lower-case characters. The spreadsheet yields a value of 98,853,048,320 (98.8 BILLION possibilities). Does that sound impressive? In the 1970’s, when even Mainframe computer’s CPUs were capable of only several hundred thousand instructions per second, 98.8 billion combinations would have taken many years to process.
Fast forward to the present. BFTcalc.xls uses a calculation of 2*(2^33) hashes per second (over 17 billion per hour) as the baseline brute force of a SINGLE desktop computer. This yields a time to crack of 2.88 hours on that “average” desktop computer built about three years ago. Are you surprised that a password like “Ph0dedq&” will fall in under 3 hours?
I recommend you remove password complexity rules from your systems and instead require a minimum password length of 13 characters. At fist blush, this idea probably sounds ludicrous.
I solve the long password problem by using strings of unrelated words. Which is easier for a user to remember, “woodgermyelling” (15 characters) or “Ph0dedq&”? I would bet “woodgermyelling” wins every time. As a bonus, BFTcalc.xls calculates that particular password would take 2,033,944,647.08 days to crack on a single computer. That is equal to 5,568,636.95 YEARS. Yes, 5 MILLION YEARS. If you additionally require that users change passwords every 90 days, the odds are very much against a successful brute force attack on your passwords.
I hope you find this information useful.
Tags: Brute Force, Crypto, Passord, Password Complexity
December 29, 2008 at 3:10 pm |
I hate to reply to an article that was posted 6 months ago, but this is incorrect and bad advice on an important topic. First your math is wrong, bruiting a 8 character password with mixedalpha-num-symbol32-space would be 95^8 which is equal to 6,634,204,312,890,625 possible combinations. Even a limited symbol set still yields over 700 Trillion At your 17 Billion/hour estimate thats about 44.5 years to brute the symbol32 set straight up. Second you are ignoring some very important things regarding password security. One of which is that a good cracker is usually not going to attempt a raw brute force, and that he/she only needs one. For instance, “Sm0rg@$b0rd”, would be considered a decent password if one was going to attempt a true brute of every possible combination in the keyspace. However, this is not a realistic assumption, since a hybrid dictionary attack with character substitution, can brute this password in the matter of seconds. The same can be done, and is commonly done, with and without spacing on adjoining words, not to mention the feasibility of a modified rainbow table attack for that keyspace. Doing the math on the simple approach of this assuming no substitution and all lowercase. Assuming a dictionary with about 50,000 (cracklib-small) words, which includes the 3 words you used, to extend to a 3 word adjoining string would only be about 50,000^3 or 125,000,000,000,000 combinations. At even half the speed you suggested, that is less than 2 years to brute (dictionary attacks are slightly slower). This is significantly lower than the password style you are advising against. While this may still seem sufficient, it doesn’t take into account that computers can split this task up to reduce the time, and also doesn’t account for precomputed tables as mentioned above. I.E Using the computer speed you stated, 100 computers could brute your password in about 4 days, which is very reasonable, where it would take about 180 days for the same computers to brute the 8 character password. I realize that if the 8 character password is based off of a dictionary word this hits on the argument above, but this can be avoded by checking the password at creation time, with filters, and user training; unlike your method which advocates this. I understand all this is a wash if the user can’t remember there password after creating it. However, there are several good ways to combat this with good training. Things like making up acronyms as such can go a long way in helping a user remember their passwords. For instance, one could use something like, “I hate to change my password every 90 days. Use the first letter of each word, through some numbers in it, maybe substitute some numbers and throw a symbol or two in there, preferably in the middle. I could get something like this from that, “Ih2cmP!e90ds”. With wise use of this method there is no significant reduction in keyspace, yet it is not any harder to remember that several words, but easier than 8+ random letters and symbols. there is much more that could be said on this topic, but I will end there. Hope this information helps some people out there improve their password selections.
January 5, 2009 at 10:58 am |
Hi Lonnie,
I am surprised that no one has challenged my recommendation until now. The math is correct within the parameters of a password (most) human users are willing to type. I will grant you that the ‘potential’ keyspace is vast if we could force users to include Hebrew, Russian and Arabic characters in their passwords, but that is not operationally feasible for most organizations. Users would rebel against having to type characters that cannot be typed without an Alt-sequence. Example: Alt+00FE (Latin Thorn character). There is also the issue that many users must remember 5 or more passwords to do their jobs. Password complexity dramatically increases the likelihood of users writing down their passwords and leave them lying about.
I am glad you brought up the subject of Rainbow Tables. Pre-compiled hash tables are lethal to weak hash schemes like LANMAN. But because of the processing power necessary to compile the tables, passwords beyond 13-14 characters are prohibitively expensive, both in CPU cycles and storage. If an asset was valuable enough to merit the effort of generating a 15 character hash table, it would likely be protected by multi-factor authentication. Notable exceptions to this are LANMAN and PIX/ASA firewall passwords (14 and 16 characters respectively). Rainbow table attacks are largely ineffective against salted hashes used by many operating systems. The MD5-crypt function uses a 48-bit salt, and bcrypt uses a 128-bit salt.
I have worked with hundreds of companies over the years and I have yet to find an IT director (outside the military) that could sell “Ih2cmP!e90ds” to Mary in Accounting or Pete in Shipping, let alone the CEO. Outside of the Security department, few users would employ that complex of a password (willingly). In the 90’s I contracted to a bank where a Senior VP demanded his Novell password be reduced from 8 characters to 6 and that he only need change it 1 a year. He was dead wrong, but he controlled the IT budget. We grudgingly capitulated.
Thank you for adding your voice to the conversation.
SecurityDude
January 5, 2009 at 1:22 pm |
Correction: The key sequence I used for the Thorn (þ) character SHOULD be Alt-0254.
January 28, 2009 at 7:37 pm |
I was an on-site IT Dir. at a Newspaper and the corporate folk made everyone change their apssword every 90 days, but the Sys Admin had a 16 character password (they suggested passphrase). What do you think of phrase?
February 27, 2009 at 3:22 pm |
I enjoyed your post about password security. That’s one of my favorite topics in my blog (in fact, I wrote something today about how programmers store passwords). It’s really frustrating for me when I have a really strong password and someone does something stupid with it like email my password to me, store it in plain text, or have me verify my social security number as authentication.
I hate when I’m trying to type a password in and I can’t use # or ! or other special characters or I can’t use a password longer than 12 characters. I mean, why limit me on the strength of my own password? Oh well, thanks for the blog post. It’ll get people to use secure passwords, but it’s up to the programmers out there to handle them better.