> The general attack model is what's known as an offline password-guessing attack.

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.

But he starts with saying the file can be processed offline. And I wonder, if one gets the "password" file to be processed offline, why can't he simply get the data too?

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.

Schneier is simply wrong there.

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.

Can you point to a good debunking?

Here you go: https://security.stackexchange.com/questions/62832/is-the-of...

After reading through most of that, it seems that the big problem with the XKCD scheme is that it's often impractical. Too many sites restrict password length and so you are forced to use the Schneier modification to get more entropy per character.

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.

Yep, unfortunately for passphrases the maximum acceptable password length on web sites tends to be the #1 factor limiting their use. I created sample passphrases and tried them on a handful of different sites to measure the problem. See starting slide 31 in this presentation (PDF): http://www.passwordresearch.com/files/How%20Secure%20Are%20M...

Do you know why sites would set a low limit? I can understand limiting to, say, a couple hundred characters, but 16 is ridiculous. These days, all anybody is going to store is a salted hash so the passphrase length should be mostly irrelevant.

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

> These days, all anybody is going to store is a salted hash so the passphrase length should be mostly irrelevant.

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.

Not on the road, but IIRC there were several in the blog comments.