It does now! This is why it's so important to use a method like diceware to select a strongly random set of words for your passphrase.

If so many sites didn't have a limit on password length, I would use UUIDs.

BTW, is there any reason to have a short limit on password length? I'm talking less than 20 characters? I could understand limiting it to 100 characters, but when it's short it makes me feel like the site might be storing my password rather than a hash.

Honest question since I want a solution to that problem. I want separate credentials for my home and office computer so even though I use a password manager I have like 3-4 sensitive passwords I have to keep in my head.

My office computer has a relatively weak password because there's nothing on it that is personally sensitive. They force a password change every three months so I added a counter to the password and just increment that each time (pa$$1word, pa$$2word, pa$$3word, etc...).

A determined adversary can do things like lift a fingerprint from elsewhere and use that, but it's not really something I worry about too much. They could also arrest me and press my finger down on the sensor or beat me and I'll tell them every password I can.

I mostly worry about having strong credentials to remote systems.

I would imagine in the "real world" outside strict culture fit requirements that a certain percentage of passwords will be popular bible verses, for example.

There's a curve where the likelihood of collision or predictability is very high with short passwords and it declines with length until it starts increasing again.

I used to use full engineering parts numbers of semiconductors I used in projects. I also used some verbose API names that I used a lot. In retrospect that's a terrible idea. I wonder how many people sitting next to me used the same password.

Was it "Live long and prosper" or "He's dead, Jim"? The latter seems more suitable given the circumstances :)

I actually looked it up: 1,1A(bunch more stuff here)000Destruct0 it was kinda long. From memory that movie even displayed it on the screen so the guys used the same capitalization and everything.

https://www.schneier.com/blog/archives/2014/03/choosing_secu...

The main point from his essay is anything that can be remembered can be hacked. He then softens that statement to show a way to take your memorable phrase and turn it into something stronger.

Most of the time these days we're talking about online services or devices where there are practical limitations (or software limitations) imposed on how quickly we can "guess" a password. This is the most important use of passwords, their strength within a hash should be a concern of the proprietor rather than the user.

Specifically using a salt + pepper, and a hashing algorithm that can be made computationally expensive (or use some other finite computing resource like a lot of memory or even GPU power).

> This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick.

Them being "on to this trick" doesn't defeat it. It is mathematically stronger. The US-English keyboard has 100 common characters on it. A eight year old child knows over 2,600 words. The key to an "XKCD password" is that one letter in a "random" password must be equal to about half a word in an XKCD-style password (e.g. 8 characters = 4 words, 6 characters = 3 words, and so on).

So:

"12345678" (8 chars)

"OneTwoThreeFour" (4 words)

Are equally as secure (still terrible passwords, but the maths works out). That's because, assuming a "bad guy" knows your trick, the search space is much MUCH larger for an XKCD style password than a traditional password.

Schneier is just mistaken, word-based passwords assuming a reasonable length almost always perform better than random characters, and the maths shows that pretty steadily. We ASSUME a bad guy knows what we're doing, that's a given, but again it is still a much harder task for a bad guy even with perfect intelligence.

Maybe there is a difference between what is supposed to be protected. The login to some server based server? Or something I use locally like my tax files.

He wanted to rant and therefore didn't read the description of the "xkcd scheme" with enough concentration to understand it.

Legions of security people debunked Schneier, but unfortunately he didn't have it in him to retract his claim and update his post.

This blog post is the best example you can give of Schneier quitting academic discourse and becoming a pundit.

If you make a password from an alphabet of 64 characters (upper and lower case, digits, and some special characters), there are 6 bits per character of entropy so a ten character random password could have 60 bits of entropy.

If you are choosing words from a list 4000 words long, there are 11 bits of entropy per word and so you would need to string together five random words to get a password of equal strength. The big problem then is having enough space to type that many characters.

Edit: that's a pretty nice slide deck. Thanks for the pointer.

Since I still run into services where the "forgot password" mechanism emails your current password in the clear, this is unfortunately not as true as one would hope.

Personally, I'd rather bet on something like Diceware.

[0]http://www.lingholic.com/how-many-words-do-i-need-to-know-th...

Some words are way more common than others, and they are much more likely to be found in your passphrase if you didn't use an external random index generator (be it a set of dice or /dev/urandom), because of availability bias: you're more likely to chose common words, or even worse, uncommon words pertaining to your interests.

Diceware uses a smaller set (about 8K words), but if you select them truly randomly, you'll get close to 13 bits of entropy per word —guaranteed. I wouldn't cry too much over the loss of 2 bits per word, because Diceware words tend to be short.

Then again, even a word in a grammatically correct sentence is likely to have more than the 6-7 bits of entropy a character may have. I wouldn't bet on anything above 10, though.

I've heard the average entropy of English is 3 bits/character, in which case 14-15 bits sounds about right for a word.

91 characters, in 21 words. 4.3 characters on average, which would mean 13 bits of entropy. I don't believe it. It sounds like your source didn't account for word frequencies in real sentences, let alone grammatical constraints.

So just random words and half-words are appended, like: 'misfortune behold oratory plexum'

Then again, these things tend to just stick very well in my mind, so it may not be appropriate for everyone. Also, I only need to do this on certain services, so it's not that many to remember.

The hard part is when they then reply with "requires at least one upper case character, number, symbol, etc.". A certain XKCD comic comes to mind...

  Lorem ipsum random garbage 1

Is there anyone reading this who has chosen to implement such limits? If so, why?

I haven't, but here's one answer I got from someone who did.

The bizarre password requirements at $WORK have the property that, sometimes, a subset of a password will be permitted when the full password would not be. I contacted our IT department once with a specific example of an objectively weak password which was accepted, and a stronger password (at least, it contained the weaker password as a strict subset) which was rejected. I proposed a concrete, simple-to-implement suggestion for how to relax the rules to avoid this kind of paradox. (I don't remember what it was.)

He agreed with me that this was an undesireable outcome, and that my proposal was implementable. However, he said that the institution would nonetheless not implement it, because people were used to the old rules, and would be confused if they changed.

(When I asked how people could be confused if all the old passwords were still acceptable, and the only change was that new, stronger passwords also became acceptable, he stopped responding.)

I feel like underlying all of this, there's a lagging perception that "spaces and special characters are hard". But when all you're doing is hashing them... they're really really not. Whenever I hit a max length limitation, I'm automatically assuming that particular password is being kept in plaintext.