
How *NOT* To Do A Password Field - edent
http://shkspr.mobi/blog/2014/04/how-not-to-do-a-password-field/
======
gabemart
> If you have to restrict the length, use maxlength in the input field.

The problem with this approach is that, for longer passwords, the user may not
be aware that the maxlength property has prevented the field accepting the
last n characters of their password. They may believe they have successfully
submitted their entire password. In other words, they may believe their
password is

    
    
      i_love_peanut_butter_and_j3lly
    

but it's actually

    
    
      i_love_peanut_butter_a
    

This may work for a time, but is likely to cause problems down the road.

------
sadfnjksdf
> Don't let a user submit a password which doesn't meet your requirements. Use
> JavaScript to disable the button and highlight the text of your password
> policy.

If you are going that route, please change last line to:

"Use JavaScript to disable the button and highlight the text of your password
policy (in addition to server-side validation)."

However, consider using a "poor password", "good password", "great password"
approach that changes as you type and don't have a short max length in your
validation, this way you can promote entering sufficient complex passwords of
longer length. The best of these I've seen is a "progress bar"-looking thing
under the password fields that also uses color changes (just don't use green
as bad and red as good, and be aware of color-blindness/blindness) and text
under it to describe how good or bad the password is.

Here is one of Microsoft's recommendations. It looks a lot like the cartoon in
the post: [http://technet.microsoft.com/en-
us/library/cc786468%28v=ws.1...](http://technet.microsoft.com/en-
us/library/cc786468%28v=ws.10%29.aspx)

