Hardware Assisted Brute Force Attacks: Still For Dummies

October 24, 2007

Evidently hardware assisted brute force password cracking has arrived:

A technique for cracking computer passwords using inexpensive off-the-shelf computer graphics hardware is causing a stir in the computer security community.

Elcomsoft, a software company based in Moscow, Russia, has filed a US patent for the technique. It takes advantage of the "massively parallel processing" capabilities of a graphics processing unit (GPU) - the processor normally used to produce realistic graphics for video games.

Using an $800 graphics card from nVidia called the GeForce 8800 Ultra, Elcomsoft increased the speed of its password cracking by a factor of 25, according to the company's CEO, Vladimir Katalov. The toughest passwords, including those used to log in to a Windows Vista computer, would normally take months of continuous computer processing time to crack using a computer's central processing unit (CPU). By harnessing a $150 GPU - less powerful than the nVidia 8800 card - Elcomsoft says they can be cracked in just three to five days. Less complex passwords can be retrieved in minutes, rather than hours or days.

GPUs, with their massive built-in paralellism, were built to do things like this. I'm encouraged that we're finally able to harness all that video silicon to do useful things beyond rendering Doom at 60 frames per second with anti-aliasing and anisotropic filtering.

There's a bit more detail on the elecom approach in their one-page PDF. They provide actual numbers there.

Using the "brute force" technique of recovering passwords, it was possible, though time-consuming, to recover passwords from popular applications. For example, the logon password for Windows Vista might be an eight-character string composed of uppercase and lowercase alphabetic characters. There would about 55 trillion (52 to the eighth power) possible passwords. Windows Vista uses NTLM hashing by default, so using a modern dual-core PC you could test up to 10,000,000 passwords per second, and perform a complete analysis in about two months. With ElcomSoft's new technology, the process would take only three to five days, depending upon the CPU and GPU.

Preliminary tests using Elcomsoft Distributed Password Recovery show that the [brute force password cracking] speed has increased by a factor of twenty, simply by hooking up with a $150 video card's onboard GPU. ElcomSoft expects to find similar results as this new technology is incorporated into their password recovery products for Microsoft Office, PGP, and dozens of other popular applications.

It's fun, and it makes for a shocking "Password Cracking Supercomputers On Every Desktop Make Passwords Irrelevant" headline, but password cracking supercomputers on every desktop doesn't mean the end of password-protected civilization as we know it. Let's do the math.

How many passwords can we attempt per second?

Dual Core CPU10,000,000
GPU200,000,000

How many password combinations do we have to try?

528 = 53,459,728,531,456

That's a lot of potential passwords. Let's stop playing Quake Wars for a few days and get cracking:

53,459,728,531,456 /  10,000,000 pps / 60 / 60 / 24 = 61.9 days
53,459,728,531,456 / 200,000,000 pps / 60 / 60 / 24 =  3.1 days

As promised by elecom, that works out to a little over three days at the GPU crack rate, and two months at the CPU crack rate. Oooh. Scary. Worried yet? If so, you shouldn't be. Watch what happens when I add four additional characters to the password:

5212 / 200,000,000 pps / 60 / 60 / 24 =  22,620,197 days

For those of you keeping score at home, with a 12 character password this hardware assisted brute-force attack would take 61,973 years. Even if we increased the brute force attack rate by a factor of a thousand, it would still take 62 years.

Elecom's idea of an 8 character password is awfully convenient, too. Only lowercase and uppercase letters, a total of 52 possible choices per character. Who has passwords without at least one number? Even MySpace users are smarter than that. If you include a number in your 8 character password, or a non-alphanumeric character like "%", attack times increase substantially. Not enough to mitigate the potential attack completely, mind you, but you'd definitely put a serious dent in any brute forcing effort by switching out a character or two.

628 / 200,000,000 pps / 60 / 60 / 24 =  13 days
728 / 200,000,000 pps / 60 / 60 / 24 =  42 days

Personally, I think it's easier to go with a pass phrase than a bunch of random, difficult to remember gibberish characters as a password. Even if your pass phrase is in all lower-case-- a mere 26 possible characters -- that exponent is incredibly potent.

2610 / 200,000,000 pps / 60 / 60 / 24 =  8 days
2612 / 200,000,000 pps / 60 / 60 / 24 =  15 years
2614 / 200,000,000 pps / 60 / 60 / 24 =  10,228 years

By the time you get to a mere 14 characters-- even if they're all lowercase letters-- you can pretty much forget about anyone brute forcing your password. Ever.

So what have we learned?

Brute force attacks, even fancy hardware-assisted brute force attacks, are still for dummies. If this is the best your attackers can do, they're too stupid to be dangerous. Brute forcing is almost always a waste of time, when vastly more effective social vectors and superior technical approaches are readily available.

Hardware-assisted brute force attacks will never be a credible threat. But short, simple passwords are still dangerous. If your password is only 8 alphabet characters, and if it's exposed in a way that allows brute force hardware assisted attack, you could be in trouble. All you need to do to sleep soundly at night (well, at least as far as brute force attacks are concerned) is choose a slightly longer password. It's much safer to think of your security in terms of passphrases instead of passwords. And unlike "secure" 8 character passwords, passphrases are easy to remember, too. Have you considered helping me evangelize passphrases?

Posted by Jeff Atwood
86 Comments

Of note-- in 1998, the EFF built Deep Crack: specialized hardware designed for the express purpose of key cracking.

http://en.wikipedia.org/wiki/Deep_Crack

Deep Crack could test 90 *billion* (90,000,000,000) keys per second.

At that rate, it would crack our 8 character alpha password in 10 minutes .. but a 12 character alpha password would take 138 years.

Jeff Atwood on October 24, 2007 3:55 AM

"53,459,728,531,456 / 200,000,000 -- ppm -- / 60 / 60 / 24 = 3.1 days"

Oh, that's why these numbers are not adding up correctly. I look at "ppm" and I think "passwords per minute." But you really mean passwords per second (pps).

Nicholas on October 24, 2007 4:04 AM

Hobbyists have been doing this already: http://nsa.unaligned.org/

Sorry for the soapboxing, but hopefully the patent will get denied. Is it really that large a step from "oh I have a general-purpose processor" to "let's use it to break keys"?

Evan on October 24, 2007 4:06 AM

While brute force is impractical in most cases, it seems possible for highly distributed system to be practical for most common password lengths. For example suppose we use the following formula:

26^12 / ((storm worm infected machines) * 10,000,000) ppm / 60 / 60 / 24 = X years.

