Let's suppose you have a model like this:
public class User {
public string Username { get; set; }
[DataType(DataType.Password)]
public string Password { get; set; }
}
To test this out, you write an action:
public ActionResult Index()
{
return View(new User { Username = "brad", Password = "secret" });
}
And an editor in the view:
<% using (Html.BeginForm()) { %>
<%: Html.EditorForModel() %>
<input type="submit" />
<% } %>
You pop up the browser and notice that the password field looks like it's already filled out. Uh oh! View Source...
<input class="text-box single-line" id="Username" name="Username" type="text" value="brad" />
<input class="text-box single-line password" id="Password" name="Password" type="password" value="secret" />
Don't panic. Believe it or not, this actually isn't a bug. I sorta tricked you by using a model that you shouldn't have in the real world. :)
To start with, you're not storing your passwords in clear text are you? You shouldn't be, because cleartext passwords are just begging to be stolen and exploited. Sites should be using an irreversible one-way hash (like SHA-1) to store passwords for their users. In practice, your model won't have an unencrypted password hanging out in it where it can be exposed like this.
Why did we allow the value of the property out into the editor?
Sometimes you want to offer an editor form which, among other things, allows the user to pick a new password. Additionally, an empty password is valid for the new password value, so you can't use empty to indicate that the password wasn't set. In this case, it's common to pre-fill the password field with a garbage "sentinel" value (like a GUID) so you can easily tell whether the user typed something, including clearing the field. Because we let you set a value in your model, it allows you to set one of these sentinel values for your form. If we didn't allow this, you'd have to ignore/avoid our password HTML helper and write your own.
