I’m just doing some work on a user registration form, and would like a bit of advice about best practice regarding the password input. These are my thoughts so far:
Set a minimum length
Don’t restrict chars
No need to make them fill in password twice
Have a toggle option to remove hiding of the password
For the toggling of the password between hidden characters and plain text, does anyone know if there are usability issues with password vs text fields for screen readers, e.g. does the screen reader read out what you’re typing in a text field but not in a password field? (I’m thinking whether this should only be enabled as an enhancement using js, or if it should be basic functionality).
If the user submits the form, but there is an error, best practice is to fill out the values of all the fields with what the user entered, so they only have to correct the error and don’t have to retype everything again. Is it advisable to fill out the password field in this situation, or would you leave it blank so the user has to retype it again? If so, why?
If you’re going to set a minimum length, don’t make it more than 6 characters. Make sure that any restrictions on length or allowed characters are clearly communicated to the user before they complete and submit the form. I would try to avoid restrictions if possible - don’t require people to include numbers or capital letters, don’t forbid non-alphanumeric characters … the more restrictions you have, the more likely people are to get frustrated and give up, lose their password or just write it down. The most secure password is usually the one that the user chooses themselves and doesn’t have to write down.
I don’t find it a hassle to enter a password twice - I would rather do that than risk creating an account with the wrong password because of a typo. One usability advantage of masked passwords that Nielsen overlooks (not to mention the security aspect) is that when you start typing in a field and it comes up masked, you know it’s the password field, and vice versa. Many times I have been saved from accidentally submitting my password in the username, search or post field because it’s come up unmasked, highlighting my mistake before it’s too late.
This is a good idea, some one is bound to be lazy and pick a two char password. This is for the protection of the (not so bright) users.
Don’t restrict chars
WHAT!?? Ok if theer are naive users out there , then there are also evil ones too. someone is going to enter : ’ or ‘1’='1. Restrict characters.
No need to make them fill in password twice
The prblem is you are typing blind. I made 2 typos in this post thus far… what if I thought I typed “zombie” but actually entered “zpmbie”?
Have a toggle option to remove hiding of the password
I guess… but again now you arent protecting the user from prying eyes ( I admit it’s naive, Ilook at their keyboard hahah) but really why make it a higher security risk just cause now you can blame the user?
That’s my take on the OP. Oh and I would consider implementing what rk007 said.
Thanks everyone for your advice. I do value it, even if I might not agree with it!
Agreed.
I partially agree on this point - it depends on whether the user uses the same password for all sites and whether you implement protection against brute force password hack attempts.
If the user uses the same password on all (or a lot of) websites, then in my opinion there is more chance that one of those websites will get hacked and reveal the user’s password than there is that the user would have their written down password stolen (unless they post-it to their monitor).
If you don’t implement protection against a brute force attack, then a simple password chosen by the user will be easier to crack than if you force the user to include non-alpha numeric chars etc.
So I would agree with your statement in the majority of cases, but it will not always be true.
You are missing that the password field would be a password field by default - it will only act like a text field if you toggle it. If you toggle it to act like a text field, then I hope it would be pretty obvious that it was a password field.
Agree with your points, but points 1 and 3 are not directly related to the question.
I have to disagree with you quite strongly on this one. In my opinion users should be able to have whatever they want as their password. If you’re trying to prevent SQL injection at the validation phase rather than the database insertion phase you have other problems. Plus, there is no stipulation that the password will even be saved in an SQL database.
If you don’t toggle the password to appear as text, yes, you are typing blind. I would hope that you would type a password more carefully than you do a forum post. If you do mistype it, you can always reset password when you find out you can’t login. It would be interesting if there were any stats on how often people get mismatched password fields to see if this is a real problem or not.
If the user toggles password reveal when there are people watching that might steal the password, then yes, I would blame the user. I would think (again, no stats to back it up), that most people register for websites at home though.
If you’re trying to prevent SQL injection at the validation phase rather than the database insertion phase you have other problems.
how can you tell if the it wont become an exploit to break the DB ( yeah I assumed SQL, just for the sake of example) at the time of sign up. In another words, it just seems like a bad idea to actually LET the user CHOOSE to use a string which is essentially an SQL hack. As song as am on the topic this is the VERY reason why you encounter many of these requirements at sign up. to protect people from their own ignorance lest they chose: ‘’,‘123’,‘abc’, ect as their pass…
It would be interesting if there were any stats on how often people get mismatched password fields to see if this is a real problem or not.
am sure the numbers will over overwhelmingly favour the LACK of typos. I have an old comp and and lack finger coordination, still… those are the users you should most take into account ( lowest common denominator).
most people register for websites at home though.
I know from personal experience of siblings stealing online identities. Point being why REQUIRE that the user go home… or find a secluded corner before he/she signs up.
If you are properly storing passwords. IT DOES NOT MATTER WHAT A USER ENTERS. If you are properly handling passwords. A user can enter an entire SQL string if they so wanted in a password field when it is properly handled. Do you want to know why? You should be throwing the password into a hashing digest. Guess what comes out of the digest? Nothing dangerous. Let the user enter whatever they want in the password field it makes no difference when properly handling passwords, because you should be hashing that password before it even gets near the database making it a none issue.
SQL Injection is a none issue.
My stance on passwords. Let the user control their own security. If they want to toggle the password field to plain text while people are watching that is their business. If they want to put in a weak password, that is their business. The only aspect of security I control is on my end, storing those passwords in a secure matter. I could give two…whether a user uses “password” its none of my business or my concern. your responsibility only extends to properly storing and handling passwords, not enforcing strong passwords or enforcing a user enter their password in some super security wing of their house. Your website is not that sensitive.
Granted if I am creating something with high sensitivity like a banking website or top secret documents then you probably want to enforce more strict rules. However, the majority of web sites do not fall into those categories.
Definitely - if someone wants to use the entire text of war & peace as their password then it will take them a long time to login each time but it still only takes up the same space in the database as the person with the one character password.
That is the only rule that must be applied with regard to passwords - that it be hashed and only the hash be stored.
WHAT!?? Ok if theer are naive users out there , then there are also evil ones too. someone is going to enter : ’ or ‘1’='1. Restrict characters.
I agree with djeyewater on this. SQL injection should be handled with proper escaping or prepared statements. And if you’re properly escaping – as you should always be – then it doesn’t make the slightest difference what the user enters.
If you are properly storing passwords. IT DOES NOT MATTER WHAT A USER ENTERS. If you are properly handling passwords. A user can enter an entire SQL string if they so wanted in a password field when it is properly handled. Do you want to know why? You should be throwing the password into a hashing digest. Guess what comes out of the digest? Nothing dangerous. Let the user enter whatever they want in the password field it makes no difference when properly handling passwords, because you should be hashing that password before it even gets near the database making it a none issue.
The first two are good and standard. The last two are a bit more questionable, and may require some usability trials and research. Some questions that come to mind are: Will users bother toggling the field to make sure they typed the password correctly? If they toggle it to plaintext, will they bother to toggle it back? If they toggle it to plaintext and leave it that way, does that defeat the purpose of the password field?
Perhaps you could try exposing only a small percentage of your users to this new style of form and see how they react. Make sure you have solid analytics that will capture their behavior.
If the user submits the form, but there is an error, best practice is to fill out the values of all the fields with what the user entered, so they only have to correct the error and don’t have to retype everything again. Is it advisable to fill out the password field in this situation, or would you leave it blank so the user has to retype it again? If so, why?
Leave it blank. Prefilling the password means it will be visible in the source, and probably cached on the user’s computer.
I didn’t think about that, but it makes sense, thanks for the advice.
If you mean that you shouldn’t let any user have ’ in their password, then you are reducing security as there are less possible password combinations that a user can choose. It also may be annoying for the (admittedly absolutely tiny amount of) people that would like to use ’ in their passsword.
It is possible that rather than deterring hackers, blocking of ’ in the password may entice them. They may assume that you are doing this because you aren’t escaping values into the db. They may think that you could also be making other security mistakes, and so probe your site’s security more strongly than they would otherwise.
Checking the password for certain characters will also reduce efficiency somewhat, since you need to do the check. Though that point is moot really, since a password check should be slow anyway. I don’t think that restricting characters is a good idea, since it has no benefit. But I wouldn’t say it’s a really bad idea either. Checking the password against a list of known weak passwords might be a good idea though.
It’s not required that user toggles the password field to plain text at all. They should only do this if they weren’t confident in what they had typed / were typing and didn’t mind the password being visible on screen. (Of course we all know that users don’t always do what we think they should).
I think we should offer a link to the user where they can generate strong password and use that while registration, some person here has suggested not to ask password twice, but I would say this is very important to ask password twice and validate them that both are same or not. I can say this by my experience that many times I have entered wrong password at first and, then realized by feeling the password second time after validation for password match.
hahah) but really why make it a higher security risk just cause now you can blame the user?