I use 10,000,000 as a baseline for most modern machines. One could assume that you could use the higher 200,000,000 number if most machines had a fairly decent video card installed.

The range of storm worm infected machine falls between 1,000,000 and 10,000,000, so lets just assume 5,000,000.
26^12 / (5,000,000 * 10,000,000) ppm / 60 / 60 / 24 = 0.02 days (about 30 minutes).

26^14 / (5,000,000 * 10,000,000) ppm / 60 / 60 / 24 = 15 days

Assuming worst case (10 million infected machines with nice GPUs) we have the following:
26^14 / (10,000,000 * 200,000,000) ppm / 60 / 60 / 24 = 0.37 days (about 9 hours)

Obviously I can still defeat this theoretical distributed cracker by making an even longer password with more possible symbols, but I think it is good to know what password length can be theoretically cracked by modern hardware.

Stormy Weather on October 24, 2007 4:23 AM

so I guess I'll be good with my 15 char password for a while

Eber Irigoyen on October 24, 2007 4:25 AM

...that contains upper/lower/numbers/signs =o)

Eber Irigoyen on October 24, 2007 4:27 AM

I see so many articles about password security lately. I think one of the much more important issue is password IMPORTANCE. I use some crappy six letter, no number default password for the vast majority of things - for example, if I had to sign up to post comments on this blog, I would use that. For the longest time, I felt guilty for that, but nowaday I realize, it's actually good.

For emails, I use a different, ten letter, 2 numbers password, that I would have to look up if I reinstalled my email client (it's a sequence found physically inside my house, but not written down - something such as the first letter on the first ten pages of a favorite book, although it's not that anymore).

For actual, important, critical issues (such as PayPal, eBay, basically what could cause me actual damage), I use one completely random password with 12 letters, numbers and special characters for every service, which are written down on a piece of paper stored inside the safe of my dad. I also do not store these in my browser or similar.

The point I'm trying to make is that I have passwords aligned at tiers of actual importance. My blog identity might seem important, but when you think about it, it really isn't, at least if compared to my bank account or eBay account. They are tiered by importance and convenience. My "system" pays heed to both the fact that you can't remember two dozen passwords that are reasonably complex every day, and at the same time you wouldn't want to put in a default password, no matter how complex, in every other site.

J. Stoever on October 24, 2007 4:31 AM

Oh, and as for the article, the increase is only by a faction of 20. That is really not relevant when it comes to password security. We all know Moore's Law, and we all know that if a password can be cracked in a time that is slow enough to become an issue when divided by 20, it's lifetime is something like 2-3 years or less anyways. Might as well choose "Joshua".

J. Stoever on October 24, 2007 4:35 AM

While all lower case pass phrases increase the keyspace exponentially, they do nothing to prevent sophisticated dictionary based brute force attacks. I think the fault in your preference for pass phrases is assuming that all brute force attacks treat every permutation of the available characters as an equally probable match.

Plus, who wants to type a book for their password every time they need to log in, especially multiple times when they inevitably screw it up. The average typing speed is painfully slow too ;)

Caleb on October 24, 2007 4:36 AM

Pretty soon, though, we'll end up grabbing passwords that have obscure symbols in them. Symbols who's alt codes we have to type on the numpad while alt is held down because the keyboard doesn't have it by default...

Matt on October 24, 2007 4:42 AM

#8776;.#9792;#9786;#964;!#9566;#9619;
That's my everyday password. ;)

Matt on October 24, 2007 4:45 AM

When you say that Hardware assisted brute force attacks never will be a credible threat, do you mean to you and your company (and anyone else using longer passwords) or to the world at large? Because you wouldn't disagree that they can be a credible threat to anyone with an 8 char password, right?

In short, are you assuming that there aren't a lot of 8 char passwords out there?

/Mats

Mats Helander on October 24, 2007 4:48 AM

I think what he's saying is that they won't be a valid security thread, just like super safe cracking experts are not a valid security issue for companies who have their safe combination on a yellow post-it next to the safe.

J. Stoever on October 24, 2007 4:56 AM

Just wondering - of the people here that use pass phrases, do you use all common words, or mix in proper names and unusual words?

Here's an example - which of these would be easier to hack, assuming the hacker knew it was a pass phrase?
"I do not like green eggs and ham."
"Ben Kenobi went skiing in Mordor."

Krenn on October 24, 2007 5:05 AM

But you really mean passwords per second (pps).

You're absolutely right. I corrected this mistake.

I see so many articles about password security lately. I think one of the much more important issue is password IMPORTANCE

Well, yes, passwords themselves are part of the problem.

In short, are you assuming that there aren't a lot of 8 char passwords out there?

I'm saying there's a lot of "password1" out there. If you're brute forcing that, you're the stupidest attacker ever. Consider how difficult it is to conduct a legitimate brute force attack, anyway-- one involving millions of attempts per second. It has to be in some kind of offline mode, perhaps against the password file or database.

The only real solution, as I see it, is to educate users on the benefits of passphrases.

Jeff Atwood on October 24, 2007 5:16 AM

Watch out with passphrases, they do need to be longer than you think.

As you point out in your previous article, English words are not sequences of random characters, so although a passphrase might be 10 characters long, a cracker will not need to try all possible 10-letter combinations, and not all combinations of words. Even if you include numbers and add some capitals, especially if you do them in grammatically correct way, the amount of information in a 12-letter passphrase is much less than in 8 random letters. Even throwing in the odd leet substitution won't help that much if the passphrase is mostly English and the cracker is trying passphrases in a semi-intelligent order.

e.g. Using some kind of combinatorial reverse-markov-chain generator that creates sentences in probabilistic order, and doese leet/capitals/number substitutions as it goes.

See also:

http://en.wikipedia.org/wiki/Information_entropy#Entropy_as_information_content

You only get about 1.3 bits of entropy per character in English. So a 10 letter password in English is ~13 bits, or ~8192 combinations. 20 letters gets you ~26 bits which is ~128,000,000 combinations. Or just over half a second of computation. Oops.

OK, I've oversimplified. There's more entropy in short sequences than long ones, so it's not quite as bad as all that. But it's still not good.

Karellen on October 24, 2007 5:31 AM

Of course, my bank requires PINs to be 4 digits in length...

when I told them that was completely useless, they told me it was for "convenience"

Theirs or mine?

Steve Bush on October 24, 2007 5:39 AM

If someone had access to your Vista machine* so that they could add extra hardware to do the cracking, surely then they could just stuck in a Damn Small Linux Live CD and just mount the hard drive and read it like that?

