storing passwords in sql server database using ef

2020-04-16 00:31发布

问题:

I have this class to represent my users:

public class User
{
    public int ID {get; set;}
    public string UserName {get; set;}
    [DataType(DataType.Password)]
    public string Password {get; set;}
}

A simplistic version of my register method looks like this:

[HttpPost]
Register(User newUser)
{
    ...
    _context.add(newUser);
    await _context.SaveChangesAsync();
    ...
}

So my question is: Should I alter the password type from a regular string before storing? If so, to what data type?

回答1:

YES YES YES

Never store passwords as plain text

While much of this is a security discussion rather than a programming one, you should only be storing a secure hash (PBKDF2, Argon, and Bcrypt are current standards) along with a unique salt used for that hash.

Storing it as you are is just asking someone to steal your database and get all your users passwords without any more effort than reading the Password column (which they probably reused a million other places).

Its still OK to store it as string though.

The DataType.Password is just an annotation for consumers of your class to read. (per https://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.datatype(v=vs.110).aspx). It does not enhance security from a storage/database perspective.



回答2:

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.