T-SQL AES Encryption vs Hashing/Salting for loggin

问题:

I have a project and apparently the designers of the software didn't put security into consideration.

The passwords are stored in plain text and transmitted through plain text. So I am left with the task to fix this.

I am a bit rusty on security, so my question is: for online user password authentication is it better to use hashing/salting techniques or is it better to use AES encryption? Could I have the pros and cons.

Would it be better to somehow use the ASP.NET membership provider? Would this be easy to do? I have used that before, but the software calls on it's own tables, so I'm not sure if that's more trouble there.

If this has been answered could someone direct me there, because I didn't find a comparison.

回答1:

You should NEVER store passwords using symmetric encryption.

Random salt for every user, hash their password, store both the salt and hash in the database. Then on login requests you get the user by email/username/id etc, then use the salt tied to that user and hash their supplied password and then match it against the stored hash. If matches, login, else bad password.

If you use the built in ASP.NET membership provider it should do this for you.

回答2:

I suggest you to multipe hash a salted password. More than 10 times or something. So why? Because for you hashing a salted password wont take recognizably longer. But for a evil guy trying different combinations to brutefocre a password, it takes 10 times more time each try. And he can't be sure if you did it 10 or 1000 times.

I use this personally as a cheap security increase.

See here: Stackoverflow Salting Your Password: Best Practices?

or there Secure hash and salt for PHP passwords

Good luck :)

Harry

回答3:

Using membership shouldn't add that much difficulty over doing the whole thing yourself, and is likely to be more secure. Just use the user's existing username as a membership username, force users to reset their passwords (fixing the security system will require you to scrap old passwords regardless), and change all your hooks that check who the user is to use Membership.GetUser() or similar.

There will be a bit of nastiness if you support the ability to change usernames. Changing a username can introduce a security hole if not done carefully as membership relies on usernames and userids in ways that could cause holes (though this requires a non-malicious user to change their own name, so it's not a huge hole).

回答4:

It depends on whether or not you want to be able to recover a user password for some operation. If you go with hashing/salting, that means every time a user forgets their password, you're going to have to have the application generate a new, secure password. If you go with symmetric encryption, then you at least give the user a chance to recover their existing password and change it later at their convenience.

I can't answer whether or not there's increased security either way. Someone with more knowledge than I will have to answer whether or not more or less feasible to crack a hashing/salting algorithm as opposed to a symmetric encryption algorithm. On the surface, hashing/salting seems to be more secure because the attacker has to figure out the algorithm before he can begin cracking passwords. But the same could be said if you decided to use a different symmetrical encryption algorithm. You could also combine symmetric key algorithms in case you think AES just isn't secure enough on its own.