5

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.

Jeremy McGee
  • 24,842
  • 10
  • 63
  • 95
pqsk
  • 2,124
  • 3
  • 23
  • 28

4 Answers4

8

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.

Chris Marisic
  • 32,487
  • 24
  • 164
  • 258
  • The answer I needed thanks. On the note of asp.net membership: The software did not use it (which explains the headache). I was just reviewing the tables and I think the best solution would be to just add a new column for the aspmembership userid. – pqsk Nov 14 '11 at 15:28
  • Note that adding a new column for aspmembership userid does not avoid the nastiness I mention in [my answer](http://stackoverflow.com/questions/8123382/t-sql-aes-encryption-vs-hashing-salting-for-logging-in-users-to-website/8123808#8123808), though it gives you choices about exactly what kind of ugliness changing usernames will introduce. – Brian Nov 14 '11 at 18:16
1

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

Community
  • 1
  • 1
Harry
  • 1,313
  • 3
  • 22
  • 37
1

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).

Brian
  • 25,523
  • 18
  • 82
  • 173
  • Could you elaborate on the security concerns with the membership provider if users can change their username? – Chris Marisic Nov 14 '11 at 18:59
  • @ChrisMarisic: The membership provider does not provide built-in supoort for changing username. Someone else who somehow knows you are changing your username can then change their own username to your old username. Then, when they try to access information, the system may incorrectly return your information. Basically, once you tie two pieces of identifying information together, you must ensure that they stay fully in sync, not merely within the database but also within any caches (and possibly must reset session data). AspNet will not do this for you. – Brian Nov 15 '11 at 01:16
  • @ChrisMarisic: Further, there are potentially 3 pieces of data to sync, since the OP must either use his own login control or must keep the users' username within his existing account system synced with their username within membership. – Brian Nov 15 '11 at 01:17
-2

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.

villecoder
  • 13,323
  • 2
  • 33
  • 52
  • 1
    Hashing/salting is more secure because you aren't storing the password. Someone who hacks into your server won't be able to run a magic function to pull out all the user passwords (and then use them on other servers)...though they will be able to crack "common" passwords (sure, there are multiple passwords sharing a hash with "Password1", but chances are the user is using "Password1"). – Brian Nov 14 '11 at 15:26
  • 2
    -1 for advocating access to the passwords. This is an extreme security violation, if you give me a couple hundred emails & passwords from a real world login system (maybe a couple thousand) I will find atleast 1 working paypal account with that information. Hashing is meant to protect the passwords being compromised both from a malicious user that hacks into your system AND from a malicious system admin who already has access. – Chris Marisic Nov 14 '11 at 15:48
  • @Brian You make a good case for using hashes in that regard. However, it does mean that the existing password could never be recovered. I know in some systems they further encrypt the information based on the salt used in the user password, making it further impossible to access the information about the user if the user forgot their password. But that's neither here nor there. I guess it really just depends on the application. – villecoder Nov 14 '11 at 16:43
  • @ChrisMarisic Where did I advocate (keyword) access to the password? All I said was that if you use hashes for passwords, you don't have the opportunity to recover the existing password. Where in my answer did I give the impression that the user should then share this password with an attacker? – villecoder Nov 14 '11 at 16:45
  • 3
    @villecoder: Why should they ever need to know their existing password after they've forgotten about it? If they forgot it, they can reset it without knowing their current password. Any other reason they want to know their current password is probably also reason they *DON'T* want a someone with access to your server to know that password. Chris's complaint relates to malicious users of your server (evil sysadmins or hackers) accessing the password by looking at the server database, not the user. – Brian Nov 14 '11 at 18:10
  • @Brian Arguing whether or not they need to know their existing password after they've forgotten it is beside the point. It's a business decision whether or not they want to give users the ability to recover a password as opposed to generating a new one. Even so, how can an attacker gain access to your password if you've encrypted it symmetrically when all they have to go on is the database when you're storing the encrypted password? – villecoder Nov 14 '11 at 19:52
  • 1
    @villecoder "how can an attacker gain access to your password if you've encrypted it symmetrically when all they have to go on is the database" A: Rainbow tables. And "It's a business decision whether or not they want to give users the ability to recover a password", honestly it's not. It's a security decision. Either your users' passwords are secure or they are not. This is also a choice a user should never be able to make, their only option should be secure – Chris Marisic Nov 23 '11 at 14:09