> Caring what characters are in the password heavily implies that the site is not hashing the plaintext password in any way, and scarier still, may just be storing the plaintext password as plain text.

I don't think that is true at all.

I may very well want to put a few simple rules I validate serverside, such as

1) No username in password 2) No email in password 3) No list of 100 most common passwords in password

All of which require me to look at the text for your password, none of which mean I am storing it in plaintext.

> I don't think that is true at all.

I've run into a couple of sites that reject passwords containing ', %, and other special characters that suggest there may be some truth to it.

If you're scrubbing input as if it's about to be insert into a database via SQL, then there's really only two possibilities. Either a) you're running legacy code that still does the check and does blind escaping (which has its own set of implications) or b) you really truly are storing passwords as plain text.

Or they're cargo-culting on decades of experience where special characters are verboten.

Hah, good point. Although I do have to wonder: When does it turn into filtering by force of habit? After all the legacy cruft has long been forgotten and is no longer maintained?

Because the other monkeys will chew you out if you start doing it differently all of a sudden. Nobody knows exactly why we're doing it the way we are doing it, but it is complex, and changing it might break something.

It's the five monkey experiment:

http://johnstepper.com/2013/10/26/the-five-monkeys-experimen...

It's not always that.

Let's use the "filtering chars from password" example above. You can't put some special chars in password field, and you want to change that so it's doing normal hashing where special chars don't matter.

In a larger org, even changing a practice like that so that it "makes more sense" can have a big ripple effect.

You have to

* explain to someone else on the team who came up with the original process that it's flawed (and why)

* explain to other dept that they need to update their testing process (and why)

* get support dept to change their language/process

* change outbound messaging in all affected places (perhaps with code you can't touch, involving other teams)

* possibly have a flag that deals with 2 versions of data

Even if your change brings you in to line with normal/safe practices, you may have to fight multiple inane battles, spend loads of time and political capital, and at the end of the day, you'll be able to also accept a !"@+'$ in a password field? Most people will not grasp the bigger issue at play.

At a small business convincing colleagues isn't that hard. At a larger corporation, getting the rest of the team on-board is the job of whoever is in charge of defining security policies and such. Not allowing characters present on all keyboards and input devices (!"@+'$) statistically increases the risk of people picking weaker passwords then possible, and he/she will guide that change through the proper processes, for example to make sure that any client software interacting with the backend is aware of the upcoming change. Same as with any security issue (e.g., the deprecation of SSLv3 ciphers in favour of newer TLS versions).

If a business can't handle a change like this, something is really broken in the development pipeline. Granted, that describes a lot of medium sized companies…

Take that one 'request' - possibly initiated by a jr-mid level developer - and stack it up against the 500 other todo items in the pipeline. You can make those arguments about "statistically increases the risk of people picking weaker passwords " - unless this increases a bottom line or comes out of someone else's budget, this sort of 'bug' is going to be really low down on the totem pole for all the reasons I mentioned, and a few others.

You can says "the process is broken" but it's also that same process that got people where they are, puts food on their table, pays for the lifestyle, and precious few people are willing to ever rock the boat at any company for anything.

Which gets back to some of the cargo cult thing too. It's not uncommon in a large enterprise to smack up against things like "Years ago we paid a highly trained Security Consultant a large amount of money to develop our Security Guidelines, who are you and where are your security credentials to tell us to do things differently?"

Even worse when that "Security Consultant" is still a retained coworker with a fiefdom to maintain by war at all costs, a wizened old greybeard whose seniority will always trump yours, and/or your boss.

Or they scrub ; from ALL arguments before considering what kind of argument it is instead of scrubbing only where that might be needed.

There's a related issue that I've seen in some banks, which prevents you from using passwords LONGER than a certain number of characters (usually 8 or 10). The only reason I can think this is happening is because they don't hash them and they need to fit in their database column. I took my money out of that bank the next day.

Could just as likely be some process that still needs to pass the password around in a fixed-length file format to some ancient backend process written in COBOL living in the cthulian abyss deep in the bowels of the bank that no one dares rewrite from fear that it would destroy the bank from inside.

All of those checks can easily be done client-side, though. Of course this means you can't guarantee that none of these rules are violated, but I suspect that the users capable of bypassing this aren't the ones you're concerned about anyways.

The server does have to have access to the plain text password in memory, you know. I don't see why you think it's worth sacrificing guarantees of password strength to uphold some kind of taboo.

