SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    110
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Best practice when asking a user to enter a password as part of registration process

    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

    This thread on stackoverflow has some good discussion on the last two points: Why should we ask the password twice during registration?

    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?

  2. #2
    Mouse catcher silver trophy Stevie D's Avatar
    Join Date
    Mar 2006
    Location
    Yorkshire, UK
    Posts
    5,881
    Mentioned
    122 Post(s)
    Tagged
    1 Thread(s)
    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.

  3. #3
    SitePoint Member
    Join Date
    Apr 2013
    Location
    Pakistan
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As you are designing your custom registration, here my suggestion:-

    • always use Ajax functionality
    • in case of error, only ask the user to correct error field. (only if you have strong server side checks, then you can leave password field as it is)
    • Always use mixture of Client side + Server Side authorization checks



    thanks

  4. #4
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,791
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    * Set a minimum length
    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.

  5. #5
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    110
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Thanks everyone for your advice. I do value it, even if I might not agree with it!

    Quote Originally Posted by Stevie D View Post
    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.
    Agreed.

    Quote Originally Posted by Stevie D View Post
    The most secure password is usually the one that the user chooses themselves and doesn't have to write down.
    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.

    Quote Originally Posted by Stevie D View Post
    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.
    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.

    Quote Originally Posted by rk007 View Post
    As you are designing your custom registration, here my suggestion:-

    • always use Ajax functionality
    • in case of error, only ask the user to correct error field. (only if you have strong server side checks, then you can leave password field as it is)
    • Always use mixture of Client side + Server Side authorization checks



    thanks
    Agree with your points, but points 1 and 3 are not directly related to the question.

    Quote Originally Posted by dresden_phoenix View Post
    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 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.

    Quote Originally Posted by dresden_phoenix View Post
    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"?
    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.

    Quote Originally Posted by dresden_phoenix View Post
    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?
    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.

  6. #6
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,791
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    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.

  7. #7
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  8. #8
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,786
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by logic_earth View Post
    If you are properly storing passwords. IT DOES NOT MATTER WHAT A USER ENTERS.
    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.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  9. #9
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    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.
    Quote Originally Posted by djeyewater View Post
    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.
    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.
    "First make it work. Then make it better."

  10. #10
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,791
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    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.
    point taken ..

  11. #11
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by djeyewater View Post
    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
    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.
    "First make it work. Then make it better."

  12. #12
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    110
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    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.
    Good idea

    Quote Originally Posted by Jeff Mott View Post
    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.

    Quote Originally Posted by dresden_phoenix View Post
    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...
    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.

    Quote Originally Posted by dresden_phoenix View Post
    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.
    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).

  13. #13
    SitePoint Member
    Join Date
    Apr 2013
    Posts
    14
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  14. #14
    SitePoint Enthusiast
    Join Date
    Dec 2009
    Posts
    48
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    try to use some captcha too..so you are not bombarded with 100s of spam forms

    i will say use ajax functionality so user do not have to hit submit and see the error message

    when they put the password ajax automatically on the right of form field will say not good password or not accepted

    and than once its good password it shows a right mark in front of the field in this way you do not have to refresh the page to show the error message

    that was the old way of encoding in which user has to submit to see the error message

    have a requirement to atleast use one character
    1 number and 1 alpha numeric character
    Affordable and professional WordPress Developer

    and expert Joomla Developer Hire now for your next website


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •