Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
2  
I would suspect for security reasons and that the password isn't in a form it can be reused. –  ChrisF Apr 23 '12 at 13:40
    
I think Chris is correct. The input characters are 99,99% of the time masked when specifying a password. And the Ajax(or whatever) technique that the form utilizes may not have access to saving input in those fields. But I don't know, which is why this isn't an answer. –  AndroidHustle Apr 23 '12 at 13:51
add comment

5 Answers

up vote 24 down vote accepted

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.

Passwords should only be lost in the rare situation that inline validation fails to match server-side validation, or if Javascript is disabled on the client, which you can't really design around.

share|improve this answer
    
@blesh I still wouldn't feel comfortable feeding back password data into the browser like that. Passwords are supposed to be one-way, encrypted or not. –  Ben Brocka Apr 23 '12 at 15:34
1  
If only more than 10% of web forms actually did this. sigh –  Andrew Shipe Apr 23 '12 at 16:13
2  
@blesh the share exists by default. For most people they use such a machine everyday at work. –  Joshua Drake Apr 23 '12 at 19:01
1  
@JoshuaDrake (and Andy) you're both right. I agree wholeheartedly that this is a possible security risk. Thank you for your correction. –  blesh Apr 23 '12 at 19:03
1  
@blesh, Joshua Drake: While blesh is correct that this is a usability problem that should be addressed, simply sending a plaintext password back to the client is not the right way to address that problem, regardless of likelihood of exposure. (A browser cache being potentially accessible via an administrative share is really irrelevant to the risk in this situation.) See my answer for more. –  josh3736 Apr 23 '12 at 20:10
show 5 more comments

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.

Edit:

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).

share|improve this answer
1  
I don't think the OP is referring to a login scenario. It sounds to me more like when a user signs up/creates an account and something in the submission form is incorrect, and why the password fields in that case usually are blanked when additional user input is intact. –  AndroidHustle Apr 23 '12 at 13:45
add comment

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 :-)

share|improve this answer
    
That's unlikely to be the reason that all the sites empty their password field, from other comments it can be derived that emptying pass causes security holes. +1 thanks –  UX-Geek Apr 24 '12 at 2:30
add comment

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!" />

share|improve this answer
1  
@blesh A developer can only suggest what a client does with a page it receives, the browser can ignore such things completely. –  Andy Apr 23 '12 at 17:18
1  
@blesh The browser has to have a local copy to display the page. If you do not actively set your browser to clear the temporary files on exit, and even then under some versions of IE, the html source remains on your system indefinitely. –  Joshua Drake Apr 23 '12 at 18:48
1  
@blesh You assume the user is not using a more public computer, and / or the browser has not been modified. Caching is only one scenario. Another possiblity is the browser crashes; the unencryted password may be available in a memory dump. Additionally, its pretty common now for those dumps to instantly be transmitted back to the browser developers. I'm sure there are other things that may popup as well. –  Andy Apr 23 '12 at 19:19
    
@Andy as I told Joshua Drake... You're both exactly right. He made a much more compelling argument that other users with proper permissions on the network could just pull the stored HTML from C$. –  blesh Apr 23 '12 at 19:26
add comment

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:

  • Use client-side validation.
  • If server-side validation fails, store the hashed password in a session variable and set the password field's value to 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).
share|improve this answer
    
If you send the password back to the user what happens from security point of view? –  UX-Geek Apr 24 '12 at 2:27
    
The biggest risk is that the user's password will end up on persistent storage in plain text. (Usually, a browser cache.) Really though, the most important thing is that sending the password back is a technically unnecessary risk: not sending the password back does not break the system, it only inconveniences the user. –  josh3736 Apr 24 '12 at 3:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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