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.

This question already has an answer here:

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?

share|improve this question
add comment

marked as duplicate by rk., Charles Wesley, 3nafish, André, Matt Obee May 23 '13 at 15:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

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.
share|improve this answer
    
This is absolutely correct. If stackexchange allowed some form of cross-posting, I would immediately re-post this to security.stackexchange.com –  scuzzy-delta May 23 '13 at 2:17
    
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. –  Henrik Ekblom May 23 '13 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 May 23 '13 at 7:55
    
-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é May 23 '13 at 13:42
    
@André Could you please explain how security is not part of UX? –  JohnGB May 23 '13 at 14:02
show 4 more comments

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.

share|improve this answer
    
+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é May 23 '13 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 May 23 '13 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é May 23 '13 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 May 23 '13 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é May 23 '13 at 14:43
add comment

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