I came up with such a scheme 12 years ago, but with some improvements. If you modify words from /usr/dict/words with h4xx0r style modifications, then it's easy to get above 80 bits of entropy with a reasonable number of entities.

An average vocabulary has something like a million words in it, if you word count derivations. If you can expand that by a factor of five with easily memorable things like 1337-speak transformations, you can get above 80 bits with only 4 entities.

That's not much better entropy on the password. It wouldn't take long to go through all three word combinations based on a normal english dictionary.

With a password the key is always entropy. You can use all the smarts in the world to avoid the pre-computation attacks on your password... but never forget that brute force is not limited to character by character attack :)

http://www.baekdal.com/tips/password-security-usability says that it would take 2,537 years to crack a password with three common words, at a rate of 100 guesses per second, and flange isn't common. That's long enough for me.

This guy picks that upper limit based on the idea that an attacker can't hit the webserver more than 100 times a minute, which makes me question how much he knows about crypto. He doesn't take into account someone who has access to the password hashes.

So assume they've got something lame like SHA-1 hashes, even on commodity hardware you're talking about 100,000 hashes a second. Now you're at 2.5 years. Setup a simple cluster or buy some CPU cards, and you easily get into the three month range.

Use bcrypt, and chose a work function that's as high as you want. It's pretty trivial to ensure that given certain hardware, it will take a certain amount of time to hash a password.

Never Never NEVER use SHA-1 or MD5 for hashing your passwords, those algorithms are designed to be fast.

Anyway, the technique is called "Diceware", and you can pretty easily calculate how much entropy you're getting with it. (and assuming your attacker doesn't know you're using diceware, you're in even better shape.

That is good developer advice. But from the perspective of a user there is no harm in assuming the website your using stores your password as unsalted sha1 and go from there.

Shit, he's in trouble now!

Right, so someone trying to brute force the password into the interface is limited by the speed of the program (or any artificial limits it should have built in :)).

In fact, just one word with a couple of numbers has the same effect.

Don't forget though, you are trusting this password to a site. If they are hacked, what then? Your 2K years turns into minutes or hours.

Reminds me of when I had to write a front-end for a web search feed. It was easy to test the standard case (millions of results, of which the first 1000 can be paged). But what about the case when there is only one page of results? The solution seemed to be, rather than finding a topic with only a few results, to keep appending common words until the # of results shrunk enough. For example, from Google:

  "antelope" has 14,100,000 results
  "antelope walrus" has 118,000 results
  "antelope walrus biscotti" has 8,100 results
  "antelope walrus biscotti eisenhower" has 1,690 results
  "antelope walrus biscotti eisenhower lambchop" has 8 results!

Bonus if you can find a word combo which produces a single page of interesting sites, not word spam. Of course now that this comment is on the web, make that 9 results for "antelope walrus biscotti eisenhower lambchop".

This was a concept back around 2004 or so called "googlewhacking". The goal was to form a search query of only two words that had exactly one hit on google.

I came up with a similar password for our house router. After a week, I couldn't remember which animals were involved...