As we promote passphrases, we need to make it clear that not all phrases are created equal.
Phrases that match the rhythm of human language, and phrases that are even only somewhat based on anything that has already appeared anywhere -- lyrics, song titles, movie quotes, phrases that appear on Wikipedia, etc. -- are subject to guessing. The password cracking community is hot on this trail, and really pushing the envelope in this area. "Myd0ghasfle@s!" is certainly better than "abcdefgh" or "Summer2015!", but it is not sufficiently resistant to state-of-the art attacks. These attacks can quickly combine phrase lists with transformational rules, and really tap into the psychology of how people select naive passphrases.
Put another way ... we need to make sure that users do not walk away thinking that "itsmypartyandillcryifiwantto" is a good passphrase.
One problem is the word "passphrase". The layperson expects something called a "passphrase" to be a real, grammatically correct phrase, but that's exactly what we don't want them to use. Such phrases are inherently easier to guess. Only randomly-selected words provide resistance to both brute force and rules-based attacks.
The best balance of "memorizability" and strength is to use "Diceware"-style passphrases, just as that XKCD suggested (but perhaps with some adjustments to the size of the word pool and number of words). The words need to be truly randomly selected, and drawn from a relatively large pool of words that are nevertheless familiar enough to be easily remembered. An open-source, client-side, JavaScript implementation is available here, and some great statistics about the strength of the resulting passwords are shown there.
The sheer numbers behind Diceware-style passphrases are significant. When implemented correctly, even if I tell you which dictionary I've drawn from, and how many words that I used, brute-force cracking is still infeasible for any modern (and even many retired/outdated) password hashing methods.
One implementation hitch is that many sites either A) still apply naive complexity requirements to very long passwords, or B) don't allow passwords longer than a certain length.
To make Diceware-style passphrases compatible with naive complexity rules, users can add their own additional rule. Such a rule can make randomly generated passphrases compliant with such complexity rules. For example, I can always capitalize the first word, and appending "1!" at the end ("Correct horse battery staple1!") Even if I tell someone what my personal additional rule is, brute-force cracking is still infeasible.
If a website has an artificially low length cap (such as 15 or 20 characters), rather than trying to cram a shorter passphrase in, I recommend falling back to a randomly generated password that maxes out the allowed length, and storing it in a password manager.
The best things that web developers can do to support good passphrases is to:
- relax complexity requirements once a sufficient length is met, and
- support a high maximum password length (such as 128 characters)
