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.
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.