I've seen many registration forms where if fields don't pass validation, the password fields are blanked as well.
Why is this the case? I understand why you'd blank the password in a login form, but I'm only referring to registration forms.
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.Sign up to join this community
If the form was rejected by Server-Side validation, the password should be blanked out since it shouldn't be sent back to the client.
This problem is easily solved with inline validation though, you simply shouldn't be able to submit a form until it won't be rejected, and then no form data will be lost.
There's a very good technical reason why this is the case. Sending back the form with the password could cache a page with the password in clear text in the page.
<input type="password" value="YouCanSeeMe!" />
As others have mentioned, this happens when a form fails server-side validation. A securely designed system will not send the password back (since the password will be part of the potentially cached HTML). There are two problems here: one is a usability problem, the other is a technical problem.
The technical problem is that sending the password back is a massive security hole. You, the site's developer, do not have the final say in how the HTML is cached – you can only make suggestions. Between buggy browsers and bad proxies (corporate environments frequently run a MITM SSL proxy by adding the proxy as a root CA to client machines), there's simply too much risk in assuming that the password won't end up somewhere on disk in plain text. And remember, it's immaterial whether or not the cached file is easily accessible (say, through
C$) – a secure system designs for defense in depth; the mere existence of a plaintext password is a design failure.
The usability problem is that the system has now created a second, hidden error. After failing server-side validation, the form page is usually sent back to the client, with each non-sensitive field's
value set to the (sanitized) value that was submitted, plus error message(s) by the field(s) that caused the validation problems.
Of course, with the password field now blank, correcting the errors from the first validation failure and clicking submit will result in a second validation failure, empty password, frustrating your user. There are a few ways to address this usability problem:
valueto something like
********(literally, 8 asterisks). When the form is resubmitted with password
********, use the stored password, otherwise use whatever was submitted (in the unlikely event the user decided to change their password before resubmitting).
One immediate reason I can think of...
If it takes a while to get a response (e.g. due to communication problem) the users may not be around and someone else may use the previously entered password to login. The user may have not log out, since he/she assumed the login failed.
In both sign-up and log-in, after a failure a new form is received. If the browser did not store the password, the only was to enter it back into the form is by sending it back to the browser, an action which may reduce security.
During sign up process, the reset of the password is annoying, I believe it might be meant to prevent users from forgetting their password.
E.g. if the choose user1 as their username and pass1 as their password and counted on the browser's storage of their password, however, user1 was taken so they changed it to user2, the browser may not store the password, since it was submitted with a different username. Also the user may get confused because he/she expected the password to be related to the username (e.g. pass2).
I think Ben is right. But there is more: if the user is forced to write the password again, she will be sure that the password is the one just entered.
If the password is sent back by the server it will appear masked to the user. She will either be unsure what's the current value or forgot what she typed before. Or probably both :-)