Dumb Password Rules

There's a not-uncommon pattern where someone gets an account compromised and starts a password tug-of-war. The attacker gets entry, and possibly changes the password, but doesn't own the recovery account, so the user finds the problem and uses email reset to change the password again. In this case, it's good to block the old (compromised) password, and bad to set a lockout that gives the attacker more time.

Of course, a lot went wrong in that story. Forcing email confirmation of all password resets can help, mandating re-typing of the old password for a change can help (against session hijacking, mostly), and any corporate or user-focused solution should probably have a response scheme for reporting and locking compromised accounts anyway.

But for social media style sites where the recovery system is "use your email recovery to fight for control", the reset time does seem like a threat.

As for other special characters, a properly implemented password storage system would just dump these directly into a key-derivation function before it ever touches a database, but I think you get those rules from a mix of: 1. people who are storing their passwords in plaintext and are worried about SQL injection attacks and 2. people who know to pass them to a KDF before storing them in the database and either have inherited some old rule about "no special characters" or who are not convinced that someone in the future won't make changes to the system such that special characters would become a problem, and are trying to make it more robust to potential reversions.

Not saying it's a good idea, but at least some people "doing things right" will still have somewhat reasonable concerns about special characters.

Generally, individual accounts don't get compromised at all unless they're a high-profile target, at which point guessable passwords become an issue. If you're a diplomat, CEO, or celebrity, you might get hit if you use "Password" or "123456". Otherwise, lockout rules and a general lack of interest will probably save you.

The real risk comes when hashed password sets get dumped. At that point, people start attacking the entire set to see how much they can crack (this is what the Ars articles were about), and this is where password security becomes a big deal. As I remember, the common attack workflow is something like:

1. Throw a top-200 password list at the dataset. (Lulzsec did this then named-and-shamed exclusively people with bad passwords.)

2. Dictionary attack on one-word passwords.

3. Dictionary attack on two-word passwords and one-word passwords with common tweaks (i.e. first-letter capital, trailing numbers). (I consider the XKCD somewhat misleading, since an alteration to bar pure-dictionary attacks remains a useful addition.)

4. Expansive dictionary work: common but nontrivial adjustments like o/0, l/1, or scattered capitals.

5. Brute force all short passwords. All of this goes basically unchanged with salting, it's just harder (and often, gets easier as you compromise a few salted passwords).

So yes, this stuff matters in predictable ways. Pretty much all of it is defense against password dumps, in which context it definitely matters. And in that context, password managers remain king - they'll block even dedicated attacks on a single user.