Scott Rippey Scott Rippey - 2 months ago 18
C# Question

Should Password fields retain their values if a form does not pass validation?

I have a typical sign-up form with two password fields.

<%= Html.TextBox("Email", null) %>

<%= Html.Password("password", null) %>
<%= Html.Password("confirmPassword", null) %>

<input type='submit' />

If the form fails validation and is redisplayed, the text field retains its value but the password fields are always blank.

Why shouldn't the password fields retain their values? And more importantly, is there any reason I shouldn't override this behavior?

I feel like this behavior decreases usability, and would prefer password fields to behave the same way as textbox fields -- keeping the entered value when validation errors exist.

I'm using ASP.NET MVC, but this question pertains more to usability and security. I understand that what I'm seeing is expected behavior, and taking a look at the
method shows me that it explicitly ignores the value in


The answers submitted by @NickHeidke and @Chris Lively were both great and led me to a few conclusions that I would like to share.

First of all, regarding usability: the ONLY place where it might be appropriate for a password field to retain its value is on a "sign-up" form, when the form does not pass validation, and the validation issue is NOT related to the password or confirm password. It is definitely not appropriate for a "log-in" form, "change password" form, or probably any other place. Therefore, the fact that Html.Password ignores the ModelState makes perfect sense.

Second, regarding security: unless carefully implemented, a "sign-up" form will be saved in your browser's navigation history. Pressing "Back" will resend your password, which would probably fail validation, and return the form with your password filled out. The fact that the password is filled out is NOT a security breach though, because its the same password that the browser already saved and sent. You can "View Source" to see the password, but you could view the page request to see the password too (for example, using FireBug).

Granted, it is easier and more obvious to "View Source" when you see a password filled out, but I'd say the better solution is implementing the "sign-up" form in a way that isn't saved to browser history; for example, the PRG Pattern with a Validation workaround, but that is a whole different topic!

My conclusion is this: password fields should almost always be clear when shown. If you want to increase usability and don't want to make users retype their passwords, try to use client-side validation first! And finally, if you really know what you're doing, and really want to increase usability, it's ok to persist the values on a sign-up form. But it probably isn't the best idea.