Solutions2
You should never store a password in the database if you can avoid it. Best practice is to store a salted, irreversible hash of the password.
Typically this would be a SHA2 or PBKDF2, or whatever of the password salted with something that cannot change about the user-- e.g. the ID of the record.
You would store the has typically as a varbinary(32) or whatever length your hash algorithm uses.
This approach means that you cannot determine a user's password, since it is irreversible. To test a password of someone attempting to login, perform the same hash with the same salt, and test if the result is the same as what you have in your database. This way, a hacker who gets your database cannot figure out what each user's password is, but you can still test if a user knows their own password.
Talk1:
What does DataType.Password DataAnnotation do for the property then?
Talk2:
The problem with MD5/SHA1 is not necessarily collisions (though that is a problem), its that they are easily crackable with consumer hardware. PBKDF2, BCrypt, SCrypt, etc. are designed to be slow so brute-force attacks are much harder (often requiring specialized FPGAs)
Talk4:
I desperately added a bunch of tags to posts just to get to 50 rep so I could stick a comment on this post saying how bad of an idea it is to use MD5 etc for passwords, but BradleyDotNET beat me to it. I still want to reiterate that it's a terrible idea.