4

I'm using ASP.NET membership for a site that will serve primarily sophisticated users. I understand the difference between hashed and encrypted passwords, and I'm trying to decide between the two.

After my last client complained bitterly about hashed passwords being a total PITA, I've started to favor encrypted passwords. But someone suggested this just isn't secure enough.

So my question is: What, exactly are the risks of encrypting passwords? Any person with the ability to steal passwords by decrypting them from the database would surely have the ability to reset them if they were hashed, no? I'm having trouble seeing where someone could cause trouble with encrypted passwords but couldn't with hashed ones. Making it convenient for users is also important.

Jonathan Wood
  • 65,341
  • 71
  • 269
  • 466
  • Can you clarify "ability to reset them if they were hashed"? – Michael Shimmins Feb 09 '11 at 06:14
  • 1
    "Reset Password" is a common website function. Where the ability to email your existing password does not exist, it entails creating a new password and reseting your account to use that password. This is a common requirement where passwords are hashed. – Jonathan Wood Feb 09 '11 at 06:19
  • The password should not be reset in the database until the user has clicked the link. Resetting the password immediately is a pain for the user if someone other than them has triggered that function. – Michael Shimmins Feb 09 '11 at 06:21
  • Sorry to be clearer - the initial action is clicking hte link on the website. The second action is going to a specified URL from the email to do the actual reset. What I meant was the password shouldn't be changed until the user goes to the URL from the instruction email. – Michael Shimmins Feb 09 '11 at 06:23
  • @Michael: I think you're missing the point. We're comparing this to someone who can not only access my encrypted passwords but has the ability to decrypt them. Such a person could likely reset hashed passwords without going through URLs on my site. – Jonathan Wood Feb 09 '11 at 06:27
  • Both reseting a hash as you put it, and decrypting a password are very unlikely. But compare the cost of both in the event that it does happen. Decrypt password - The thief now has the users plain text password, probably the same one they use on every website. Screw up hash - The user cant log into your website and must do a password reset; The theif only denied service to your site – w.donahue Feb 09 '11 at 06:31
  • @metalideath: Well, you forgot that the "thief" could also wreak havoc on my site with the account they can now access. But, yes, I think we've established that the issue is that users tend to use the same passwords on multiple sites, which is worse than compromising just one site. – Jonathan Wood Feb 09 '11 at 06:34
  • I didn't forget that; but it is not relevant to the question posed. – w.donahue Feb 09 '11 at 06:48
  • Ah do you mean just changing them directly in the database because it has been compromised? IMO this is still better than that same person having the actual password, rather than having a one-way hash of a password. – Michael Shimmins Feb 09 '11 at 08:02

4 Answers4

15

The risk with decryptable passwords is that people use the one password for various logins and accounts, not just for the application you are dealing with.

  • With an encrypted password, a stolen/decrypted password could be tried out on users' other accounts (e.g. a stolen banking password could lead to access to their email).
  • With a hashed password, there is no recovery. Theft of password hashes should never easily yield usable passwords

Treat passwords as the property of the account owner. It's not yours to view, decrypt, or do other things with. If a user forgets their password, offer reset, and not retrieval.

Stoive
  • 11,232
  • 4
  • 24
  • 32
  • Also with a symmetrically-encrypted password the key has to go somewhere. Anyone who find the key can do a lot of damage. – seand Feb 09 '11 at 06:16
  • If they trick the admin into running an exploit then the will have their permission and can just decrypt the database in your system as you. Its really best to never have the raw password, just hash it as soon as you get it and delete the original. It is safer then running the risk of a huge PR mess because your login database was stolen. From a user point of view the only difference is that you will offer password resets as opposed to emailing them their original password. – w.donahue Feb 09 '11 at 06:25
6

The point is that Encrypted passwords can be decrypted...so it is possible that with having access to the keys etc all the passwords could be known.

Hashed (with salt) passwords are a 1 one function so there is effectively no possible way of determining what the password was which means the user supplying the password has less to worry about. Sure someone could change the hash in where ever it is stored (e.g. database) so that user could no longer log on, but the password they had provided originally still wouldn't be known.

Edit
As you've tagged the question ASP.Net, I'd recommend using BCrypt.Net library to generate your hashes

davidsleeps
  • 9,393
  • 11
  • 59
  • 73
  • Since a hash can not be undone even if a theif were to steal all your hashed passwords it would be of no use to them since you cannot recover the original passwords from the hashes. Just make sure as David said to salt the passwords so they are not susceptible to rainbow attacks. It is generally a poor practice to ever keep the original password around as they can be stolen and you don't need them in the first place. – w.donahue Feb 09 '11 at 06:16
  • @metalideath: Well, original passwords serve as a convenience to users who've forgot them. And a sophisticated user with access to the database could, in fact, potentially log into accounts on my site. However, as davidsleeps points out, it would not provide them with the passwords that users may be using on other sites. – Jonathan Wood Feb 09 '11 at 06:24
  • What's wrong with the way ASP.NET membership hashes passwords? – Jonathan Wood Feb 09 '11 at 06:29
  • Probably nothing at all really, and the built in one is quite convenient. But BCrypt easily gives you arguably the best hashing library available for asp.net (for free)...(it's likely overkill provided you are hashing and salting your passwords correctly using another option)...but i'd still recommend it...it does provide an additional level of security by requiring more processing power to generate a hash such that if an attacker has access, it would take far more computing power to undo anything (Again, likely overkill for most situations)...but again, i'd recommend it! – davidsleeps Feb 09 '11 at 06:32
1

The risk is, that encrypted passwords can be decrypted to get the plain text password.

Hashes normally can't be reversed.

Reversing an MD5 Hash

A quite common occurance is people using the same username and password on all their internet sites.

All it takes is one site password to be decrypted, and all the users sites are at risk.

While with a hash, the cracker never gets the plain text password.

Community
  • 1
  • 1
djeeg
  • 6,685
  • 3
  • 25
  • 28
  • I addressed that in my question. Who could have the ability to decrypt data in my database but not have the ability to reset hashed passwords? – Jonathan Wood Feb 09 '11 at 06:14
  • @Jonathan by 'resetting' I'm assuming someone with access to the database can Joe's password to "foobar"? That would certainly be possible. However the hacker couldn't find Joe *original* password that Joe perhaps uses for other accounts as well. – seand Feb 09 '11 at 06:24
  • [Gawker](http://www.lightbluetouchpaper.org/2010/12/15/the-gawker-hack-how-a-million-passwords-were-lost/) was using hashed/salted passwords and those were decrypted. Not all hash algorithms are created equal. – Greg Feb 09 '11 at 13:50
1

As other users have said, encrypted passwords can be decrypted and are not a good idea.

If you use a standard hash technique the user who has access to your database could put in the standard md5 for "password" for example. You can solve this issue with a salted hash which takes the input string and a salt string value to create a unique hash that can not easily be replicated. Store it somewhere safe and use sha1($salt . $input). You now have a salted hash.

Thomas Hart
  • 40
  • 6