The last thing I'd care about if someone had physical access to my machine is someone adding a GPU! :)

(*For the record, I don't have/want one of these anyway!)

Ben on October 24, 2007 6:30 AM

I think you're being a bit harsh on this technology. A system that can try potential passwords very fast is an advantage because it can be combined with a smarter search tool that searches all the obvious spaces quickly. A good system would have a database of patterns that people use for passwords and try those first. Longer passwords that have a certain pattern: 555556666677777 or five5six6seven7. Both of those are long passwords (18 chars and 15 chars), but have a certain pattern to them that could be coded into a search system that could search all similar permutations very quickly. If you had a database of thousands of actual passwords that real people use (e.g., the set of passwords used by users on a popular web site), you could make up patterns that would allow searches of technically longer passwords. In any case, if this tech is valuable to dumb brute force searches, it will also be valuable to "smarter" searches.

Also, as others have noted, this is only useful when you can search the password space independently of the system you are trying to break into. A real system (such as a bank ATM) would lock you out after some number of failed attempts and force you to verify your identity some other way before letting you try again. However, cracking a .zip file or office document that you have access to is an example of a system where you can try as often or as quickly as you want.

Brendan Dowling on October 24, 2007 6:58 AM

As Karellen hinted at, it is extremely taxing to remember passwords with enough entropy that they cannot be cracked with current hardware.

Sure I could memorize a GUID and use that as a password, but that's not easy. The most random password most people will come up with is randomly-capitalized first letters of words in a sentence they remember -- the search space here can be limited by relative frequencies of letters at the beginning of English words.

To paraphrase Bruce Schneier: You can't memorize passwords complex enough to be uncrackable, so don't; Generate some long, random passwords and write them down on a card you keep in your wallet.

Eam on October 24, 2007 7:16 AM

My personal favorite password strategy - pick a word 6 to 8 characters long, then in that word, randomly pick 3 or 4 letters and replace them with their ASCII code. So long as you can remember the word, and roughly which letters you type, you can figure out the missing ASCII. Plus you eventually learn most of the 6583677373 codes. That's leet.

Dave on October 24, 2007 8:21 AM

Passphrase in leet:
1don7L!k3gr33ne99sH@M

Timbo on October 24, 2007 8:38 AM

Ummm....hey...
Could social-networking (who said MySpace!?) and/or their seedier cousins (who said AFF/porn!?) actually be fronts for password harvesting? Could the harvested password data then be hypothetically used as a training set for some AI routines to deduce patterns in password selection? Could the routines hypothetically deduce the 'human element' from a large enough initial data set (or, a constantly growing data set)?

Harvesting by day, training by night, raids against ecommerce/banking/etc on the weekend?

inspired by:

e.g. Using some kind of combinatorial reverse-markov-chain generator that creates sentences in probabilistic order, and doese leet/capitals/number substitutions as it goes.

TTFN,
Tarkin

Tarkin on October 24, 2007 8:47 AM

Do those 8-char timings include passwords less than 8 chars?

hmm on October 24, 2007 8:55 AM

A minor point, but don't forget the times quoted in the article to crack a password are worst-case -- the average time will be half the quoted amount, for each.

Mark S on October 24, 2007 8:56 AM

[passphrases] do need to be longer than you think.

This is a complete and utter myth. We can't even do proper machine translation, much less generate a complete set of all possible sentences-- there are FAR more possible words and combinations than ASCII characters in any given position. This was discussed to death in the comments at the URL below, so please read through those before immediately responding.

You can't memorize passwords complex enough to be uncrackable,

Oh yes I can. Here's an example password that's brainlessly easy to memorize and uncrackable.

"I drive a 1998 Ford Contour."

http://www.codinghorror.com/blog/archives/000342.html

Jeff Atwood on October 24, 2007 9:45 AM

Hey, guys. Before criticizing people for choosing 8-character passwords, remember that many online services don't even allow for anything longer than that. :-)

Felix Pleoianu on October 24, 2007 9:54 AM

Brute Force, even if it's as "advanced" as presented here is just silly because it presumes to have the kind of access it would never have to a truly secure system. Think about it, the method presented here presumes it can just brute force passwords as fast as hardware (in this case a GPU) will allow.

But what happens if the system locks you out from trying passwords after 3 consecutive failures? And I'm not even talking about -long- lockouts... those tend to be inconvenient to legit users. What if we made the lockout a mere, say, 30 seconds?

Let's try some math shall we? Unless I made a mistake somewhere, this should be correct. Simply a matter of adding 30 seconds for every 3 passwords to the actual hardware time, right?

Without lockout: 53,459,728,531,456 / 200,000,000 pps / 60 / 60 / 24 = 3.1 days (as per this blog)
With lockout: ((53T / 200M pps) + ((53T / 3) * 30 sec)) / 60 / 60 / 24 = 6187468583+ days (16940365+ years)

Oops. There goes all their effort, dwarfed by the time they spend waiting to be allowed to try the next password.

Mike on October 24, 2007 10:12 AM

@Jeff "Passphrase" Atwood:
Oh yes I can. Here's an example password that's brainlessly easy to memorize and uncrackable.
"I drive a 1998 Ford Contour."

That's just 5 dictionary words and a common number (recent year). It's "brainlessly easy to memorize" because has a very low amount of entropy. Maybe the average rainbow table out there now won't get it, but it just requires a different type of (no more sophisticated) attack.

The only way you can make a password more secure against any type of guessing is by adding real entropy, and there's only so much entropy a person can easily memorize.

Don't get me wrong, I agree that using such a passphrase would be secure against most types of attacks we see today, but only because it's such an uncommon thing to do. If everyone was using passphrases, we'd see rainbow tables and dictionary attacks for passphrases.

I don't see anything in the comments in the link you give that directly addresses the point Karellen and I are making. In fact, it seems you were seriously underestimating the ingenuity of some crackers and legitimate software developers alike:

"I guess the hypothetical attack tool you are talking about would have a complete command of English (and perhaps other languages/words/grammatical errors that might slip in)? I don't know how it would know what capitalization and punctuation rules make sense to try, or even which words statistically follow other words. I am not sure this attack tool you're describing A) even exists or B) is possible to create."

This is more or less how Google's translator works. It's also how I would go about cracking a passphrase. Note that it's not a *complete* command of any language - it's all about heuristics. All passwords humans come up with have characteristics and patterns in common (just like their languages). If we can come up with the right statistics on passwords/languages, we can (and usually do) limit the search space enough to make password cracking feasible.

Eam on October 24, 2007 10:27 AM

Mike:
Copies of databases are stolen all the time by crackers and insiders. We don't even know about most of these incidents. After California passed a (pretty dodgy) disclosure law, we found out that Citigroup leaked data on 3.9 million people!

http://www.schneier.com/blog/archives/2006/04/identitytheft_d.html

Your "three tries and you have to wait" security doesn't help too much in these (common) cases. Of course, we need to get big companies to stop storing passwords in plaintext or symmetrically encrypted text before we should even be worrying about password strength.

Eam on October 24, 2007 10:32 AM

Jeff:
Sorry for the flood of comments, I just wanted to add one more thing.

I think we're not seeing eye-to-eye because you're talking about cracking passwords with a 100% probability of success. In the real world, if a target system has 10 administrators, you only need a 10% chance of success. This is why heuristics can be applied to pretty much all human-generated passwords with great practical results.

Plus, it's hard for a human to repeatedly make his password 10x better, but the attacks become better and better at an alarming rate -- whether by faster hardware or better cryptanalysis methods. These Russian jokers saw a 20x increase in speed just by finding and exploiting parallelizable aspects of an existing encryption algorithm (I imagine this is what they're patenting, not the use of the GPU per se). I'm sure similar properties exist in all major cryptographic algorithms, and we'll find them sooner or later.

