13

This question with a similar name refers to registration, but in my case, I would like to address submission.

My use cases are:

  • A login form consisting of an email address.
  • A change password form where the user enters his new password twice to change his password.

Assumptions:

  • The user has javascript enabled, so we can use AJAX and perform inline form validation. There is then no security risk of sending the password back to the users to re-render the form.

The password field can fail for several reasons:

  1. In the login form, the password is blank or the password/email combination is incorrect.

  2. In the change password form, the password does not meet password requirements (minimum length, etc).

  3. In the change password form, the repeated password does not match the password.

  4. In the change password form, a blank password field exists.

Currently, I have the following behavior:

  • In the change password field, once the password is successfully changed, the passwords fields are blanked out as there is no point keeping them around, and we prepare "clean" fields in case the user wants to change the password again.

Should I also blank the fields for the other failure modes? For example, when using change password fields and setting a password like "123456" and the form returns "You need to have at least a letter in your password", I could just go the beginning of both builds and add "a", resulting in "a123456". This probably defeats the purpose of secure passwords, but it is a lot faster than typing "a123456".

Are there any established guidelines for this?

Improve this question
3
  • 1
    This is where usability and security have different requirements. For usability you probably don't want to clear the field(s). For security you do absolutely want to clear the fields as not doing so adds another way in which passwords will travel around in plain text (as part of the request's form variables).
    – Marjan Venema
    Commented Jun 27, 2012 at 7:07
  • @phpdev, You've listed 4 situations. For which one of them do you want guidelines? Or all of them?
    – dnbrv
    Commented Jun 27, 2012 at 15:55
  • @dnbrv, yes I am looking for guidelines for all situations.
    – F21
    Commented Jun 27, 2012 at 23:42

3 Answers 3

Reset to default
3

I think the main thing to worry about here is the familiarity of forms blanking the password field on a form validation error.

Since most users aren't savvy enough to distinguish between an AJAX request and a standard one, they may think their password field not being blanked after clicking "save" and receiving an error is unusual/insecure behaviour.

The best way I can see to accommodate the best of both worlds here is to do inline JS validation as opposed to only validating the form when the user clicks "Save". Seeing the password field immediately raise an error before I've clicked the submit button makes seeing my password still in the field a less worrisome/unusual scenario (of course it's not blank, I haven't sent it yet!). It would seem extremely unusual for an inline form validation error on a different field clear my password, so I think that option is much more unequivocal. If somehow the user scrolls down and clicks "Save" having ignored inline validation, I think a standard POST (including clearing of any passwords) is reasonably expected.

Improve this answer
2

During creation of a password: (new user or password change)

  • Validate (complexity and matching if you are using two fields) on the user's machine (e.g. Javascript) on change, so that the user gets immediate feedback. Only enabling sending if user-side validation has passed. Do not clear password(s).

  • Run server-side validations (in case Javascript was hacked, is out of date or is disabled) prior to accepting new password. If server-side validation fails, user receives a new page, see login process for details.

During login:

  • Password is encrypted and sent to server.

  • If login fails (same for new password's server-side validation failure) then the user is sent a new login page (can be the same page), you can send the user back all the plain text fields (I am assuming both sign-in and log-in are encrypted), but not the password. - Clear the password fields.

Improve this answer
1

For usability, your form shouldn't even allow posting until it's valid. With that:

  1. In the login form, the password is blank or the password/email combination is incorrect. When the form is posting(before making he call to the action), it first should be validated and appropriate messages should display next to the offending field. No resetting of fields

  2. In the change password form, the password does not meet password requirements (mininum length, etc). You should provide instant feedback to the user on their password strength. No resetting of fields unless your requirements cannot be mirrored in a client side javascript

  3. In the change password form, the repeated password does not match the password.You should provide instant feedback to the user that the passwords do not match. No resetting of fields
  4. In the change password form, a blank password field exists. Again, don't allow posting until the form is valid

It's very inconvenient when filling out a form and it resets all the values after it tries to post. If it's valuable information, the user will most likely get annoyed and just leave the site...

If the authentication fails, then yes; blank out the password since it's apparently not valid. Although the username could be incorrect, it's your call if you want to validate that the user account exists and not blank it out on refresh.

Finally, whatever you do, be consistent!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.