In most Create Account forms that I've used, when you enter in something wrong (username not long enough, passwords don't match, invalid email, etc.), it'll keep all the fields but erase the password field(s). Is there any real reason behind this? I can understand it if the passwords are causing the invalidation, but if the email address is the problem, why clear the passwords?


2 Answers 2


The simple rule is that a password should never be stored in a retrievable format.

To be able to leave the password fields as they are, the password would have to be stored somewhere locally in a readable format - somewhere like the browser cache or a cookie. That is poor security as someone could later retrieve the password from one of these sources.

Jeff Atwood wrote an excellent blog post many years ago titled: You're Probably Storing Passwords Incorrectly. It is mostly dealing with how you store passwords on databases, but the same rules apply for any storage system (even temporary storage). The key points that he makes are:

  1. Do not invent your own "clever" password storage scheme.
  2. Never store passwords as plaintext.
  3. Add a long, unique random salt to each password you store.
  4. Use a cryptographically secure hash.
  • This is absolutely correct. If stackexchange allowed some form of cross-posting, I would immediately re-post this to security.stackexchange.com Commented May 23, 2013 at 2:17
  • 1
    If the "ok" buttons uses AJAX or some client side validation (the latter might be dangerous though since it can be tampered with) and something is reported to be wrong, then the password could be left where it is - since the place where the password is "stored" in is the very textbox(es) that were used to start from. The password fields won't simply be refreshed - hence they can be left where they are. Commented May 23, 2013 at 7:32
  • @HenrikEkblom There is the additional use case where a person submits a form, and does something else, thinking that it has validated. If the password remains on the screen there, you are exposing them to unnecessary security risks.
    – JohnGB
    Commented May 23, 2013 at 7:55
  • 1
    -1: This is a purely technical answer, and not reasoned from the UX perspective. From the UX perspective, @Brendon gives a convincing example of alternative designs that show it is not needed to make the user jump through the hoop of re-entering a password (and to add insult to injury, do that twice).
    – André
    Commented May 23, 2013 at 13:42
  • @André Could you please explain how security is not part of UX?
    – JohnGB
    Commented May 23, 2013 at 14:02

As JohnGB said, this is really a security precaution. However, there is an alternative way which is usable and secure at the same time. Rather than sending back the password mypassword, you can:

  • Send back a hidden field indicating the password is saved on the server (hashed, of course).
  • In the password field, assign the value ********.
  • The user will see ******** in the password field. If the user attempts to change the password, clear the field and prompt for a new password (change the hidden field indicator).

This will obviously require client-side scripting. Alternatively, you can replace the password field with Password: ******** and add new fields for New Password and Confirm New Password. Then you only update the server-stored password if the user enters a new password.

Other than the password length being different, the user will only see the obfuscated form and will assume that their actual password is in the field. To this extent, their behaviour does not change.

One issue with this approach is that users cannot see their passwords so will be unable to use the show password option, if you provide it. One possibility is disabling the field with a 'Change password' button to allow the user to enter a new password.

  • +1. I really appreciate the effort you put into this. I have never seen any of this implemented, but it sounds like a massive improvement to just deleting the password "for security reasons". Security does not demand me typing in the same information multiple times, it just needs a bit more thought and work as you clearly show. In fact, I'd argue your approach to be more secure than requiring re-typing the password.
    – André
    Commented May 23, 2013 at 9:41
  • 1
    Interesting ideas. I'm interested to know what key you would use in the database if there is no username to associate the password with (yet). Also, can you point to any examples that have implemented this?
    – JohnGB
    Commented May 23, 2013 at 14:05
  • 1
    @JohnGB: I'd probably store it (already hashed and salted) in a temporary, time limited store keyed against a session token or something like that. But again: that's a technical consideration, not a UX one.
    – André
    Commented May 23, 2013 at 14:23
  • @André Technical feasibility is a UX consideration. I've never seen this implemented, and I can think of many situations where this may be problematic. So I'd still like to see an example of it implemented to test whether it fails or not under certain circumstances.
    – JohnGB
    Commented May 23, 2013 at 14:34
  • @JohnGB: Well, I guess we disagree there. Not everything is UX, otherwise the term becomes meaningless. It is up for the engineers to determine if a proposed solution is technically feasible, not for UX designers. And yes, of course it needs testing and a proper review from a security specialist: yet another field that is relevant for choosing the end solution. UX isn't everything, but for me from a UX perspective Brendon is thinking in the right direction.
    – André
    Commented May 23, 2013 at 14:43

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