views:

315

answers:

6

The company I work for has taken on a support contract for a large order processing system. As part of the initial system audit I noticed that the passwords stored in the database were actually the hashcode of the password.

Essentially:

string pwd = "some pasword";
string securePwd = pwd.GetHashCode();

My question is, how secure or otherwise is this?

I'm not comfortable with it, but I don't know enough about how GetHashCode works. I would prefer to use something like an MD5 hash, but if I'm wasting my time then I won't bother.

+1  A: 

GetHashCode returns a 32 bit integer as the hash value. Considering the birthday paradox, it's not a really acceptable hash value due to the relatively high probability of collisions. You'd probably want to go for SHA1, MD5, SHA2 or something really designed to handle such a task.

Mehrdad Afshari
Aren't SHA1 and MD5 broken?
Mitch Wheat
Depends on how you define broken. There are known methods to compute a value that collides (at least I'm sure of this case in MD5), but that doesn't make them useless. Even a salted MD5 is sufficient for storing passwords in most cases. Their "broken" attribute affects digital signatures much more.
Mehrdad Afshari
Oh, that said, I do not, by any means, recommend using MD5 or SHA1. As Mitch said, go with SHA256 or higher hash algorithms. The whole point of my comment was with the "broken" thing. In encryption algorithms, broken = dead. But in hash algorithms there is a bit more gray area.
Mehrdad Afshari
Thanks, that's kind of what I was thinking. I try to get the system moved over to SHA256.
ilivewithian
Don't forget to add the salt. :)
Mehrdad Afshari
+6  A: 

You should use a salted, cryptographically strong hash, such as SHA256Managed.

Jeff Attwood has a few good posts on this topic:

Rainbow Hash Cracking

You're Probably Storing Passwords Incorrectly

Mitch Wheat
+2  A: 

It's not just insecure, but also subject to change:

http://netrsc.blogspot.com/2008/08/gethashcode-differs-on-systems.html

The value returned by GetHashValue for a given input has changed in the past.

There's no guarantee it will even be the same between different executions of the app.

stusmith
A: 

GetHashCode was definitely not designed to be used in this way as the implementation does not guarantee different hash returns for different objects. This means that potentially multiple passwords could produce the same hash. It also isn't guaranteed to return the same hash value on different versions of the .NET framework meaning that an upgrade could potentially produce a different hash for the same string, rendering your passwords unusable to you.

It is recommended that you use a salted hash or even MD5 at a push. You can easily switch it to something within the Security.Cryptography namespace.

jamiei
A: 

As others have said, GetHashCode isn't designed for what you're trying to do. There is a really excellent article on how to handle user passwords securely.

To summarise the article, you need to use either a relatively slow adaptive hashing scheme such as bcrypt, or alternatively the Stanford Secure Remote Password Protocol. I would suggest the former. And of course you should also use a salt.

RoadWarrior
A: 

I'd recommend using BCrypt instead. As others have already said using GetHashCode for passwords isn't a good idea.

Quibblesome