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' />
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.