No it doesn't. You can perform the first pass of salted hashing on the client-side.

This should not harm security, but it can improve it if someone on the datapath is logging requests but does not alter them.

so you just replaced the password with another secret, the hashed password. An attacker would now not need to gain access to the original password, but needs the hashed password - which will be logged just like the PW.

The only security benefit is that it offers a bit of support for those that are reusing passwords since it doesn't expose the plain text.

Most people reuse passwords, so that isn't a trivial benefit.

Isn't that what SSL does? And if the SSL between you and the destination is compromised, you don't even know if the hashing algorithm you asked the client to use is actually the one they used.

Yep. And importantly, SSL is securing more than just the password - if you just salt + hash client side, then anyone watching gets to do a replay on that value instead of the original.

> You can perform the first pass of salted hashing on the client-side.

Not really. JavaScript crypto is fundamentally broken: an attacker, malicious server or disgruntled employee can replace server-side JavaScript and remove the client-side hashing at any time. This is, notably, why Firefox Accounts are completely and totally insecure (and hence why Sync is unsuitable for storing any private data at all).

Can you reassure me about the worst horror I've seen?

That is: a listed-and-enforced ban on obscenities in passwords. Is there any world in which that company isn't butchering their security in some serious way? (It's Time Warner, so not a small-time deal here).

Or, they submit the password over HTTPS, validate server side, then hash and store in the DB?

There is no reason to assume rejecting of a + means they don't hash, and browsers escape the password for you in POST/GET etc. The fact that + is used for space really isn't relevant.

(That said, I think it's pretty stupid to "validate" passwords beyond checking for "12345", "password", a min length, and other public info. e.g. your password should not be your name or date of birth. Anything any password generator spits out, so long as it meets the min length criteria, should be accepted).

> Anything any password generator spits out, so long as it meets the min length criteria, should be accepted

It annoys me to no end when I have to hand-craft a password to stay within the silly rules of some service.

Be vocal about this! Keep complaining to the services you use that don't accept such valid passwords. Banks for example are notorious in insisting on short passwords and arcane limits on which characters to use (ING in the Netherlands limits you to 20 characters, and nobody there seems to be able to explain why).

With banks there is other problem, because they often use partial passwords. They are password manager unfriendly and often limited to 16 characters.

Société Générale uses the client ID and a 6 digit passnumber (sent via physical mail) with a digital numpad (you have to click) where each number is randomly placed.

So secure.

And they force a change every 3 months. As if a new 6 digit pass was more secure than the last 6 digit pass.

[https://en.wikipedia.org/wiki/Société_Générale]

Sadly at some places it's intentional so your password matches existing PIN systems or is "easy to remember" so you're not as easily locked out of your account. I wish in those cases there was a check box that says, "I know what I'm doing, leave me alone."

Speaking of annoying validations, my name has a hyphen in it but you'd be surprised how often that's rejected with the familiar, "Please enter a valid last name." Sigh.

My partner has a hyphenated first and last name. So many systems refuse to accept that, and even regular humans struggle with understanding it!

Had this bug in a system I was working on. Pushed a patch in april.. and there still is an ongoing discussion whether it should be merged or not.

Why is there a discussion? What do the people who don't want to take the patch say? "We don't care if we lose customers with unusual names"?

Because of code style (I do not mean spaces or tabs, it is beyond that). Different developers have different ideas of how a function should behave, where it literally has no effect on how the rest of the system works.

My last name starts with oo, which many humans struggle to understand. It almost always becomes do, or co.

As much as I agree that most artificial limits on the passwords are silly, there's a reason for at least limiting to latin1 charset - or maybe even a bit stricter. How sure are you that strings are always unified the same way between the browser and hashing? Have you tested that you can login from a browser which prefers CJK encodings and each of the UTFs? From all browsers? Maybe it works, maybe your framework deals with this without issues. But if not, do you really want to chase those mysteries in the future?

Btw, almost nobody is actually storing hashes as binary blobs. Pretty much every framework I know stores either base64, or direct hex encoding of the value.

We reject Unicode control characters, surrogates, private use code points etc. Passwords are sent in a UTF-8 encoded JSON over TLS. They are normalized using NFC.

For more fun, try putting a "--" (two consecutive hyphens) in many fields in the AWS console. Not allowed, I guess because they're passing it to shell commands somewhere along the line?!

Not likely. That's the comment start marker in many dialects of SQL.

For commands, shell metacharacters like `, |, &, and $() are much more important.