I am wondering if I should re-populate the (masked) password field in a form when other fields don't validate. I have seen both on the web where the form would either:
- re-populate the masked password field
- empty the password field, so the user needs to put it in again (even though it was valid)
What is your best practice? Does re-populating the password field indicate a security hole? Usability-wise I would prefer to re-populate the field and not have the user re-enter it.
One option if you want to do this, is not actually send the password plain-text, but a random token. Since it's a password field, the user won't be able to tell (except for the length). Then, store the hashed password and token in the session. When the user submits the form, if the password field is the same as the stored token, use the stored password hash. Otherwise use the submitted password. This solves the cache issues (Since the random token will have no meaning in requests by other sessions). That way you never need to store or transmit the raw password after the initial form submission...
Re-populating it is much more comfortable for the user.
However, if the form is submitted in the classic way (i.e. with a full page reload, not via AJAX) you risk the html containing the password being cached. With proper headers you can lower/remove that risk though. Using HTTPs is also really important in that case. It completely prevents HTTP proxies from caching it and the local browser cache usually honors nocache headers (and even if not, it's not a big issue if caching happens on the local machine).
All in all, I usually prefer not having to enter the password again just because another field (e.g. a crappy captcha) was incorrrect.. but in a high-security environment you don't want to re-populate the password field unless you are using AJAX and don't have to actually send back the entered password.
Absolutely, clear your password fields and don't re-populate them. Don't compromise security for usability.
It's a security issue on shared computers since the password will be visible in cleartext when viewing the html source. Not only in an active browser window, but also in any diskbased cache.
I would personally go with OpenID instead of requiring the user to invent yet another username+password pair to remember (which also affect usability to the better).
If you need to send the actual password (or anything derived from it) from the server to the client in order to re-populate it, it's a major security hole.
If all you do is save the password locally on the client until the form submit validates (by not reloading the page, eg via javascript), then it seems fine to me.
No, it will not (if done right).
- An attacker in the network (i.e. between browser and server) will have seen the password the client sent. If you're using HTTPS, you must use it for the form as well as its target.
- A browser-side attacker could have registered a listener on the password field or intercepted the request.
- A third-party attacker could try to fetch the filled-out page from a proxy the user's using. Set appropriate
Cache-Control
headers to prevent the page from being cached.