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.
-
2I would suspect for security reasons and that the password isn't in a form it can be reused.– ChrisFCommented Apr 23, 2012 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.– AndroidHustleCommented Apr 23, 2012 at 13:51
Add a comment
|
5 Answers
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.
-
1If only more than 10% of web forms actually did this. sigh Commented Apr 23, 2012 at 16:13
-
1@Andy: That's completely controllable by the developer, and is a development error, not a design consideration.– bleshCommented Apr 23, 2012 at 17:00
-
1@JoshuaDrake, you're right. Still seems extremely unlikely this would be the attack of choice for a hacker with that sort of access to the machine in question. If they had the access to set up a share on that machine, why not just install a key logger? And who in their right mind would log into anything and/or register an account on a public machine in such a network?– bleshCommented Apr 23, 2012 at 18:58
-
2@blesh the share exists by default. For most people they use such a machine everyday at work. Commented Apr 23, 2012 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.– bleshCommented Apr 23, 2012 at 19:03
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!" />
-
1@blesh A developer can only suggest what a client does with a page it receives, the browser can ignore such things completely.– AndyCommented Apr 23, 2012 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. Commented Apr 23, 2012 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.– AndyCommented Apr 23, 2012 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$.– bleshCommented Apr 23, 2012 at 19:26
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
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).
-
If you send the password back to the user what happens from security point of view?– AlirezaCommented Apr 24, 2012 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.– josh3736Commented Apr 24, 2012 at 3:28
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).
-
1I 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. Commented Apr 23, 2012 at 13:45
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 :-)
-
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– AlirezaCommented Apr 24, 2012 at 2:30