The author relies on the assumption that one can try 100 passwords per second (or, fewer, in the case of an extra delay), but that doesn't correspond to real-world security breaches.
The danger of having an insecure password is not that someone will bombard the server with login requests. That can easily be detected and stopped by even the most cursory of server security. The danger is that they crack the server and get the list of password hashes, at which point the time to crack a password is dictated by the hardware at their disposal and the hashing algorithm. Your server capacity or timeout protocols are irrelevant.
So, the 100 attempts/sec number is essentially a fiction. It applies only to a manufactured threat. The real threat is much worse, which means that a password like "this is fun" is not reasonably secure.
To be more specific they are dictated by the hashing algorithm and how it is set up.
Say you have something like a straight md5/sha256/etc. It's fairly likely that there exist rainbow tables that will insta(for some reasonable value of insta) crack any reasonable password.
On the other hand, if you use a salted hash you arn't vulnerable to rainbow tables, but an attacker can still try an altogether silly number of passwords per second given enough hardware. (or again, more specifically GPUS against most common salted hashes).
On the other other hand, if you use a memory hard key derivation function (scrypt/etc.), you can quite easily set things up such that even with a ridiculous amount of hardware it is infeasible to launch any sort of attack. The problem then, is that the harder you make it for attackers to attack your passwords, the slower normal logins are for you, affecting scaling.
So at the end of the day you need to weight off how much of a problem this is in the specific circumstances you are in which will then dictate the solution you can provide.
Bcrypt is a good hashing algorithm to use, as you can tailor the difficulty level to find a good balance. A 100ms hashing time probably won't make much of a difference as far as scaling goes (unless your users are actually doing the login process multiple times per day), but it makes a huge difference in how long it takes to brute force.
What about using a unique salt for each user. For example, if you use the user's login name. Then, the hacker would have to make a rainbow table for each user, in essence.
I think bcrypt is probably still more secure? Or maybe the best would be to combine both.
The problem is that by using a unique salt per user, you can't simply create one salted hash and use it on every user hash simultaneously, however you can still check one password each hash you generate. Bcrypt/scrypt are more secure as it requires much more effort to check each password.
That's true, but the construction of the argument gives a false sense of security. "j63<2a" is more secure than "password" as well, but since they are both effectively useless (as is "this is fun"), we probably shouldn't waste time comparing their relative terribleness.
The proper solution to passwords isn't to come up with a slightly longer phrase that can still be cracked in a reasonable amount of time, it's to use a 30-character randomly generated password for each login, and keep them in a privately encrypted password safe of some sort.
Except that's a usability nightmare, and the majority of password field (annoyingly) won't accept a 30 char password.
I aim to use a short phrase that includes punctuation and a number if required, and to have the sentence be thematically linked slightly to the system I'm logging in to. This produces a long string that meets the criteria and is memorable by following the original train of thought from that led me to form the sentence. This I believe is "good enough" in all scenarios, since I should be able to type it quickly, and never write it down or share it.
The only remaining issues are max-length password fields and keyloggers (apparently a parabolic microphone can be used as a keylogger!)
You run the risk of making it a lot easier to figure out your password for other sites once one of them is known though, right?
Say you create an account at fakecompany.com where they happily and naively save their passwords in plain text in their database. Wouldn't it be easy for that site admin to then figure out your facebook.com, for example, password?
I do this too. You just have to make sure your passwords have sufficient complexity, yet have an algorithm that is easy for you to remember. Just start off a base, let's say oUb$r8!A. Now let's use a simple algorithm of taking the first letter and last letter and injecting it somewhere into the base. So your new password for amazon.com is oUAb$r8!nA. For facebook.com it's oUFb$r8!kA. To the casual observer it looks just like any other password and it beats using the same password over and over again. You can of course make it even more obscure by changing the algorithm, just as long as it's easy to hash out in your head.
> The danger is that they crack the server and get the list of password hashes
This isn't an argument either way. The service poorly handling passwords is even more culpable than the user with poor password complexity. Passwords should never be stored as plain hashes.
If you include a serious delay (like, "10 attempts to guess a user's password and we lock the account for an hour" or if you lock accounts & require admin unlocking), this is a great way to set yourself up for a quiet DoS. I don't have to bring your server to its knees -- I can lock our any user with only 10 requests, ha ha...
If you save the limit in the browser session, well, it's easy to start a new session for each attempt (just don't send in any established cookie). Limiting per IP is a bit stronger, but with large NATs this is still as risk of DoSing.
If you use just a small timeout -- like 5 seconds -- that means any individual attempt will take 5 seconds to return. Let's say I submit 100 requests in 100 threads. Will it take 500 seconds to return? Nope -- each thread will take 5 seconds, concurrently, and I'll have the results back in request tine + 5 seconds.
Also don't forget that an attacker is not required to choose a single email address and try to brute-force passwords. In fact, it's probably more efficient to take one common password at a time and try likely usernames.
Huh -- yet another wrinkle. If you track by IP address, you may have serious problems in the UK, where many ISPs are filtering all of their users through a few proxy servers (so it will then appear as if all users routed through a given proxy server are all on the same IP...).
As I wrote in another comment, high entropy passwords by definition must be hard to remember. It's not strictly true, but it definitely refutes the title of this submission.
While I think this post is rather optimistic in its calculations — using maximum entropy distributions, for instance — it does bring up a good point: Personally memorable nonsense sentences are rather high entropy.
Actual practical guessing is not pure distribution entropy but instead closer to the KL divergence since an intelligent brute force guesser has to make assumptions about the password distribution in order to reap benefits. If your password comes from an expected distribution (letters in English words, words in English sentences) you're losing a whole lot of potential entropy, traded for particular memorability.
If you can hedge between those bets, though, you're in a good place. "this is fun" is not actually terribly secure compared to "J4fS!2" unless you're actually attacked by a uniform dictionary brute force search. "slurping radicals debilitate enzymatically" is super high entropy and quite likely easier to remember than "J4fS!2".
Yet, if your Gawker password had been "passwords delight entropy enthusiasts", it would have been cracked immediately, due to the 8-character truncation. "i<3turtles" would probably have been much safer. Unfortunately, users rarely know anything about the systems used for authentication, so any advice should keep poor systems in mind. That's why I frontload my passwords with a few characters of high entropy before appending a longer high entropy (but memorable) phrase.
I once did the following for a password that I wanted to be able to remember, but that I wanted to be very secure against attack. It was easy to remember, yet very effective. How does this fit into the entropy vs. rememberability thing?
1. Take a 100x100 binary matrix, initialized to 0.
2. Change some bits to 1, in a pattern that I memorized. It was just something simple, like my initials in dot-matrix form.
3. Apply Conway's Life cellular automata rules to the matrix, with no wrap, doing 108 iterations.
4. Read out the final state of each cell row by row, as a an ASCII representation of a binary string of 10000 bits.
5. Run that through MD5. Iterate this 1960 times.
6. The final MD5, as an ASCII representation of a 128-bit hex number, was my password.
I did NOT have any of the software for this on any computer. Whenever I needed this password, I'd write a Life program, enter my memorized pattern, run it, do the MD5 stuff, and then delete the program.
Effectively, my password was the combination of the Life algorithm, the size of the input, the input pattern, the number of iterations to run of Life, and the algorithm for converting the final Life state into an ASCII password string.
There seems to be a lot of entropy here. Yet it was pretty easy to remember.
As I stated, the entropy/rememberability tradeoff isn't strict. Your pathological example demonstrates a failure mode. It's the exact same one as my nonsense sentence though.
If the attacker doesn't have a clue what the generating distribution is, then his attacks will be mis-encoded to a penalty up to the KL divergence between the his guess and the true generating distribution. You can fool people more simply than by your scheme.
Moreover, if it became common to use GoL and MD5 to generate passwords, then you've actually got a relatively small number of parameters leading to an insecure code space. I suggest you at least draw an easily remembered picture in the 100x100 grid.
Actually, that's a pretty fair principle of how to abuse the properties of our brains to make better passwords. Make the password depend on doing something that humans can do well but computers haven't mastered, and then do it slightly "off" in the even that computers do someday master it. The space of "almost intelligible" sentences or "poorly photoshopped images" are both way larger than the space of English sentences or recognizable images.
I assume you guessed 50 from the fact that I iterated MD5 1960 times so assume that was my birth year. That is correct.
I don't see how you (incorrectly) guessed Libra. If you took the 108 as the 108th day of the year and assumed that was my birthday, that would be April 18th, which would be Aries. If you took it as meaning January 8th, that would be Capricorn. Did you assume it was 10/8? That would give Libra.
Anyway, the 108 is not a date. It refers to Math 108, an undergraduate math course at Caltech that bestows a curse upon those who take it. Forever afterward, the number 108 starts appearing in their lives more than normal.
One girl I knew there went so far as to build a digital clock that held 1:07 for two minutes so that she would stop seeing 1:08 on her clock.
+1 and my nomination for the Dr Sheldon Cooper ubergeek of the month award (the combination of the bizarre password story and the 1:07 digital clock is unbeatable in my view)
...and here we have a nicely presented example of the practical difference between the purely kolmogorov complexity-based Solomonoff Induction[1], and in-principle computable measures like the speed prior[2].
The latter is, of course, unnecessary when you can do hypercomputation in your head.
How did you encode the value in step 6? Assuming that you can't enter arbitrary binary data into that password field, you could at most have used base64 which would probably be good (~20 characters, 64 possible characters).
OTOH, you said "hex value". If you encoded your number as hex, you would get a 32 character long password (good if the target form allows for such LNG passwords), but only 16 possible characters which is way too little and defeats the purpose of all your elaborate setup
I think this is the real key. Sentences as passwords are really hard to crack as long as you choose a reasonably long sentence that you can remember easily but is not overly simplistic or obvious, and if you include a few typos or non-standard capitalization and/or punctuation it becomes that much more difficult to crack.
A sentence is the only way you'll get normal users to memorize a password > 6 chars. I think a sentence is much better than what most people end using, which is a personally significant word (like a child, spouse, or pet's name) + a brief personally significant numeric suffix (like birth year).
In practice is a long nonsense sentence of English words really any better than an equally long coherent sentence of English words? Are cracking tools really that intelligent?
It's not at all about how intelligent the cracking tools are; it's about how unimaginative users tend to be.
Let's say the suggestion "use an easy to remember sentence, rather than a short password" gets around.
The actual set of easy-to-remember sentences for a large set of users will include some very good ones, but mostly a small set of simple ones, like "To be or not to be", "Seize the day" and so on.
The cracking programs don't need to figure out what those are -- they just need ONE password dump from a site with poor security (easy to find, unfortunately), and the analysis is trivial.
The other downside of sentences, though, is that even when the average person picks an easy-to-remember sentence, it's still hard to remember exactly how they wrote it last time (upper-case, all lower, what punctuation?), and for poor typists, think about the chances of making a typo (or just forgetting where they were) while typing out all those little stars....
The danger with semantically meaningful passphrases is that they have a lot less entropy than you think they do. I still use them for everything, but it is something to be aware of. (You can get more by e.g. padding it with a number, doing the usual l33tspeak tricks, etc.)
You can chose which letters you want to 1337, you can double some letters, you can uppercase others, etc. The key is to stick to your own secret trick :)
As others have mentioned, I don't think "l33t" is going to help you there. Remember - a dictionary attack isn't based on "THE dictionary" (Websters et al.) but A dictionary. If I were to write a password cracker, the first thing I would do was take a list of common passwords and "l33tify" them (trivial) to create my cracking dictionary. Of course, this is still a brute force attack, and all that entails.
You've added about 100 new words for that one old word. Of course you can do this programmatically, so your actual dictionary stays the same size, but your search is still 100x or more longer.
I didn't suggest it was a hypothetical. But I wanted to be clear that its not like you double the size of a not l33tifi36 dictionary. Rather it becomes 100x larger. And depending on how many l33t variants you supports several thousand times larger.
Right, and if the argument is that adding character classes adds complexity, then the 1337ed characters are not actually a different character class, they are equal to an existing one. "e" == "3" doesn't help, even if you have a "secret scheme" (as mentioned above). "secret," "s3cr3t," and "secr3t" are all equal in complexity except with raw brute force. Which this isn't, it's just a dictionary with some extra substitutable characters.
The usual trick is to use only the first letters of each word: e.g. something like "Mttboom1cuia!Igdtdts1flIkohd." is reasonably strong and is easy to remember (it's just a song).
True, but increasing the raw length of the password (which passphrases will give you in spades) makes those leetification tricks combinatorially explosive.
"apple" has 3 characters (2^3 = 8 variations) for easy leetspeak. "apples" has 2^4 = 16. "applestastegreat" has 2^12 = 4,096. Assuming you don't totally fubar your entropy in the underlying passphrase, you'll end up with something both memorable and infeasible to brute force.
Oh yes, and I do use this in my own passphrases for the added combinational complexity. I just wanted to point out to the naive that using `passw0rd` or `s3cr3t`, they are in password lists that a brute force attack will use. My point that crackers will programaticaly try this was less relevant.
You can choose to l33tify different combinations of letters in the password. passw0rd may be in the dictionary, but is p4ssword, or pa$$word? Patrick's point is that there are combinatorially many different ways that you can 133t!fy a password, so they don't really help in dictionary attacks.
>passw0rd may be in the dictionary, but is p4ssword, or pa$$word?
I'm guessing yes. If I were building a dictionary, I would add every password that's been dumped from sites like Gawker, etc. With hundreds of thousands of passwords floating around in the ether, you can quite quickly cover common leetifications. Also, it's trivially easy to leetify algorithmically, so padding a dictionary wouldn't be difficult. You'll run into space issues eventually, but you can easily split the dictionary over several machines.
The best solution for the user is to pick a fairly complex, long, and unique password. Server-side, assume your database will be compromised use something like bcrypt to make cracking it computationally expensive.
> You can choose to l33tify different combinations of letters in the password. passw0rd may be in the dictionary, but is p4ssword, or pa$$word?
yes they are. well, actually, password cracking software (most used is Jack the Ripper) comes with a bunch of commandline tools that allow you to do substitutions and common variations to your password lists.
generally, when trying to crack a specific target, you start with a few "seed" password lists (common passwords, but also lists of target-specific jargon), and then apply the transformation tools on those to expand your lists.
say you'd want to crack accounts at an aviator forum, you'd include a list of airplane types and aviation jargon. then you'd apply the transformation tools, and you'll end up with boeing Boeing b0eing Bo3!ng, etc.
check this guy's blog, he writes about how it's (usually) done:
I know I am annoyed by "keyspace rules" that actually reduce the keyspace (rant). So, I capitalize the 1 letter and put 0 or 1 at the end - voila! IT appeased.
Am I the only one? No. So the 'keyspace rules' don't accomplish anything, and may actually reduce the keyspace.
If you want to cheat at complexity you can look at the most common mechanisms for brute force and their defaults. For example, the publicly available rainbow tables are mainly built for US character sets. If you're using characters that aren't in those character sets the rainbow table lookup will fail (as the hash wasn't precomputed).
Likewise, if dictionaries (and the permutation rules) lack a non-standard character, using that character will defeat the dictionary attack.
If you use a straight brute force then there's a trade off between the characters you use and the amount of time it'll take to exhaust a particular set of characters. It's only if the attacker is determined (and has usually exhausted alphanumeric character set brute forces) that you'll start to see other characters being added to the brute force. The great thing of course is that the attacker has to pretty much start from scratch with another set of permutations for each additional character.
Assume there are 7500 very commonly used english words. A three word sentence, all in lower case, would yield 421 Billion permutations. Let's say, of those 421 billion permutations, which don't tense or plural nouns about 1 in 5 are familiar english language constructs, which drops down to around 20 billion permutations. In this case, if we took all capital letters, all numbers, and 6 punctuation characters, we'd end up with ~67 unique characters, for a combined 82 billion permutations.
Furthermore, like Richard Feynman discovered in Los Alamos, you could narrow down the possibilities of combinations if you know something about a person. You could probably build profiled dictionary attacks and reduce possibilities a lot.
So, is it more secure? No, it's maybe equally secure, but it would completely depend on the attack. A combination of capital letters would probably be more secure though.
I thought about this a bit more and, in reality, the amount of english words used could probably be cut down to less than 1000, which would cut down to 1/400th of my original figure. So no, I don't think it's more secure against advanced dictionary attacks.
>if we took all capital letters, all numbers, and 6 punctuation characters, we'd end up with ~67 unique characters, for a combined 82 billion permutations.
82 billion may sound like a lot but it is not. Suppose you had a few multi-core machines that could collectively get up to 1 million crack attempts per second. Now you can crack that password in 82,000 seconds, or under one day.
Except your recommendation reduces available entropy. It would be better to randomly mix words from multiple languages and disregard word order. No matter what algorithmic approach you use, you need to exclude results that are cracked easily by existing methods.
One advantage of gibberish passwords like "b923F$5mvA" is that if someone looks at your fingers while typing them, he'll have a hard time figuring them out from your keypresses, whereas if you typed "this is fun", it would be much easier.
Ditto for when someone has a visual glimpse of your password which is only a few seconds long. (e.g. someone looked at your laptop screen while you got an email with your password from an irresponsible website.)
This should be fairly obvious to anyone who's done any sort of combinatorics - you're saying that a 10 character password using symbols and lower case letters is more complex than a 6 character password using 36 more characters in the character pool. Anyone who's even glanced at password complexity research will be able to tell you that. To break down the numbers though, a 10 character password using lowercase letters and symbols (spaces) has 30155888444737843000 possible combinations. A six character password has 735091890625 combinations (around 1/4000th of the complexity, assuming a brute force approach). While the author also takes into account the possibilities of using a dictionary attack, you can't really tie a number to the search space for that. It depends on the breadth of what the program will go to. Will it check alternate spellings (color/colour)? Will it check for apostrophes? Foreign languages? Etc.
A while back I wrote a small piece of JS to demonstrate to some people the complexity growth in passwords. Some people didn't believe me that asdfasdfasdf was more complex than Fc34!j_, and this was the end result. Feel free to play with it. The source is rather simple as well:
There is a huge logic gap here. He is comparing 11 characters passwords to 6 character passwords. The difference in length also will account for a significant difference in the time required with brute force.
I think what he is trying to show is that is that the lower security of using multiple common words on a password with 11 characters is still greater security than a random 6 character password, and still quite acceptable.
Actually, I think that's his point - by using a longer passphrase instead of a shorter passcode, you get something inherently more secure AND more memorable (added bonus: no post-its, which means one more layer of security).
This isn't a logic cap. The 11 character password is easier to remember and faster to type than the 6 letter one, so it is perfectly fair to compare it.
It's interesting. The author shows some fundamental misunderstandings and makes assumptions that are not necessarily based on real-world situations to present an idea that longer strings with more recognisable characters (e.g. passphrases) are better than shorter strings with larger keyspaces. If you pick two data points you can actually fiddle with the numbers to present either side of the argument as the truth. For example:
A full 16-bit unicode 2 character password has 65 536^2 or 4,294,967,296 permutations to work through.
A lowercase alphabetic password of 6 characters in length has 26^6 = 308,915,776 permutations.
Of course there's a tradeoff involved, and that tradeoff is what IT departments try to manage, with mixed success. It's easier for the software to determine whether or not the password contains methods of increasing the keyspace than whether or not the user has typed out a 200 character long series of 'A' characters, so that's what they use. I don't know whether or not increased length has a higher risk of collisions for some algorithms (that's tptacek territory, not mine). Over time, software products have been guided by best practice standards from organisations like COBIT that define and mandate complex passwords based on keyspace rather than length alone.
Secondly, there is a difference between an online brute force and an offline brute force. Depending on the algorithm, with the right kit (or Amazon EC2 instances) you can get billions of hashes per second to crack a password hash offline. At that point your increased length only matters if the attacker doesn't know about the complexity. The samples provided are terrible as they're all lower case with a space at most. This is the poor end of the trade-off. To brute force a SHA-1 hash of the word 'sum' on my 2 year old laptop takes less than a second.
Online brute forcing (e.g. brute forcing a web form) is generally something you're not going to do if you're looking to compromise a web account, unless it is a specifically targeted attack (e.g. the user is an admin or a specific person of interest). In these situations your brute force rate is dependent on your network throughput, the application's ability to respond to concurrent requests and any other factors that may affect it (such as any monitoring system). Your web application on a linode slice will probably choke out between 40 and a hundred attempts per second (and you'll notice it unless you're blind or have no performance reporting). If you can get past the automation detection in larger sites, like Amazon, Google, Twitter etc. you'll probably be able to go much, much higher. For this reason, web site brute forces tend to be dictionary based, or at most on dictionaries and a number.
Ultimately when choosing a password you need to consider what you're defending against. If you own the box or the app, chances are you trust the defences. If you're going to change the password every few months then maybe you will choose a weaker password. If you don't own the kit and you're not intending to use the password, then use a tool such as Keepass[1] and generate the passwords yourself. That way it doesn't matter what J Arthur Random says on the Internet, you won't need to remember the passwords at all.
Right, but to put it simply, character count is the only metric that matters. If your password is a sentence that's 44 characters long, then you're set.
No, goddamnit! The search space of possible passwords is the metric that matters. This is why people should not be rolling their own password schemes.
27 possible chars * 16 length gives 27^16 combinations, or about 8.0 * 10^22 combinations. (Although much, much less in practice because you're using common english words separated by spaces.)
Printable characters, including punctuation like { } | & etc, gives you 95 characters, for 4.4 * 10^31 combinations - about fifty million (50,000,000) times larger.
Also, the main attack (which the article misses) happens offline, where the bad guys have compromised a system and downloaded all of the password hashes. In that case, they're only limited by the hardware that they can throw at it - FPGAs and high end graphics cards can check stupid numbers of hashes per second. http://nsa.unaligned.org/ is from 2007, and will check 800 passwords * 64 chars * 8 length in about a day.
Almost. If your password is 44 letter 'A's long and the only supported character is 'A' then it's not. That's an extreme example, but there is a trade-off between length and complexity. As long as you bear that in mind you're fine.
This is what the author of the original article is trying to say, apparently nobody has heard of hybrid dictionary crackers. For example, JtR has a whole set of 'mangling rules' that take words in a provided dictionary and apply various transformations (see http://www.openwall.com/john/doc/RULES.shtml).
a) check length of password. Length < 6 = fail. Length < 10 = complexity requirement. Length < 15 = less complexity requirement. Length > 15 = secure.
b) ALWAYS do a dictionary lookup on the password. A dic lookup vs a dic attack is cheap. Hell the dic can be stored in memory in a hash map... even with misspellings, we don't even need to be 100% accurate either. Once you have that, basically check complexity: 1 word = no good. 2 words = ok, add a special character in there and a caps. 3 words = great. 3 words + special characters = awesome. etc.
Anyone can make one of these in a few hrs. and give error messages like:
"Your password is too short"
"your password is too simple for it's length, either make it longer or add special characters, numbers, and capitol letters"
"your password is made up of a single word or easily obtainable information about you based on information we have in our system, please change the words used or add more of them"
This means: (a) people understand why password is rejected and (b) people have choices and (c) increases probability that people won't forget their password.
Oh and any system that limits passwords to < 50 characters can fo fk themselves. Too bad ADP (paystub) has a policy of 6-12 characters. Thats right limitations, and I have to use that crap. Is a 4000 byte database column that expansive nowdays?
Furthermore... Changing password every 1-3-6 months is also bad. WHY? Simple, very very simple: 99% of the time you will have one of the following situations:
- The same password is used + an extra 1 or 2 characters.
- The same password is used + different capitalizations.
- A different password is used + post-it note.
- The user will forget their password immediately.
The TRUE answer to the reason why it policies are the way they are is because people don't want to think. "Tom did it this way, it must be secure." "I don't really understand it, so whatever, its the standard, it must work."
To make passwords secure they need to enact the policies I stated + a second factor for authentication. If you log in from an "unknown" location (a new one) just send them an email, or sms, or something that gives some key to enter to authorize. This will work in letting people know there is a breach, change pw on need, don't make ppl change passwords nonestop. Lots of advantages.
Wow writing this I feel like we need a startup that provides this exact solution. One question for the fellas who know more... how hard is it to spoof someone's ip without them knowing (internal network or external)
You do realise that a password of AAAAAAAAAAAAAAAA would be considered completely secure by your system, right?
For your second point your dictionary checking algorithm is only as good as your dictionary. If your dictionary is too small then you're not going to do much. It won't do much good for multilingual users either.
<snip rant about changing passwords every now and again>
So are you proposing that people don't periodically change their passwords?
As for spoofing the IP, it depends on where you are and where the target is. If for example you're both on the same internal network, are NATted and your system's on the Internet then it won't distinguish between the two IP addresses. The same applies if both your and the spoofer are going through a proxy, or the spoofer is between you and them (although it is harder to do than just sitting behind the same NAT gateway it is doable).
>So are you proposing that people don't periodically change their passwords?
This always gets me thinking.
Why is it "good" to change your password periodically? The only reason I can come up with is that, if someone gets your password, you prevent them from being able to use it if they sit on it for X months until your routine change comes through. To which I say "What?! Why would they wait that long?". It's a ridiculous assumption.
There's also that forcing changes (kind of) ensures system A doesn't use system B's password, so you don't lose everything if one account is compromised. But people get around that by having several that they cycle through, on all sites - mostly negating that argument. If they got in once, they can get in again, and (as below) each of those multiple passwords is more likely to be weaker.
Meanwhile, on the flip-side, we have that more frequent changes create weaker passwords, as they all have to be remembered, or trivially-guessable changes. Which means every password is easier to guess, or if the attacker sits on it for a few months, they can probably guess the one of a few hundred likely changes you made, and it really makes no difference that you changed it. Or they wrote it down and stuck it up somewhere, which means it's wide open to social hacking if you have any coworkers.
So the solution is to use a unique random value for each password, stored in a keychain somehow. At which point: why would changing it help? You would only lose the password if someone got your keychain, or hacked the system the password is used on and retrieved it. Either way, it's gone for good, immediately, and it wouldn't matter if you had changed it last week. And all you lost is that single account, which was lost the moment you lost the password anyway.
> Why is it "good" to change your password periodically?
That depends on what it's being used for. Changing your password on systems you own (and monitor) might not be necessary if they're 'good enough', although if you can ditch passwords entirely that's much better (e.g. using One Time Pads, Public Key auth etc.)
From a compliance perspective forcing people to periodically change passwords in theory means that while a certain amount of users will have insecure passwords, that over time this will change or rotate at least. In practice it doesn't generally work that way but COBIT tells us to do it anyway so we tick the box.
If you don't own the system then you can't assume that the system hasn't been owned, so periodically changing passwords is seen to be a good thing(tm) as it stops people from having persistent access to your stuff. Again, real world deviates significantly on theory on this, but YMMV.
The frequent changes don't necessarily create weaker passwords, they do disrupt password guessing slightly. For example, imagine organisation foo has a password policy requiring monthly changes. The default password is welcome1, so inevitably people change it to welcome2, welcome10 etc.
Once I've got the hashes I see that I'm pulling off a lot of welcome1s, and welcome2 works as well. I do have to do some work to get the rest of the welcome<nn> and welcome<nnn> but on the whole it's fine, except for the guy that chooses a password that doesn't fit the common password ('that guy' with welcome1welcome2welcome as his password in this case). So it doesn't have a significantly measurable effect for all people, but may have for some. Yeah, it's still a load of rubbish though :)
If the password is sufficiently complex then the keychain solution should work and changing it is unlikely to have any statistical effect unless someone's doing a very slow and long winded sequential brute force (in which case changing a password to earlier in the sequence may help, but that would require a priori knowledge of the sequence and position and is impractical). With the keychain solution the only measurable difference would be that the resulting password would be better, worse or the same in terms of complexity and length tradeoff, but that's down to the algorithm.
>it stops people from having persistent access to your stuff.
I can buy that, but that's far from the most likely danger on the internet. Usually it's the equivalent of a smash-and-grab job; break in, download everything of value within minutes, never go back (unless you can install a trojan, bypassing passwords anyway). Because going back in multiple times raises flags.
And every system with any reasonable need for security should detect questionable access from new locations, and block them until they are verified. Not all of them do, of course.
The must-change-password tradition seems more and more like a blind dogma for proper systems, because it's a slightly-effective bandaid for really crappy ones. I have yet to see a reason why, in an even half-way decent system, it's not actually a detriment due to weakened passwords / people writing them down where others can see.
>Once I've got the hashes...
... you've already got access to all the info in their database, likely in their entire networked system. That's infinitely more destructive - all those passwords can be changed within days, rendering them useless for re-entry. And it's safe to assume that they will do so, as per above in an even half-way decent system with any kind of logging whatsoever.
As a bandaid for systems which need a bandaid, I admit, they do have (minor) advantages. But such systems shouldn't exist in the first place, and are less and less of an option for newer systems, as proper setups are getting easier and easier to create. And I fear that, as long as they're seen as an effective bandaid, the weaker systems will be more likely to be used because there's an effective bandaid to improve their security. And such systems are usually more vulnerable to trojans, which are a far greater and more real danger than someone guessing someone's password.
> Usually it's the equivalent of a smash-and-grab job; break in, download everything of value within minutes
Is that still the case? I was under the impression that these days, account/identity access has black market value. People sell each other lists of accesses. That means there is a certain -- maybe even significant -- amount of time between when somebody has cracked your password and when somebody will make use of that access.
Which is after someone has made a dump of all the user info from a database. Which should be detectable by any logging software. Which means the company should have taken steps within the day to change all passwords.
And again, this is what any company at all interested in security should be doing, and is relatively easy to do. Not what they all do. I'm arguing against the blind following of tradition, not that it isn't an easy way to improve things slightly at horrifyingly insecure locations. And if your security depends on changing your password routinely, you have much larger problems.
All of this makes the passwords useful only for breaking into other sites, as people re-use passwords. It's the personal information that's valuable, not that the password was used at location X. A person's password entirely detached from its source is still valuable, because of that re-use.
But a unique random password means they got nothing but a day's worth of access to the location they got it from, which they apparently already had, likely at a significantly-higher security level than you have. Changing it monthly helps this... how?
Lots of them. SSH supports it natively, for a high-profile example. I see them every couple months as a learn-to-program project, or look-at-this-neat-index-card-trick.
>Why is it "good" to change your password periodically?
I don't get it - why does no one mention the most obvious reason ? Is this a trap set up by math nazis ? I have this feeling I may be the stupidest person in the room.
For the sake of argument, let's say all passwords on a server are numbers from 0 to 99. An attacker using a brute-force attack can try 5 passwords per day. So it will take at most 20 days to crack it. First day the chance is 5/100 = 1/20, second day is 5/95 = 1/19, third day is 5/90 = 1/18 and so forth#. So, as the time passes, it is more and more likely that the password will be cracked, because some combinations have already been tried. It's not 5/100 forever ! Now if you're forced to reset your password, the chance of guessing the password is restored to 5/100.
We can ponder the wisdom of forcing password changes if they take, say, 50 years to break with brute force. When the change is forced each year, chance is restored from 1/49 per year to 1/50 per year. Big deal ?
# There's a fairly simple formula for calculating the chance of k successes over n trials, given p probability of success in each trial .
http://en.wikipedia.org/wiki/Bernoulli_trial
A rebuttal is in order, because I've seen this argument before:
First: assuming a long, slow, undetected brute force is running, you have just as many chances at the beginning of helping the attacker by moving closer to their starting point as you do increasing the distance. It's the same whether you change it or not.
Second: a long, un-detected brute force? Bull.
Third: decent passwords negate brute forces entirely. Trillions-of-years entirely. We've established that changing passwords when you have a horribly insecure system might minimally improve things, but we have not established that changing secure passwords in any way helps.
About 6 years ago this happened to us. A slow but persistent SSH brute force was targeting one of our servers. After we spotted it (it was an SSH brute force and because it was slow we didn't detect it over the noise of general SSH scans on port 22) we switched to public key auth only on the server and installed fail2ban.
How is AAAAAAAAAAAAAAAA not a secure password? Unless you're standing over the person's shoulder, how are you going to know that their 16 letter password is all one letter?
Exactly. Enigma was cracked because the Germans applied routine practices that limited the available entropy instead of making the code harder to guess, as they intended. It's important to avoid the classic xkcd "4, guaranteed random number" issue with overused passwords, but that doesn't necessarily mean that all equally simple (as in memorable) passwords are insecure.
They do. Most decent password-dictionaries I'm aware of are based off actual password dumps from hacked sites, so they're loaded with low-mental-entropy stuff like that.
They're "dictionary" attacks because they work from a pre-selected set of values, not because they read from Merriam-Webster, cromulent though it may be.
You're not going to know anything about their password unless it's leaked in some way (e.g. maximum length on a password change screen, character set etc. or cryptographic leaks). However it's wrong to assume the approach an adversary will take when you know nothing about the adversary in question.
If I exhaust a 16 character space with alphanumeric passwords and pull out aaaaa as one, am I going to add mixed alphanumeric to my list and start again or am I going to check variants on AaAaA up to a certain length? Personally I don't know which I'd choose, it'd be dependent on the situation (but I've done both on penetration tests).
That's reasonable; but, they probably aren't going to know the length of the password either, so they might go through a great many other tests before they reach A16. Of course, the person trying to discern a person's password may follow a DFS approach before a BFS approach, and that password would be quickly compromised, but I don't see that happening.
Note: In the real world, I wouldn't encourage anyone to have that as a password. This is more of an academic curiosity.
Upvoted for recognition of the difference between academia and reality, and lack of spherical cow assumptions.
It's entirely possible that someone might stop at 14 (for example with NTLM based on an incorrect assumption that as LM stops at 14 characters, so must LM for example).
I guess the point is that security's more probabilistic than deterministic, which means that you can take some measures on a given topic up to a point, then beyond that the payoff decreases to the point where you're wearing a tin foil hat and worrying about the RF conductiveness of tin foil versus the alien ray beams it's supposed to be blocking.
Still, thanks for the interesting conversation, it's one of those things that for me makes HN really worthwhile participating in.
An important tweak to the "real world" aspect of cracking passwords -- the attacker is just as capable as the user of reading the advice you give to users when choosing passwords (and what rules you enforce).
If you say "longer is better -- nothing else matters" or "think about using a passphrase -- the added length makes your password much more secure!", and you prevent them from using passwords < 10 characters, that's going to influence the attack.
The short answer is dictionary's of existing passwords people used on actual systems exist. So "I think there fore I am." is about as bad as "AAAAAAAAAAAAAAAA" they will both probably show up within a the first billion tests of a good dictionary attack. Note: "I think, therefore I am" is the correct spelling but common misspellings don't really protect you from an actual password list. Other useful tests use all phrases in the Bible etc.
Another approach is to look for patters asdfasdfasdf is a fairly common password for a reason.
It's probably not considered secure because it's all one class of characters.
It's a lot faster to bruteforce with "uppercase characters only" vs "uppercase, lowercase, numbers, special characters".
Now, if i would be trying to get as much userpasswords of a database as i can, i'd probably start with "lowercase only" and most likely will get the biggest amount of passwords. Afterwards try "lowercase + numbers", "case insensitive + numbers"..
If you're not a bank or other equally sensitive entity you have no business enforcing password complexity requirements. Let me decide whether I care if someone gains access to my account on some rinky dink web app.
One of those little meters that warns you if your password is weak is fine, but in my experience they aren't very accurate.
Let me decide whether I care if someone gains access to my account on some rinky dink web app.
Complexity requirements aren't targeted for you. You're making a conscious decision about what risks you're willing to assume. Most people aren't aware of the risks, even if told their password is weak. That is who complexity requirements target. (But the requirements probably aren't altruistic: they're really there to help protect the application and its developers from the perception of insecurity.)
This is one reason why application developers should get out of the business of building authentication systems. At least then the problems belong to someone else who we'll trust to have dealt with them.
In my 25M word corpus, "this is fun" occurs 23 times. There are only 94,000 trigrams that occur more frequently.
Therefore, you should be pessimistic, and consider the password "this is fun" less safe than passwords in the shape [a-zA-Z]{3}, like "tsP", of which there are 140608.
Assume attackers know the algorithm (e.g. three common words, one 7-letter word in l33tspeak, a 6-letter string of random ascii characters) but not the parameters.
You should also make your sites amenable to password managers that autofill and submit login forms.
Bank of America, for example, foils 1Password by spreading login across two forms and using a custom, non-machine-discoverable "submit" button in one of them.
"this is fun" has structure and I suspect is an easy password to guess from the pool of all three word passwords. Just like using a dictionary is better than brute force, trying common words that usually go together when guessing three word passwords is much better than trying all three word passwords. If Google were to write a "word" password cracker using their data trove, I suspect "this is fun" would go down early. Likewise putting spaces between words would be to the Google cracker like adding a number on the end of a dictionary word is to a standard cracker.
What about moving away from semantics (easy to remember words) and change to patterns on the keyboard? That's how I handle my most secure passwords. Patterns on the keyboard using all the keys and combinations of shift create passwords that are easier to remember than a random length string, and can become quite long (>8 chars).
No it's not. If I was brute forcing a password these days, I'd use the google ngram database, and "this is fun" and pretty much any other memorable phrase would fall pretty quickly.
Would you do that before or after your dictionary attack? Or brute force character ngrams? Or pure brute random chars? There's a fair few responses pointing out that it's not a hugely uncommon ngram, but the known search space in this case is just "a password field", the application/organisation's rules might tell us min length, or if we can discount no numbers/symbols.
Time between events should be limited by either the app's login function or a suitably expensive hashing function (whose algorithm will have to be known in the case of a DB dump)
I'm willing to bet that the set of 8-character full-ASCII passwords is comparable in cardinality to the set of 8-word sentences, even accounting for Markov information density.
Using a grammar and a dictionary of common words I can see attacks on 3 or 4 word passwords being somewhat feasible although I should do some back of the envelope calculations.
Those are unique per year, so the phrase "a simple but potentially" is counted many times. There are about 600 million google 4-grams, slightly more than there are 4-character ascii strings.
Summing up, a meaningful 4-word phrase, is, in the terminology of the article, "risky".
My advice: use generated passwords, and apps like 1password to remember them.
hmm, perhaps I'm missing something, but shouldn't systems just not allow you to attempt to login so much and so frequently?
I guess these systems do get hammered by so many improper attempts and you'd risk blocking the actual account owner. But if a billion attempts are made from the same ip in an hour, shouldn't that be considered suspicious?
Personally, I like what Google's doing with the two-step verification. That's probably where security should be going.
Good "dictionaries" for doing on-line brute-force attacks don't just contain words, they contain likely passwords. Guidelines for choosing good passwords should point this out. For example, something like "J4fS!2" is a much much more secure password in terms of protection from on-line attacks than "letmein" or "chang3m3" or "tryandguessthis" or "password123" or "root!@#" or "b4ckm3upsc077y". All of those passwords are actual passwords taken from the list used by an SSH brute-force password cracker.
Because people aren't random when they choose words to remember (e.g. "beavisandbuthead" is also on that list), a better set of password-choosing directions would provide instructions one how to add some additional (pseudo-)randomness to passwords that are being created. The classic "pick a phrase, take the first letters + punctuation" method is one way to do that ("pap,ttfl+p" is a somewhat strong password), and it's not hard to think of other password generation schemes that also create strong passwords.
Using multiple words or even sentences as password (as described in the article) doesn't even work always, there are too many websites or application which have a password length limit.
I recommend to use a password manager, KeePass is quite good.
Good password manager should be able to easily generate a new strong and complex password every time.
Remembering only one password and getting rid of the laziness of choosing always the same password is another advantage too.
Even if a website that stored your password in clear text and someone hacks the website, you shouldn't have to worry about other applications or services you may have used with the same password.
My personal rule is to choose unique strong passwords (alphanumeric and symbols) with at least 9 chars.
Brute forcing a password with 8 chars was with my 5870 no big deal at all, but cracking a password with 9 chars is too expensive (ec2 gpu) or takes to long for the usual hacker.
If someone really brute forces my password, with gpu and a cluster support, damn, than he really deserve it.
The title is a bit misleading. The passphrase "this is fun" may be 10 time harder to brute-force than "J4fS!2", but both are hard enough that nobody would bother trying to brute force attack them. So they both are equally acceptable. I personally would rather type "J4fS!2", and here's why:
We use PGP Whole Disk Encryption at my company. The passphrase strength requirements are quite strict. It took me about two dozen attempts before I found a password that it would accept. The password was something along the lines of what the article is proposing, five short English words arranged in a sentence (about 25 characters long). This was acceptable to PGP because the software prefers longer passphrases with less entropy per character over short passphrases.
The problem is that it's quite hard to type this long passphrase in when all you can see on the screen is stars or dots. The longer a passphrase is, the higher chance there is of introducing a typo. A shorter passphrase, mixed case and with symbols, is, at least for a programmer, easier to type, especially with muscle memory.
In the case of PGP Whole Disk Encryption, they obviously realized this since you can press the tab key to enable showing the password in plaintext as you type it. I always do this because it increases the success rate of my password acceptance quite a bit.
On an unrelated note, it seems that a far bigger security risk on the Internet is the use of the same password on multiple web sites. If you use "this is cool" on ten different sites, then you are opening yourself up to serious vulnerability if one of the sites is compromised. Using a hash of a common password with the domain name provides a lot more security, but the simple implementations available today produce passwords that are short with mixed case and symbols versus long strings of words. But since the only sane way to use this approach is with a password manager, extension, or bookmarklet anyway, this doesn't seem to be a major limitation.
But having to create and remember short three to five word passphrases for dozens of web sites would be a daunting challenge!
I think dictionary attacks are a far more common attack profile than looking for written down passwords. Also, pointing out common passphrases is a good way to ensure that passphrase checking makes it into later iterations of password cracking.
If site X suggests to users that they use pass phrases consisting of common words chosen at random, then "this is fun" is not very secure. A brute force attack using /usr/share/dict/words found on many Unix systems would take about the same effort as a brute force attack on an 8 character random password where characters are drawn from upper case, lower case, digits, and common punctuation.
You'd actually break most people's common words passwords using smaller word lists, say the 4096 most common words. Three words from the top 4096 chosen at random gives a password equivalent to a little under 6 characters of mixed case/digits/punctuation.
Q: So, are you saying we should use "this is fun" as our password?
A: No, I'm saying that you should use a 3+ word pass phrase as your password. Something that isn't linked directly to you or your immediate interests. So don't choose the names of your three kids.
In http://qbix.com , we have implemented passphrases out of the box for all of our apps.
Try signing up there. You will find that the passphrase suggestions are quite nice. To obtain them, I took three random words, searched yahoo news for those words, and for each result, chose 3 contiguous words and presented it as a passphrase suggestion.
In the event that Yahoo is unreachable, our server generates one of 50 million unique phrases from ADJECTIVE NOUN VERB NOUN. I would say this produces greater entropy than if you left people to choose their own passphrases, even if they don't copy our passphrases exactly.
1. Construct a complex password key with a minimum length of 8 characters, e.g -Kr/2.pq4
2. Make an algorithm based on the URL. E.g. news.ycombinator.com
a) Take the last 4 characters in the URL, excluded the domain suffix: ator
b) Shuffle the letters based on your algorithm: orat
3. Combine the password key and the output of your algorithm: orat-Kr/2.pq4
4. Always enjoy individual, secure and easy to remember passwords for any services.
The algorithm you use can be more complex, e.g. adding characters in between, but the basic idea should be explained.
A few years back I got heavily into password cracking. As part of it I sniffed a bunch of people's passwords in coffee shops, as well as other black hatty things that I'm not proud of (though I will say that I learned tremendously from them). While these pattern based passwords work nicely to deter automated systems from grabbing your password after a site compromises your password, they dont stand to the test of human eyes. I had several people's passwords who used similar tactics, it wasn't hard to figure out the pattern. My point here is this: don't rile yourself up about having bulletproof passwords. It's good that you do it, but don't mandate it if you're the head of a company. No password is bulletproof - if someone wants it hard enough, they will get it. Figuring out a pattern based password is only another breadcrumb to follow.
"None can remember a password like "J4fS<2", which evidently mean that it will be written on a post-it note."
That's bullcrap. Few will remember this password, but most can if they try. My work domain password is over 8 characters in this level of complexity and it took me about 10 minutes to get used to typing it, a day to fully get it into muscle memory. If you ask me what my password is, I'd have to type it out.
I started writing a response, but then it got too big. Basically the 5 second timeout is a bad idea because its implementation is not worth the effort. http://oim.ae/gx8qMD for the reasoning.
But the other thing, use UTF8 high value characters. Or simply learn Russian and use a password from russian words.
The author either knows basically nearly to nothing in computer security and password bruteforcing, or knows stuffs but miserably failed to properly communicate the hypotheses used (he did communicate some of his hypotheses, but not in an appropriate way that would have rightly prevented the general public from making password choices based on this article while under radically different conditions) and caveats to take into account when interpreting his examples.
This article is misleading in the sens the results it gives are only applicable for very narrow cases, and fast reading it can give the impression that "J4fS<2" is a "secure" password and that "this is fun" is even more secure. While this can be true under those very restrictive hypotheses he used, the fact that it was not prominently warned that those hypothesis should not be blindly used for basing password choice for random online web sites or other things makes this article dangerous.
Speaking of passwords, I believe hackernews account passwords are transmitted over plain-text HTTP. Even the password reset is plain-text HTTP. Perhaps that will change soon?
When helping people construct passwords I always guide them to use an acronym from a favorite line of a song (or bible verse, or poem depending on audience) and then add a symbol and a number. So for example if you really like Led Zeppelin you might take the opening line"
"Hey Hey Mama Said The Way You Move Gonna Make You Sweat Gonna Make You Groove"
and turn it into the password hhmstwymgmysgmyg!8
or "The woods are lovely, dark and deep. But I have promises to keep"
to become: twaldadbihptk$9
Easy to remember, relatively high entropy, pretty good compromise.
Your idea was ok until you posted it on the internet.
Since I already had a song-lyric dictionary (that prioritized complete phrases like you used there, "HHMSTWYMGMYSGMYG" being FAR more likely than just "HHMSTW") it didn't take long for my program to just grab the first letter of each song lyric word, stick them together, and then add every possible combination of symbol->number to the dictionary.
Now everyone you've told to do that will be very quickly cracked if I ever get their hash.
This is security through obscurity and you just gave away your obscurity by posting your algorithm on the internet...
the author only considers common words attacks, what about common phrases attacks? with a database consisting of common sentences, (eg. from reuters) those passwords could be broken in a much shorter timeframe than claimed in the article.
A number of posts have made this point and all seem to have not understood the article and the FAQ. (Or just like to nitpick)
Let x be a three word pass-phrase of 11 characters and y be a 6 character standard complex password.
The argument is: x is more secure than y.
You've pointed out a special case where x is also a COMMON phrase, and demonstrated a counter example to the assertion.
So rephrasing the argument:
Let x be a three word uncommon / nonsense phrase and y be a standard complex password.
x is more secure than y (and a hell of a lot more user friendly)
I think with that modification the argument stands, and the specific case of 'this is fun' is a mundane distraction from the real point the author was making.
with that argument you've reduced the problem to how complex (ie. how long) said phrase is. the point the author makes, is that the password should be easy to remember and not a nonsensical phrase (so you don't have to write it on an insecure post-it). I see you wrote uncommon as well, so I agree there might be an uncommon yet easy to remember password, even though this somehow contradicts itself (not subjectively but collectively).
I would not use "this is fun" ever. If it becomes at all common for people to start using 2- or 3-common words instead of smaller non-word strings, password crackers are going to start generating 2- to 4-word strings. "This" and "is" are two of the most common words in the English language. A flat dictionary approach may take prohibitively long, but a smart password cracker is going to start with the most common English words, and I just don't believe "this is fun" will survive very long.
If you use 3 uncommon words with no logical connection ("masquerade nefarious pulchritudinous") you are probably safe, but if two of your words are among the language's 100 most common, and your password is a sentence... bad idea.
A cracker faced with a 20-character password space is going to choose "this is fun" before "J4fS!2". It's only with a 6-character password space (which is pathetically small) that "J4fS!2" is likely to be hit.
Novelty accounts on HN? Really? I guess I've quickly become a pessimist in the last few days of changes around here but the green on what is presumably new accounts highlights the poor quality of new commenters.
I wondered what might be the reason for that. This makes LOADS of sense. Hi-light new users in threads and your eye is drawn to them. This enables experienced users to easily give constructive criticism, knowing that a poor comment was left by a new user who might not otherwise know the community's mores.
If you're also enforcing complex, high-entropy passwords this is a good way to encourage users to write their password down on a sticky note under their keyboard.
It's a lot more secure than relying on "000" for 6 months if your server was breached or your PW was sniffed over the wire, or if you use the same (or similar) password on a different site and that PW was stolen/sniffed. Rotating passwords is one of those security practices that (like any legitimate security consideration) is crazy annoying but effective.
Because it's not true! Or at least not the way it was explained. The reason to change your password is to avoid the vector of attack where someone gets your password and can therefore use it against you. If you change your password each month, you limit the damage the person can do to whatever they can achieve in that month. Similarly if they have your username and don't have your password, they only have a month to try as many combinations as they can.
To say that is is 'the only way' is certainly not true. However, it does help in these circumstances and that's why it is a method which is used - mostly in companies as far as I can tell.
I think corporations are just as worried about employee X willingly giving account info to employee Y, as they are about a malicious attack.
Of course the real fix for both scenarios is two-factor authentication. Not something that practically begs the user to either write their password down or append apr-11 to their normal password.
The danger of having an insecure password is not that someone will bombard the server with login requests. That can easily be detected and stopped by even the most cursory of server security. The danger is that they crack the server and get the list of password hashes, at which point the time to crack a password is dictated by the hardware at their disposal and the hashing algorithm. Your server capacity or timeout protocols are irrelevant.
So, the 100 attempts/sec number is essentially a fiction. It applies only to a manufactured threat. The real threat is much worse, which means that a password like "this is fun" is not reasonably secure.