Eam on October 24, 2007 10:52 AM

@Eam

Well, you pretty much answered yourself there with the last paragraph.

You're right, the 3-tries-lockout method doesn't help in those cases. But then, it's quite obviously not meant to. That's a whole different scenario. This blog post, unless I'm mistaken, is about brute forcing -passwords- and not password hashes. And -that- can be effectively prevented with 3-try-lockout.

Password hashes are a different story, but can also be effectively secured. Due to the "recent" advent of hash-to-password lookup tables for most common hash functions, it's obviously not a good idea to just md5() your passwords (I'm not even going to touch on not encrypting or using symmetric encryption; we're talking security here after all, not non-security).

Instead, it's much better to use a custom, secret hash function that adds complexity and obscurity by means of nesting hash functions, using salt, using constant values besides the password (like the username), scrambling the hash(s), etc... or any combination thereof. Essentially using something unique to your service and preferably unknown to potential attackers even if they manage to get their hands on your database.

Mike on October 24, 2007 11:20 AM

Er, my apologies... I AM mistaken, this is about brute forcing hashes. That's what I get for forgetting to drink my coffee. :(

In that case though... the real issue here is not secure passwords but security of the system itself. Like you pointed out, it's all too common that even large companies leak sensitive information or entire databases. THAT is the real issue.

After all, if someone manages to get their hands on a dump of a large companies database, there's more than just password hashes in there already. And if someone has physical access to the machine itself, well... then it's all moot anyway because they can do whatever they want with it.

Mike on October 24, 2007 11:37 AM

Mike:
I'm not sure I see the distinction you're making between brute forcing passwords and passwords hashes. I'm sure in the vast majority of brute force attacks, the attacker has the passwords hashes.

But I have to ask you, please don't use custom, secret hash functions or security methods. There are well-documented methods for storing passwords and challenge-response authentication that are both mathematically sound and proven in practice. If an attacker has access to your database, he probably has access to your source code as well, in which case security through obscurity fails miserably.

And one more thing, avoid MD5 altogether if you can. It's better than nothing, but there have been successful collision-producing attacks against it. There's usually no reason not to use SHA-2 at 256 bits or higher.

Eam on October 24, 2007 11:47 AM

I just have a ruleset for creating passwords based on the name of service, type of service(bank, email, forums etc) this keeps me feeling reasonably safe and i am yet to forget a password.

I also like to throw in repeating characters into that because people watching your hands type can rarely pick up on the double taps.

Steeeeve on October 24, 2007 12:01 PM

@Eam

"But I have to ask you, please don't use custom, secret hash functions or security methods. There are well-documented methods for storing passwords and challenge-response authentication that are both mathematically sound and proven in practice. If an attacker has access to your database, he probably has access to your source code as well, in which case security through obscurity fails miserably."

Why not?

Even if we assume an attacker has access to the source code with the custom chain of hash functions (which as you correctly point out voids the obscurity), there's still the added complexity and unique nature of the hashes.

For example, compare:

myhash = sha512(password);
myhash = sha512('mycustomsalt' + sha512(username) + sha512(password));

You can't possibly be saying the first is just as secure as the second? The latter...

- Can't be reverse mapped with a vanilla lookup/"Rainbow" table (at least not the top level sha512)
- Would require a separate lookup table for each user (if the attacker is willing/able to build custom ones)
- Would take at least twice as long to brute force for a single user (assuming most of the cpu time is spent on the hash functions and not on comparison or concatenation)

And it doesn't have to end there. You could nest them further, use different hash functions, split up the username and password or scramble them (take every odd char from username and every even char from password for on hash; and vice versa for a second) and so on and so forth. You can add as much complexity as you like.

"Security through obscurity" is never a good thing to rely on, that's (or should be) common knowledge. But that's not what this is. This is security through complexity (takes more cpu cycles to generate each hash) and through uniqueness. And we can all see just how much lack of the latter compromises security by looking at Windows and IE.

If everyone uses the same method for storing passwords then eventually someone will find a way around it. No matter how mathematically sound or practice proven it is.

Mike on October 25, 2007 2:02 AM

Get your free passwords:

G6Zjk#_I@}VeW1}Q~@Z~SP=-bw.W!bU$K#:Q/%W}*y)9+!D(k8b.*YZ%a'*ew!t^jPsTtlm,IyMKRn

$}lkVo's~/7%@lR/D6{Y$7Hc'0f!Q_1ok7NxJW7B*C^Lj`rHDY2o2bj{T/NJ+NY3)$yhm-"[nQaQR2

Zo3Xr4Xsx^\lE0}Cqs5-['1?xuwPQjNFX3M^dd6bJ#!{,M//4A/bM1w%[,yi-gn`M36'-oNPcjFG

KGqYY1wR'e8hRG$pQGJry9o|[nQ!\A/i*S}~%Qd@$5U3Js.!B!`bkNSZgZ9dvErn52"UtaZP2z@a1|

