When a site insists that certain characters are not allowed in passwords, that is strong indication that they are storing them clear-text in text files.

Those characters are disallowed because they would cause delimiting issues for the shell/sed/awk/perl/php crap they are using to process those files, or db injection attacks.

A proper password hashing function takes any byte string.

It's often just a reflexive behavior on a website. Fields which have to be displayed back to the user naturally tend to have reasonable restrictions on what characters they can contain (no linebreaks is a common one, for example). The fact that passwords will never be displayed back to anybody (ideally) is no deterrent to your typical business analyst writing a hundred page spec for the account management pages, and just like every other field on the site they will place some arbitrary length restriction on the field, and pronounce that certain special characters are off limits. Programmers will then implement the restrictions because hey, it's an easy two points.

There are, actually, a couple of reasonable UX reasons for placing some restrictions on the characters someone can use in a password. If you hope that they will be able to enter the same password from another device later, you want to encourage them not to exploit all the wonderful input possibilities afforded by their plug-in emoji keyboard on their phone. Sadly I don't think this kind of reason underlies any restrictions I've ever seen in the wild.

Password has to be compatible with phone input -- legacy 0-9 phone, not mobile computing devices.

Why would this need to be restricted to A-z 0-9? Isn't it safe to assume that nobody will be typing in passwords from their land line?

I can give the quantum of the benefit of the doubt and assume that they're just possibly overly defensive for SQL injections if they're using the DB to do the hashing. They should be using parametrization anyhow and HAND, but maybe they missed that memo.

>When a site insists that certain characters are not allowed in passwords, that is strong indication that they are storing them clear-text in text files.

Except it really isn't, while stupid this is hardly uncommon in software that does hashing.

Just today, I tried to return something on staples.com. They have a field called "optional comments". I left it empty, and got an error saying "Sorry, but an error has been made. Please check the following highlighted field(s)." with the empty box highlighted in red.

Did you report the bug? (Perhaps in the "optional comments" field.)

I expect the amount of effort it would take to find someone who could do something about it is more than it's worth.

I've reported bugs in Google products before, but it's usually just not worth chasing a company down for something that doesn't really impact me, and often they'll just refuse to acknowledge the problem or refuse to fix it anyway. E.g. the issue I described at https://news.ycombinator.com/item?id=10478264. Since then I usually won't bother unless it's hard to work-around or the company has a known bug-tracker.

I once went to a lot trouble to report a bug in an online precious metals trading site, and they gave me, like, 1% of an ounce of silver as a reward. :-) At the time, I seem to recall figuring out it was about $50. Of course, I had to open an account on their site in order to claim it, and there was a large initial deposit, so blah, nevermind....

I don't think it's safe to compare every internet site to Google. Google is notorious for not having good support, but many other companies take customer feedback very seriously.

I mentioned google as an example of a company with a public bug-tracker, not as an example of one that treats reports poorly.

Probably the weirdest password requirement I've seen was the one for my college's email: it had a maximum of 10 characters, and required it to contain no dictionary words or reverse dictionary words. I never figured out why they would have such strict requirements, and also force it to be so short.

My university required us to change passwords every semester, and the password couldn't contain a similar enough substring of any of your old passwords. (I think 4 characters was the threshold, it would also detect reversed substrings).

I didn't really know much about web dev or security at the time, but thinking back to it now, there is no safe way they could have done that.

Technically, they might have been able to take the new password, which would traditionally not have been hashed on the client side, and try and permute it to see if it hashed to the same value as the old hash. Granted, with current best-practices in stretching, it probably shouldn't have been feasible to do even that -- but for salt+sha1 it might have worked.

They probably didn't though.

Actually my university requires exactly six characters for library passwords. They may only be changed by the library personnel and you must either write them down on a piece of paper for them to type or just spell it out loud...

Probably a legacy plain-text database field... if it makes you feel any better. :/