> 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.)
Thanks for the reply. Sounds like another case of "we've always done it this way".
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.
Max length limits can also be imposed by actual cryptographic hashes. (8-char limits are admittedly implausible.) For example, bcrypt is generally considered a good idea for storing passwords, but has a length limit of somewhere around 55 bytes (http://security.stackexchange.com/questions/39849/does-bcryp... for details).
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.)