>>>https://blog.codinghorror.com/password-rules-are-bullshit/
>>>
>>>I keep pointing people at the XKCD cartoon, but Atwood expounds further on the topic.
>>>
>>>If you're a dev or sysadmin in a position to influence password policy, PLEASE do the right thing.
>>
>>Hmm. Since most servers just store a hash value of the password why would longer be better ?
>
>If you're talking about password hashes being compromised, the answer boils down to the fact that the hash value of a long password is different from a short password.

Different in what way ?

>That means that attacks such as cloud-based rainbow table lookups will likely fail; those tables have precomputed hash values typically only up to some (relatively short) length and limited character set. In contrast, the hash of a short password will be included in rainbow tables and getting the password is just a lookup.
>
>AFAIK salted hashes are best-practice for storage i.e. https://en.wikipedia.org/wiki/Salt_(cryptography) . If a server stores salted hashes then from the POV of that particular attack vector a long password would have no advantage over a short one.

I've been using a PBKDF2 implementation (with 12 byte salt and 12 byte hash) for a while - good enough for the sites in question.

>But all this is just discussing the subset of problems related to compromise of stored hash values. The article (and the original XKCD cartoon, for that matter) point out the practical advantages e.g. greater resistance to brute-force attacks, less chance of Post-It notes on monitors etc.

True. But of course, if we are discussing web sites then, given that HTTPS may be the weakest link, the whole discussion is irrelevant :-}