v(o''qk+?ZL%:=85"1N1$M|!`H:'nvid/iAcGwb-NsA{G4xv@Z_TIWO3jdcS~PI{#UgA]|"#V%@#_

/pO.{:d$m)3vGIdL4edX!Tf8Aht6#t$O?H-XVo/Xq8|@!FG'5P^3(kT,OLnrp:|o+._rd~T.*pRWC

The only problem with passwords like this is the limitation for webpages and programs to save and read them! Also, they are hard to remember.

Can someone solve a math problem for me? (80^94)

TIA
KEN

Ken on October 25, 2007 2:28 AM

@Mike

The salt needs to be random, and different per password. Basically, what you intended the username for. The username is just as predictable as the password in the cases you care about.

Also, you want to use a hash function that isn't designed to be fast (including basically any hash function useful for message signing). The idea is to make calculating hash(salt + dictionary) as slow as possible, while still processing a login in a user-acceptable amount of time.

cwillu on October 25, 2007 2:32 AM

Im still glad to see at least windows vista has upgraded it's passwords by default past the old LM hash which you used to be able to crack 14 letter passwords in 10 minutes on new hardware. Next for windows password salting by default.

Pete on October 25, 2007 2:34 AM

Mike has a good point earlier on about adding a 30 second lock out period, it shifts responsibility away from the user to the designer. Honestly, what good security designer would allow brute force attacks to even be possible?

Let's assume you have a web application. Let's also assume that you log all login attempts. Why not implement a simple method that prevents any user from trying to log in more than once every 2-3 seconds (if (time = lastLoginAttemptTimeStamp+3) /* allow login */ else /* error page */), about the delay you'd expect an online refresh to take and nothing the average user would get pissy about because they would never even notice. However, crackers would notice because even a distributed password cracking attempt would be slowed to a crawl with every login attempt on a user being checked synchronized to a moderated login schedule.

The point is: it is up to security designers to make sure that brute force is a waste of time no matter how short or long the required password length is. The password is an authentication token, not the length and measure of all computer security.

James on October 25, 2007 2:47 AM

I think they mention 8 char passwords because of NTLM limits. It's been many years since I last looked at NTLM, but I remember they truncated your password and split it into two pieces (2x 8 chars), so it doesn't matter how complicated and long a password you use, it will still be easy to break.

The hardware assisted cracker may therefore simply reduce the upper bound for the time required to break and make cracking more convenient.

Charles Darke on October 25, 2007 2:59 AM

My passphrase:

"I've ridden in a 1998 Ford Contour with Wumpus on front"

http://www.codinghorror.com/blog/archives/000515.html

Jarrod on October 25, 2007 3:01 AM

@james

Brute force is already impractical against most webapps:

First, bandwidth already limits the number of attempts per second, and any production service should take your advice at the very minimum.

Further, it's the server that takes the load in this case, so unless you were planning on breaking into google hq so you can install a couple gpu's...

Finally, all of this still only targets one account at a time. Such an approach isn't very efficient, unless the attacker has a particular target in mind.

Presuming of course that the app doesn't simply crash from the load :p

The vulnerability for most sites is what happens when the password database somehow is compromised. It happens all the time. And if the designer didn't take that properly into account, then the database might be vulnerable to all sorts of attacks.

Granted that any particular user can take steps to lower his exposure (presumably his account is just as compromised as the password database itself), but the fact is that most people reuse passwords. But just because they're gonna be bit by _some_ site's poor practices doesn't mean they should be bit by _your_ site's poor practices.

When my password database is stolen, I want to be the guy who can respond with a press release including my code together with an audit that states that my clients should consider changing their passwords some time in the next few years.

cwillu on October 25, 2007 3:15 AM

Some above have mentioned using lockout periods for login retries, or 2-3, or 30 seconds. Why not use some sort of binary backoff (a la collision avoidance)? No maximum tries before lockout, but brute forcing a login becomes infeasable.

Also, all my logins are perl one liners. It's hard to get a higher entropy than that!

cog on October 25, 2007 3:28 AM

Quick points:

Eam It is easy for a user to make a password 20x better. 20 26, which means you only have to add 1 random lowercase letter to a password to do that. Or, 20 2^5 which means you need less than 5 extra bits of entropy, which is going to be only 3-4 letters (worstcase) in a passphrase.

Mike What Eam said - *never* use a custom hash function. Use an off the shelf one. (Look up Schneier's law. This applies to hash functions as much as crypto algorithms. Anything custom is almost certainly going to be much worse than a published, peer-reviewed and well-attacked algorithm.)


Jeff, I don't know of an existing tool to do this, but...

Take a good size corpus of English text and generate a Markov model of it.

As you create the model, if you come across a word that matches a name in your Cracker's Name Database (e.g. "John" or "Smith"), or just a word starting with a capital letter that is not at the beginning of a sentence, tag it somehow in the model with "name". Do the same for numbers - tag them so you can easily tell they're a number. Dates would be good too. If you can grab "January 15 2005" as a single token and mark it as a date, brilliant! Ditto times.

Create indices for your Markov model for previous word and order of probability. You want to be able to look up by previous word in O(1), and by order of probability in O(1).

That can be done beforehand.

Then, to generate passphrases, go through all one-word passphrases, starting with the word most likely to appear at the start of a sentence, and finishing when you get to the word least likely to appear at the start of a sentence (but still non-zero possibility) Then two-word passphrases; Start with the most common word, and it's most common successor, etc....

When you hit a "name" token, first try that name, but then try all the other names in your Cracker's Name Database. Ditto numbers - try the number first, and then numbers "close to" that number, and/or round numbers near that number. Ditto dates.

Add leet. Try the, say, 10 most common leet substitutions on words. Say for an average 4 letter word, 2 of those could be leetable, giving you 4 possible combinations. Try the, say, 16 most likely leet substitutions for each word? Then ALL-UPPER, CaMeL1, cAmEl2 and Initial Caps.

You could also try replacing_spaces_with_underscores and removingspacesaltogether.

16 leet substitions + all those gives me an extra 1024 combinations per word to try, but meh. There aren't that many words.

Let's say we've got a vocabulary of 10,000 words. How many of them are valid (p 0.001?) at a given point? Um - I'm going to guess at 1,000 here. I've no idea how accurate that might be.

So, that's:

1,000,000 1-word phrases (negligible)
1,000,000,000 2-word phrases (5 seconds)
1,000,000,000,000 3-word phrases. (5000 seconds ~ 1.4 hours)
1,000,000,000,000,000 4-word phrases (5,000,000 seconds ~ 57 days)

Hmmm....and cracking your 6-letter passphrase will take a million times longer than that.

OK, that's starting to take a long time. Maybe moving on to longer passphrases before exhausting *all* shorter ones might help. Or maybe there are less than 1000 valid words at any given point. But that's the idea. But it will certainly get your passphrase before a brute-force alphanumeric would. 63^28 (~10^50) tests by my calculation, using upper, lower, numbers and space, compared to 10^24 tests for mine.

Karellen on October 25, 2007 3:35 AM

How about 'malformed' passphrases?
"1 drive a l998 Ford Cotnour!"

Gonzalo on October 25, 2007 3:37 AM

All fine and good until someone finds a weakness in the hash and then everything cracks in seconds.

Security is like a wall - only as good as the weakest point, be that your password or the hash or the hardware to crack it on.

And just like walls, eventually all security falls.

And hey, if someone really wanted to see what is on your computer, it would probably be easier to add in a cheap keylogger behind the computer where the keyboard plugs in. Not a lot of security there.

And hey, if the person has a wireless keyboard, why even bother with that!

Xepol on October 25, 2007 4:19 AM

nobody seems to have realized that besides ASCII there are international caracters that crackers dont take into account. In Spain it's quite common to use our beloved "enye" (can't write it from this iphone, dammit) that for example is used on our country' local name. And I guess other special letters are used in countries such the escandinavian ones... not a bad practice IMHO.

Great, great blog Jeff. Congrats!

javipas on October 25, 2007 5:11 AM

What about using CAPTCHAs beside the password? with CAPTCHAs brute force attacks would take a very long time (assuming you have a very efficient OCR application).

Muhamma Adel on October 25, 2007 5:12 AM

As some have mentioned, you might use markov models to reduce the search space for passphrases and really the only ultimately secure way to avoid that is to add real entropy. I have combined both of those to automatically create secure passwords. I generate random words using a markov model of the target language and calculate the entropy of the resulting word(s). This way I know the search space size for even the attacker with perfect knowledge. Thanks to the language model the words are reasonably easy to memorize and not too long. If I control the hashing then as already has been mentioned, always use a random salt with the length of the IV of the hash and raise the cost of the hash function to reduce brute force speed. (I use PBKDF2 for this, see RFC 2898) For the markov chain word generation example see Yould, allthough this is dead simple to implement yourself, you just need a sizeable corpus of text to get good results.

Ants Aasma on October 25, 2007 6:08 AM

It's one thing to generate millions of passwords per second. Quite another, time wise, to enter them into the program requesting the password. Or comparing (string compare?) the generated hash with the password hash.

If we generate a list of hashes, do we sort the generated list and do a binary search? If not sorted, we'll have to do a linear search. There goes the timing benchmark.

Are we almost done hashing :-) this out?

