I've been using phrases and sentences as passwords for a while, and I've found that there are 2 main problems;
1) A lot of sites, still in this day and age, have max password lengths, so I still have a lot of short passwords. Usually this is bank sites and the like.
2) Password entry fields are often very short visually, and with a long password getting lost is much easier. I find I have to type them over A LOT.
These are the real issues with this. Banks seem to be borderline idiots when it comes to password security: case-insensitive, no spaces, 20-character max, small choice of "special characters". These are from Amex, who's password requirements sadly were even worse a few months ago.
With crappy password requirements, it's impossible to use decent passphrases. Getting locked out of your account for 3 failed attempts at typing a 30-character password is pretty obnoxious, too.
In situations that allow passphrases, you don't need a password generator like this. You can grab a sentence from your favorite book and use it. e.g. "How do you do, Miss Doolittle?" That's not the best choice, but it's still got way more entropy than a standard password, probably a lot more entropy more than you'll get by choosing a 4-gram composed of words from a corpus of 2k, and it's easier to remember.
The average book length is probably not over 400 pages. An average page probably doesn't have over 25 sentences on it. So the whole book contains only ten thousand sentences.
That gives you 14 more bits of entropy.
The total is 41 bits of entropy. This is one-eighth as secure as a 4-gram composed of random words from a corpus of 2k, if we measure strictly by entropy.
The situation is actually much worse, though: your favorite book is probably a popular book. So the number of bits of entropy provided by the choice of book might be a lot smaller than 27. I would guess that it's perhaps 10.
And many of those 129 million books are not very different. They contain quotes from other books, reprinted short stories, folk tales, set phrases, and so on.
In practice I think it might be difficult to mount a password-guessing attack using the Google Books corpus, because it's hard to get access to that corpus. The Project Gutenberg corpus would not be so hard.
Of course, the flip side of this is that we're veering off into attacks where you're targeting one specific person and know a bit about how they've chosen their password.
If you want to mount such an attack, fine, but most of us are dealing with the much-more-common threat of someone who gets a file or a database of hashed passwords and wants to crack them all in one go.
That's an interesting analysis. I can't really see any major deficiencies with it.
On the plus side, a sentence is probably going to be easier to remember than 4 random words. Personally, I draw some of my "high-security" passwords from literature, but then I modify the case and do the "leetspeak" character substitution, so a naive sentence attack would not work. A more clever one might, though.
Edit: Oops, as dpark points out, I swapped two digits. My apologies. Below, my original, erroneous comment.
41 bits of entropy means you have on the order of a one in 10^12 chance (2^41) of guessing it, and 2,000^4 is on the order of 10^16. So how is the former "one eighth as secure" as the other? Wouldn’t it be 10^4 times less secure, that is, 10,000 times more likely to be cracked?
If you choose one of eight small modifications to apply at a randomly-selected character, you get perhaps 6 bits of entropy from the choice of character and 3 bits from the choice of modification. That's better, but adding an extra common word to the end of the sentence would be better still.
Don't forget sites that require: "your password MUST contain at least one number, one uppercase letter, and one of the following characters: !, @, #, or $, but not %, ^, &, or *". I slap my forehead at how counterproductive these requirements are.
This is why, for my lab's password changer, the requirement for short passwords is simply that it must have one upper, one lower, one digit, and one none-of-the-above (and be at least 8 characters).
If you have a long password (at least 16 characters), all other requirements are waived so that you can use passphrases.
Forcing one or more digits has little value. You are better off with 1 uppercase one lower case and 2 non alphabet characters. (Users are very likely to be replacing a letter with 1,0 so 2options * 8posistions = 16 possibility's = fail.)
Then the space would be "the obeisance to the stupid website piece". Note that the entropy of "correct horse battery staple" is only one bit more than "correcthorsebatterystaple".
Usually the symbols involved are used by SQL or some other layer, and the programmers insert the password directly into the query string because they don't know any better. This leads to SQL injection and other issues.
So rather than discovering the correct way to do things, they try to prevent you from using any characters that might be involved in an SQL injection.
In some cases the guys on the backend know what they're doing, but the requirement can still be passed down from on high from some manager who absorbed the practice from another project.
They're trying to force users to use those characters in an attempt to enlarge the space passwords are drawn from. It doesn't work very well, of course. Instead of "password", you just get "Password1!". That said, I might make the same choice (for short passwords) if I were implementing password policy.
Edit: If you meant the "but not %, ^, &, or *" requirement, that's an indication that the devs don't know how to use prepared statements or at least escape properly.
Those requirements are there for the people who try putting just their name or "password" or their 4 digit ATM PIN as their password. For very short passwords, only having alphabetical (not even alphanumeric) passwords is terrible. Those requirements are there to prevent some really stupid passwords.
Also annoying is that a lot of sites require gibberish. Apple requires at least one uppercase, one lowercase, and one number. Some sites require a symbol as well.
Especially if you are logging into multiple systems regularly using domain credentials, it rapidly becomes apparent that the faster and easier the password is to type, the better. I've found that some passwords with symbols and numbers just roll off the fingertips with a little practice, others not so much, but longer passphrases are for some reason the worst.
This. My password is not a word, not even a word with substitutions, but it is optimized towards typing it on a keyboard (in terms of when caps come in, when numbers are added, switching hands, etc). I can knock it out in a second and it's muscle memory with zero risk of forgetting. correct horse battery staple, not so much. I lose some entropy by making it typing-friendly, but the cracking algorithm to simulate that would be pretty difficult. I'll take the loss.
As an aside, 1000 guesses a second? Seems generous.
Very few sites have a short max password length. I use 1password, and of the 63 sites I've stored passwords, all but 2 allow 25 character password lengths. Ironically, my Bank only allows me 15 characters.
I haven't typed a password in 3+ months - don't know what any of mine are anymore, so I find typing is no longer an issue.
I really like using 1password. I have a long passphrase as my unlock key, easy to remember, then do the randomly generated codes as long as is feasible for each different service.
1) Nothing written down
2) Unique per service
3) Adjustable difficulty & char set per service, to match their stupid requirements.
1) A lot of sites, still in this day and age, have max password lengths, so I still have a lot of short passwords. Usually this is bank sites and the like.
2) Password entry fields are often very short visually, and with a long password getting lost is much easier. I find I have to type them over A LOT.
The second is actually the more annoying problem.