That helps but is far from good enough. Read:
[http://en.wikipedia.org/wiki/Password_strength](http://en.wikipedia.org/wiki/Password_strength)

Focus a bit on entropy to go with that colored-progress bar I talked about:

"It is usual in the computer industry to specify password strength in terms of
information entropy, measured in bits, a concept from information theory.
Instead of the number of guesses needed to find the password with certainty,
the base-2 logarithm of that number is given, which is the number of "entropy
bits" in a password. A password with, say, 42 bits of strength calculated in
this way would be as strong as a string of 42 bits chosen randomly, say by a
fair coin toss. Put another way, a password with 42 bits of strength would
require 242 attempts to exhaust all possibilities during a brute force search.
Thus, adding one bit of entropy to a password doubles the number of guesses
required, which makes an attacker's task twice as difficult. On average, an
attacker will have to try half of the possible passwords before finding the
correct one."

Following on that with:
[http://en.wikipedia.org/wiki/Entropy_%28information_theory%2...](http://en.wikipedia.org/wiki/Entropy_%28information_theory%29)

That states the limitations thereof, so entropy alone is not good enough:

"Limitations of entropy as a measure of unpredictability

In cryptanalysis, entropy is often roughly used as a measure of the
unpredictability of a cryptographic key. For example, a 128-bit key that is
randomly generated has 128 bits of entropy. It takes (on average) 2^{128-1}
guesses to break by brute force. If the key's first digit is 0, and the others
random, then the entropy is 127 bits, and it takes (on average) 2^{127-1}
guesses.

However, entropy fails to capture the number of guesses required if the
possible keys are not of equal probability.[17][18] If the key is half the
time "password" and half the time a true random 128-bit key, then the entropy
is approximately 65 bits. Yet half the time the key may be guessed on the
first try, if your first guess is "password", and on average, it takes around
2^{126} guesses (not 2^{65-1}) to break this password.

Similarly, consider a 1000000-digit binary one-time pad. If the pad has
1000000 bits of entropy, it is perfect. If the pad has 999999 bits of entropy,
evenly distributed (each individual bit of the pad having 0.999999 bits of
entropy) it may still be considered very good. But if the pad has 999999 bits
of entropy, where the first digit is fixed and the remaining 999999 digits are
perfectly random, then the first digit of the ciphertext will not be encrypted
at all."

But, even checking for common passwords (search and you can find numerous
articles on that), etc. is not good enough. You must also tell people not to
use easily guessable personal information in their passwords. Your birthdate,
then "$" then your son's name then "$" then his birthdate may have "ok"
entropy, but it would be easily hackable for anyone with elementary knowledge
about the person.

That starts to get into the fallacy of security questions to reset your
password, though. Security questions are terrible, and I cannot believe that
financial institutions use them. If you hack the email account and know enough
personal info, you bypass the password. That's bad.

But, everything is hackable, eventually. There are no hard rules that cannot
be broken. Even our understanding of physics, etc. is incomplete. Anything is
possible.

------
NateDad
Actually, please do NOT have a maxlength on your password field. Instead, if
the contents are too long, disable the submit button and tell me my password
is too long. Why? Because I never actually _type_ in a password. I generate a
long one and copy & paste it in. And when you put a max length on the field, I
think my password is FooBarBazBatAwesome, and you think my password is
FooBarBazBat.... and that is going to _screw me_.

I've had this happen on more than one occasion. For God's sake, do not put a
max length on your password field. It silently drops any characters that are
too long without notifying the user that it's doing so.

------
ceejayoz
> If you have to restrict the length, use maxlength in the input field.

This bit is really bad advice. Maxlength stops you from typing but doesn't
give you any indication it's happening, so I'd be happily typing out a 20
character password without realizing it's being lopped off somewhere.

If they ever lift the maxlength restriction, my password suddenly stops
working for no apparent reason.

~~~
NateDad
Ha! Glad someone else agrees :)

------
Fr0styMatt
YES!!!! TELL US THE DAMN PASSWORD RESTRICTIONS ON THE FORM BEFORE THE PASSWORD
IS ENTERED!!

I hate hate hate hate (can't you tell I really hate it) when I use LastPass's
awesome password generation, only to save and submit and then be told by the
site the password is bad for whatever reason.

Please just do this. THEN we can start talking about those other restrictions
(why is my password limited to 16 or even 32 characters?!?!).

Lots of frustration here, I'm pretty certain it's shared by a lot of people.
Does feel better though :)

Now I'm not a web dev but I'm interested and echo the question that someone
else posted below - why is there a length restriction on passwords
(notwithstanding a restriction to stop strain on the server)?

------
sadfnjksdf
On a related topic, a troubling new trend (to me) is the reliance on passwords
being automatically generated/kept by a tool. You are putting your trust in
something else for something only you (or a select group) should be trusted
with. If everyone were to start doing this or a vulnerability was found in it
and exposed, then attackers would exclusively target the tool or the password
store, making many at risk.

It is a trade off, because you have the ability to use significantly more
complex passwords that are harder to brute force or guess using personal
information. Just don't forget that you are providing new attack vectors in
the process. If they access your password store and you didn't know about it,
how at risk would you be if they were to unlock all of your passwords?

Do you really understand how the password store and password generator work?

------
Tloewald
The problem with really awful password interfaces lies mainly with big
institutions (banks!) who are unlikely to be influenced by bloggers linked on
hacker news.

Ever since switching to a password manager (1Password in my case) I've become
acutely aware of how many places have ridiculous restrictions on passwords
(especially _maximum_ lengths and character restrictions), and the worst
offenders are invariably banks and financial sector sites.

~~~
chrismcb
It seems like the more secure you need your data to be, the worse their
password restrictions are. Restrictions such as no special characters, or an
arbitrary short length raises a red flag. It says they don't really know what
they are doing, and it makes me wonder what else is broken.

~~~
SimHacker
And no SQL keywords allowed in passwords. Because they like to advertise that
they don't bother escaping user input before concatenating sql strings to
store plain text passwords in the database.

[http://stackoverflow.com/questions/13738141/blacklist-
filter...](http://stackoverflow.com/questions/13738141/blacklist-filtering-
data-for-sql-keywords)

~~~
krapp
I'd bet that patterns like

    
    
        $db->execute("INSERT INTO USERACCOUNTS ('username','password') VALUES ('".$_POST['username']."','".$_POST['password']."')");
    

are more common than anyone wants to believe.

~~~
SimHacker
The PHP manual pages are full of user comments with helpful suggestions just
like that, which incompetent programmers copy and paste into production
systems. But I think of it as a good thing, an instance of evolution in
action, because banks that hire such stupid programmers deserve to have all
their money stolen from them.

------
Spongeroberto
If you _must_ have a maxlength, please be sensible. I've seen plenty of sites
use 12 as max length - which is really not that much.

Also, requirements to what characters must be used (at least one number, at
least one upper case letter) doesn't do much to increase security I think.
Just let me enter whatever I want.

------
robinhoodexe
I hate sites that restrict how complex my password can be. Seriously, NemID, a
Danish ID every person has that's used for everything (banking, among other
things), don't allow special characters. What the heck. It's like they want it
to be insecure.

------
PavlovsCat
_Why_ would you have to restrict the length at all? I could see something like
a few thousand characters max, to avoid making it easy to strain the server,
but other than that, you're not supposed to store it as is anyway, and if you
hash it, the input length doesn't really matter... what am I missing?

~~~
krapp
You're missing the obvious - that such restrictions are a sign the site does
probably store passwords in plaintext.

Although _maybe_ they aren't but they still want to make sure they meet some
arbitrary standard of "randomness" to make it less "hackable."