Les on October 25, 2007 6:40 AM

The reason we're not seeing any (or lots of) tools to crack passphrases is the extremely simple: you can't use them that many places where a brute-force attack would apply, and furthermore, where brute-force attacks do apply they're typically quite optimized.

If the world was using passphrases you'd see tools to crack those. Just like you're seeing dictionary attacks on passwords now.

@Charles Darke: WinXP and below using default passwords will split them into 2 groups of 7 characters. Not 8.

Kind regards
Fake

Fake51 on October 25, 2007 6:54 AM

Karellen, your rough time estimates are missing a crucial factor: the search will pick the most likely words first in each position.

'I' and 'a' are so common that they'll be among the first words it tries, especially at the start of the sentence. The search will probably be significantly faster than your worst-case time.

Laurie Cheers on October 25, 2007 8:48 AM

Nobody has mentioned Enhanced Authorization/Two Factor, authorization. You probably already see it on most of your banking websites. The site recognizes a single PC as your primary machine, and if you access from a different machine it asks you a personal question, like mothers maiden name. With that additional level of security brute force attacks are irrelevant.

Dan on October 25, 2007 9:00 AM

I often train, on a very basic level, older people (60+) to use a computer.

"If it's stored on a computer, and someone wants it badly enough, they are going to get it."

That's the phrase I use when a novice computer user asks me if they should store sensitive information on their home computer.

I always follow up with a brief lecture on pass phrases and the importance of splitting a word with a number(s) if the host limits the number of characters a password can contain.

I also remind them that they are "small potatoes," and to not be too frightened by using services like Ebay or any Bank-from-home as long as they use caution.

Is this, roughly, a good way to go about things?

I really enjoy this blog because it addresses a lot of usability issues that I encounter when dealing with older people. So thanks, Jeff, for helping to help old people!

Ira Knight on October 25, 2007 9:11 AM

The problem with passphrases is generally they are usually succeptible to dictionary attacks. The problem with 14 character passwords is no one can remember them, and everything has different standards so you can't meet them all with one password. One suggestion is to have a good base password - like f0Rk$ - then add 5 letters of the place requiring the password, if it is amazon.com add amazo - password is now f0Rk$amazo.

If you always use the same firefox instance, there is an extension that generates a random password within the limits of the website, and remembers it. That way you get an extremly complex password you don't have to remember. Set a good master password, and even local access won't give you all the passwords free. The only problem is sites that firefox won't store passwords for (like wellsfargo.com) or sites that use alternate passwords (like hsbc.com point click passwords).

Since you don't even know your password, to protect against loss, either
- store a backup of these passwords in a truecrypt volume somewhere else (use another ff extention - password exporter) OR
- don't worry about it - if you lose your PW just do the PW reset to have it sent to your email.

Which brings up another point, make certain you set a unique password for your email. Don't store it locally, and make sure your provider locks out attempts after a few failed password attempts. If someone gets into your email, you are sunk.

jambarama on October 25, 2007 9:24 AM

I agree with Ira - any mass market end user security can easily be broken by someone who wants it badly enough. It's like that old BIOS password, or nowadays Windows login passwords: People feel it protects their PC, but all you needed was a screwdriver, or nowadays even only a bootcd and you could get to the data within seconds. And just as easily you could beat the vast amount of security systems today with a tiny little keylogger. Bam, there goes your super secure password.

His (?) other point is very valid too: *IS* someone going to invest time and effort into trying to crack your password ? The answer is likely going to be "no", and instead of discussing pass phrases and numbers in passwords, I feel it would be much more effective to teach people how to not become a target: Don't put your email address on shady web pages. Don't click on spam. Don't fall for those phishing sites.

When Granny walks through a bad part of the town at night after withdrawing money, all the security and care when choosing a combination for her bank password won't help her.

Practically all the getting screwed people experience works via social engineer or (physical!) brute force. I doubt there has been a reasonable number of people been screwed over because someone brute forced their 5 letter passwords, and I doubt there ever will be. It's simply not the most effective way, because despite all flaws, even bad passwords are still way harder to crack than sending out phishing emails to a million morons. Passwords are not and never have been the weak link in security.

J. Stoever on October 25, 2007 9:37 AM

