[tetrad]

Their advice for diversifying your passwords is not very good. If you are using the same password stem with a suffix determined by the site name, as

"m1p.5AsGs9LXo_HN" for HackerNews "m1p.5AsGs9LXo_RandomForum" for some random forum "m1p.5AsGs9LXo_WF" for Wells Fargo

and the random forum's database gets popped, how secure do you think your Wells Fargo password "m1p.5AsGs9LXo_WF" is? Less than 12486848 years. That goes from the realm of password cracking to some guy typing out all the abbreviations he can think of for Reddit or Twitter.

In case you're wondering, Wells Fargo will not accept "m1p.5AsGs9LXo_WF" as a password - too long!

[Piskvorrr]

That's the one thing which always leaves me speechless: what is the purpose of having an upper bound on password length?

To me, it always feels like they're putting up a humongous, blinking sign proclaiming "Proudly storing your passwords in plaintext since 1991!" (Most notable offender, last time I checked: Skype)

[marshray]

In practice, there will be some part of the system that breaks first when a password or any other field tries to grow infinitely long. Having a defined upper bound from the beginning of the design means you have a testable requirement.

That said, there's no excuse for setting the upper bound so low that any human ever gets their actual choice for a password rejected.

[tetrad]

It doesn't necessarily mean that they're storing it plaintext (ie it could simply be a front-end input validation). But in any case it doesn't inspire confidence that they're following best practices.

[Piskvorrr]

I'm somewhat skeptical of "we have a validation rule here, but it doesn't validate against any actual requirement, we just threw it in for the heck of it [image of dog piloting an airplane]." Even the bizarre "well, we have a CHAR(20) for the password, so we can't save anything longer" sounds saner than that ;)