Why don't password input screens include the site's password criteria?

6 points by phozy1 ↗ HN
If you type your password in incorrectly, or type the wrong password in, the website will almost never tell you their criteria for passwords.

I understand it could make it slightly easier for a person, who isn't you, to access your account; but it will also make it harder for a large amount of people. I would think it would be harder for more people, than it would be for the lazy hackers, that are too lazy to start creating an account to find out the criteria. Many people use the same set of passwords and just modify them depending on what website or program they are on. Why not tell people your criteria for passwords, so they have a much better chance of remembering their passwords, to use that website or program

8 comments

[ 3.5 ms ] story [ 37.8 ms ] thread
I've seen a site do it, I don't remember which one.

The issue here is that password UX is simply not taken seriously. If it was, password criteria wouldn't be so "stupid" in the first place.

http://passwordistoostrong.tumblr.com/

> Many people use the same set of passwords

We don't want to encourage that. It makes your account more likely to be compromised.

This prompts another question: why don't password fields have the logos of password managers to hint people in this direction? If it is the signup page, then that would decrease conversion rates. But on the login page, that would be fine, no?

There is no good reason. Ever tried updating password on Authorize.net? Good God! It's the dumbest shit ever. It doesn't tell you the whole criteria in a single sentence but goes through the list and displays them one by one. And resets everything you typed in the process. Kill me now
What I do on Authorize.Net, and other sites that have password age limits and lack a clear explanation of the rules on the password change page of the rules is tweak the old password.

For example, if the old password was '4phOhc}ve6BErc' I might do one of the following to come up with the new password:

• Increment a digit: 5phOhc}ve6BErc

• Increment a letter: 4qhOhc}ve6BErc

• Change the case of a letter: 4PhOhc}ve6BErc

• Transpose a pair of adjacent characters: 4phOh}cve6BErc

Those transformations almost always result in a password that still obeys the rules.

Make it easier for would be attackers.

If someone knows the minimum requirements are 8 characters, alphanumeric, with one capital chances are the majority of users are using that minimum.

Add to this most people use easy to remember and common passwords one wouldn't need to brute force every possible combination just the most likely combinations. If someone is brute forcing and they can't get it by just going through a list of the most common they will probably just stop and move on to the next user. Attackers are not often after one user they are just trying to get the easiest ones.

I think the OP addresses this in his second paragraph.

In the case where registering is open for the public, it is trivial for a would be attacker to find the password requirements. They only need to go through registration to find the password complexity. This means that you are incurring a usability cost with out a security gain.

One limitation of showing the requirements at log in I could think of is that it would require all users to have the same password requirements. This is just a thought, but if the password requirements were random throughout the userbase, it would make it more difficult for your users to use the same password across different sites. For example, if you require 25% of your users to have two capital letters, 25% have 2 symbols .. etc, it is less likely they would have gotten the same requirement from a different site.

Recently I've just been using zxcvbn[0] to score passwords client-side, skipping the extra server-side criteria. It seems to be working nicely. Educate, don't infuriate. :)

[0]: https://github.com/dropbox/zxcvbn

Usually form validation occurs on the server-side, written such that if a form's post body is invalid, a human-readable set of errors will be returned to the client to display. In this context, the password is just another field mapped to a specific conditional check -- which, if evaluated as false, simply means adding a canned message to the said set of errors to return.