also, if you get the password wrong 3 times you get permanently locked out of the system or until an admin unlocks the account. surely that makes any of these attempts futile?

hello on October 25, 2007 9:44 AM

The numbers listed are the absolute worse case right? So statistically, the time to crack the password is actually going to be roughly half the time listed on average.

It's kind of a meaningless distinction though, as 5,000 years to crack a password is not really any less safe than a password that takes 10,000 years to break -- the MTBF of the equipment is going to be the limiting factor after some point.

Timothy Lee Russell on October 25, 2007 10:03 AM

J. Stoever brings up an important point.

Here at where I work we're wrapping up a CISP/PABP compliance pass, and they have a ridiculous set of things one is supposed to do, both process- and implementation-wise, in order to get certified for credit card processing.

However, none of their requirements can prevent the most common way people's CC data actually gets stolen in the environment we work with - keylogging software or hardware attached to the POS computer.

(Or, for that matter, Iwaiters swiping your card on their own reader/i or photographing it with their phone camera.

People are all fired up worried about someone cracking their eBay password, yet they hand a Icomplete stranger/i their actual physical card most every time they go out to eat!)

Sigivald on October 25, 2007 10:25 AM

What happens when you start using these GPUs to implement rainbow tables? That's what worries me.

Kraln on October 25, 2007 12:19 PM

This is more or less how Google's translator works.

And have you seen how well that *doesn't* work?

http://blogoscoped.com/archive/2007-10-23-n54.html

That's just 5 dictionary words and a common number (recent year). It's "brainlessly easy to memorize" because has a very low amount of entropy. Maybe the average rainbow table out there now won't get it, but it just requires a different type of (no more sophisticated) attack.

The attack you're describing is completely improbable to the point of ridiculousness. Just because you can describe something does not make it so. I can describe lots of things that sound very appealing, but are impossible in practice-- that's called "The God Algorithm". Show me one single real world implementation of a pass-phrase cracker that could break:

'I drive a 1998 Ford Contour.'

If that kind of attack is so "unsophisticated", show me a tool that can do it.

Jeff Atwood on October 25, 2007 1:13 PM

Elecom's product attacks not just Windows Vista passwords, but a wide variety of passwords on a lot of different products (MS Word/Excel, Acrobat, Quicken, etc), as you can see here:

http://www.elcomsoft.com/edpr.html

The length of the pass phrase is irrelevant! The relevant thing is the length of the stored, hashed value, or the password/phrase, whichever is shorter

This isn't quite right. Even in a rainbow table attack, you're attacking using cleverly linked pre-computed hashes from *generated passwords* -- you never actually "attack" the hash itself.

In a traditional brute force attack, you'd never see the hash-- your code is using generated passwords and repeatedly attempting to open the PDF, or access the website, or what have you.

Jeff Atwood on October 25, 2007 1:50 PM

Am I the only one thinking how much more BS-RAC I could get in SETI@Home with this?

Atario on October 25, 2007 1:54 PM

