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

i have typical sign-up form 2 password fields.

<form>     <%= html.textbox("email", null) %>      <%= html.password("password", null) %>     <%= html.password("confirmpassword", null) %>      <input type='submit' /> </form> 

if form fails validation , redisplayed, text field retains value password fields blank.

why shouldn't password fields retain values? , more importantly, there reason shouldn't override behavior?

i feel behavior decreases usability, , prefer password fields behave same way textbox fields -- keeping entered value when validation errors exist.

i'm using asp.net mvc, question pertains more usability , security. understand i'm seeing expected behavior, , taking @ password(...) method shows me explicitly ignores value in modelstate.

you can send value on regular input type=password field.

however, if using .net input control, clear contents of value prior sending html client.

the reason simple: wanted limit number of times in password sent , forth between server , browser. helps limit exposure systems.(link)

now, obviously, if using ssl isn't of consideration. unforunately vast majority of sites out there still don't use ssl , happily send data , forth in clear. more times field travels between client , server, more opportunities has of grabbing ala firesheep.

bear in mind, isn't listening in on whole conversation won't first post. however, consider simple option limit (not eliminate) attack surface.

the next reason every time sites show password field user after submit, it's because validation didn't pass. mean username and/or password incorrect. considering password fields display asterisks or dots user, there's no real reason give them.

given never want tell user of credentials failed (ie: not want "password invalid" or "username invalid") , common users have no way of figuring out whether fat fingered entry, it's better imho clear both.

---

all of aside, have choice here. standard blank it. considering way vast majority of sites work, want go against grain? personally, find better off sticking ui standards when disagree them.

users have hard enough time different options available.