My password: (N#c@bub,Iv{*{P`\=|7RbBZYjIb37m{`:!3R4i_BKK8$3-g`wOaR_qDK=Psjd3\0iwVjHG"L4IssY

So with my character set of [a-z][A-Z][0-9][+|\';/.,}{:"?`_)(*^%$#@!~=-][] there are 94 possible characters and a password length of 80 characters, so that makes 94^80 password possiblities.

This comes out to: 70,831,801,567,220,716,246,837,892,378,
711,076,995,107,590,018,336,991,237,446,
616,560,952,575,252,565,205,806,113,305,
457,006,260,943,190,445,617,340,073,590,
087,132,329,381,328,917,490,245,668,948,
227,915,776

Which took an hour this morning to figure out without any advanced calculators.

It also comes to: 7.08x10^157


How many hours would it take you to crack that?

(not my real password, just generated a similar one.)

Ken on October 26, 2007 9:01 AM

Easy to remember pass-words or pass-phrases are OK if you only have a few to remember.

How many of you use the same password or passphrase on more than one website?

Those who do are now reliant on someone's website for their security. If they store passwords in plain text then they will know your Username/Password for all the other sites on which you use that combination.

I do not trust other websites to hold my passwords secure and I no longer trust myself to remember multiple passwords.

My solution was to buy Roboform. I now have one password to remember and Roboform remembers everything else. Logging on to websites which require a username/password is now so easy.

Socrates on October 26, 2007 10:03 AM

Passphrases can be made even more bulletproof if you transpose keys on the keyboard.

So HORSE for example, becomes JPTDF if you transpose one key to the right on the keyboard, and Y($W# if you transpose one key towards the front (up?) of the keyboard.

Transposition makes it nearly impossible for anyone looking over your shoulder to memorize what you are typing as well as people are looking for a pattern to memorize.

Davide on October 26, 2007 10:49 AM

back to my password being cracked. It is 80 characters long, with 94 possible characters being used

I don't think we need to crack it; I doubt anyone with this password would ever be able to log in to their computer in the first place. So in that sense, it's perfect security.

Jeff Atwood on October 26, 2007 11:20 AM

Socrates. You are now reliant on your computer not crashing and burning. Be sure to archive your roboform identities folder and store it on a few flash drives(make regular backups). As far as I know there is only a windows version of roboform. So much for using roboform where ever you happen to be.

Anyway, back to my password being cracked. It is 80 characters long, with 94 possible characters being used: (N#c@bub,Iv{*{P`\=|7RbBZYjIb37m{`:!3R4i_BKK8$3-g`wOaR_qDK=Psjd3\0iwVjHG"L4IssY

If you were able to test 1 Googol of possible passwords per second(10^100), then it would still take you up to 4.08x10^41 Eons to crack my password. (Well, an average of half that or: 2.04x10^41 Eons) (And Eons being defined as 550 million years each) Good luck, since the Universe is only about 2.49x10^1 Eons old! In other words, we will likely have severl big bangs and big crunches by the time you crack the password, perhaps you should focus that time on something more useful like building a time machine to go back and watch me type the password in?

HAHAHHAHAHA just try to crack it, I dare you Marty McFly ... hahhahahahahahahahahahahaha!

Ken on October 26, 2007 12:30 PM

I just thought I'd point out that Charles Darke's comments mention NTLM but apply to LM, which no self-respecting admin has used in years. I'm sure most readers of this site would know, but...

How I tell people to secure up their passwords: One or two words in english and one or two words in a foreign language. Never going to be cracked in a reasonable time. Then I tell them about _actual_ security, which has nothing to do with password length and everything to do with not giving it out (or changing it right after), getting a new one every now and then, using a password manager, and avoiding anything they didn't sign up for.

Foxyshadis on October 27, 2007 4:25 AM

"4.08x10^41 Eons [...] (Well, an average of half that or: 2.04x10^41 Eons)"

and

"2.49x10^1"

I don't think you understand how math works.

J. Stoever on October 27, 2007 7:01 AM

J. Stoever, I don't think you understand how comprehension works. You obviously are referring to my use of notation. I would just say the number "25", but stupid people like you wouldn't understand the difference in magnitude between the number 25 and say the number 4.0x10^50 so to make it easier for the people who are just a bit smarter than you, I wrote it as 2.49x10^1. The "^1" isn't necessary, but again it is to help morons see the magnitude and be able to compare more easily. Sorry I confused you. I did not mean to over-estimate the intelligence of the readers of this blog, J. Stoever, but it should be obvious to even the average reader, which was my intention, to see the magnitude of a number by looking at the exponent to which it was raised in scientific notation.

If you were confused about why it would take an average of half the maximum time to crack a password that is simple. When you crack a password, you could guess the correct answer on the first try or you could guess the answer on the last attempt. The average will fall somewhere in the middle... So if you're confused and talking out your arse about 4.08x10^41 divided by 2 to get 2.04x10^41, perhaps you should go back to 4th grade and read a math book?

Enjoy your ignorance!
~Good Day to you Sir!

Ken on October 27, 2007 11:31 AM

Mike wrote nearer the top about random salts (unless I misunderstood, also possible).

That's all well and good, but how does the software then check that your password is correct? Unless it stored the random values in the database too, but that defeats the point really.

Ben on October 30, 2007 8:46 AM

Ben, you can put the salt in the hash. The attacker won't know this

lets say you make a random salt which is 5 char long for each password hash.

to make the string to put in the db, or wherever you do this

String salt = makeRandomSalt(); // makes a random 5 char string
String passwordHash = salt + md5( salt + password );

now when you want to check this you grab the first 5 characters as the salt. Remake the hash and check it against the hash you have in your db.

This way you can store the hash in the db and it will not be viewable to the cracker. Random length salts also works ^^

You can of course also just store a salt in the software (Hardcoded). Though then as soon as a cracker finds the salt he can generate a rainbow table and crack all passwords used in that software.

To continue on the topic of password length, I usually use phrases. Have done so for a few years now. It's a lot easier to remember. I usually put in a comma, or a '. A normal phrase can be "Idon'tlikecheese" or even "Sometimesit'stemptingtoclimbawall"

they are easy enough to remember, and are highly secure

Thomas Winsnes on November 3, 2007 10:09 AM

In the future there will be only one password that will pass all of the security checks for randomness, number of characters, and the use of digits.

That password is:
mxl%lct7

You should all change your passwords to use this new one now.

Paul on December 10, 2007 8:07 AM

I'm not sure what all the other comments said... but I read this and heard "Microsoft use a crap method to encrypt their passwords"... again.

Jheriko on January 7, 2008 7:20 AM

Who really uses brute forcing attacks anyway? I mean, don't get me wrong, they can work, but it seems to me that as an attack vector it's really a last resort. The best method, and in fact it's always been the best, is to take advantage of human stupidity.

Pope Hannibal on February 5, 2008 1:17 AM

What if they try to use a few computers to distribute the work and on each computer have more then one GPU?

it can significantly lower the runtime...
10 computers with 2 GPU will make 20 time less runtime. but still not short enough :)
can you also add the CPU to the GPU calculations??

B on May 19, 2008 7:08 AM

Lol you just generate a rainbow table on 40 PC in one month and you have all the passwords and that is that ,no brute force,no time to change the password.

Gothic_killer on November 3, 2008 10:13 AM

Like you can't combine parallelism and rainbows.

Seriously...

(and I'm not even considering the fact that most people's password are weak, and when you do mass cracking even without rainbows it's still really cool to be just a constant factor faster)

xilun on May 5, 2009 12:59 PM

Of course, my bank requires PINs to be 4 digits in length...
when I told them that was completely useless, they told me it was for "convenience"

Thing about bank PINs is that you can't brute-force them, since you only get three tries; after which, usually, the machine eats your card (or the web site locks your account for 24 hrs, or whatever). This gives any potential thief only a 1 in 3333 chance of getting in through pure guesswork.

Simon on February 6, 2010 10:14 PM

I put together, based on your formula, a basic password checker, to see how secure a password/passphrase is against a brute force attack.

Let me know if you're curious.

M Kenyon II on February 6, 2010 10:14 PM

The requirement for stronger passwords at my company has reached a point of diminishing return. The more complex the password, the greater the chance of finding the password taped to the bottom of the keyboard.

Pat Hamilton on February 6, 2010 10:14 PM

Everyone here suggesting using account lockout to prevent brute force attacks ought to read this:

"Even though the guide recommends configuring account lockout at 50 tries, I urge you not to configure account lockout. First, as the initial article of this series described, the chances that an attacker will guess a reasonable password are so remote as to not justify this option. Second, an attacker is highly likely to take your account lockout setting and convert it to a denial-of-service attack by locking out every account on the system. Third, most vulnerability assessment tools will lock out all the accounts on your domain. In the end, whether you use account lockout is a matter of your security policy, and debate whether it provides value. Keep in mind, however, that account lockout problems represent some of the most frequent technical support issues with Microsoft support services, and resetting an account costs an average of $70 per incident. If your security policy is so stringent that you believe these numbers are acceptable, and your policy cannot enforce reasonable passwords, you might still choose to configure account lockout. If not, do your Help Desk and budget a favor, and avoid it."

It's here: http://www.microsoft.com/technet/community/columns/secmgmt/sm1204.mspx
This link which was included in Jeff's last post on pass phrases: http://www.codinghorror.com/blog/archives/000360.html

James Stevenson on February 6, 2010 10:14 PM

The length of the pass phrase is irrelevant!

The relevant thing is the length of the stored, hashed value, or the password/phrase, whichever is shorter. If the stored value is only 8 long, then a lot of info has been thrown out, and there are a lot fewer combinations that need to be be tried to make it work.

Take the improvements from using GPU, and use them to more quickly build rainbow tables.

Are we to the point where the salt can be overcome by speeding up the build of the rainbow tables to custom build for each salt?

Grant Johnson on February 6, 2010 10:14 PM

A great read, and should be given to every person that has a website by default!

David Thompson on February 6, 2010 10:14 PM

The comments to this entry are closed.