Do not use string hashes for security purposes

re: Do not use string hashes for security purposes

Jonas Grumby — Mon, 24 Oct 2005 18:47:42 GMT

Wow. It never even dawned on me that someone might do that. And this was someone who had read your series? Talk about understanding just enough to get it completely wrong.

re: Do not use string hashes for security purposes

Eric K. — Mon, 24 Oct 2005 19:03:58 GMT

Soo... what is the supposedly-painless alternative that we should be using instead?

Roll our own algorithm and hope it behaves according to standards?

Buy a third-part component?

Hope we don't need standard behavior and don't expect upgrades?

re: Do not use string hashes for security purposes

Brian Delahunty — Mon, 24 Oct 2005 19:49:35 GMT

>Soo... what is the supposedly-painless alternative that we should be using instead?
>Roll our own algorithm and hope it behaves according to standards?
>Buy a third-part component?
>Hope we don't need standard behavior and don't expect upgrades?

Plenty of standard hashing algos built into .NET... look in the System.Security.Cryptography namespace in 1.1 and you'll find the following (plus a few more):

System.Security.Cryptography.MACTripleDES
System.Security.Cryptography.HMACSHA1
System.Security.Cryptography.MD5CryptoServiceProvider
System.Security.Cryptography.SHA1Managed
System.Security.Cryptography.SHA256Managed
System.Security.Cryptography.SHA384Managed
System.Security.Cryptography.SHA512Managed

re: Do not use string hashes for security purposes

G. Dog — Mon, 24 Oct 2005 19:59:32 GMT

I think there is some confusion here and you should probably point out WHICH methods specifically you are talking about.

I think you are talking about calling GetHashCode() on a string, is that right? If so then I understand this post... But it appears as in the question by Eric K. that you may be referring to some OTHER hashing methods when you say "the .NET string hashing algorithm" (a very vague statement).

Please clarify...?

re: Do not use string hashes for security purposes

Jonas Grumby — Mon, 24 Oct 2005 20:29:18 GMT

G. Dog: Follow the last link in the article.

re: Do not use string hashes for security purposes

Eric Lippert — Mon, 24 Oct 2005 21:08:20 GMT

* no, this was clearly not someone who had read my articles -- this was from a customer who had developed their own customer-secret hashing system. The question just got to me at random from a PSS guy.

* The alternative you should be using instead is exactly what I said -- use SHA1 or MD5 or some other industry-standard algorithm designed for security purposes. Make your own educated judgment as to what algorithm suits your purposes based on the characteristics of your problem and the algorithm in question.

* Yes, I am talking about String.GetHashCode. I apologize for the unclear text; I've clarified it.

re: Do not use string hashes for security purposes

Gabe — Wed, 26 Oct 2005 23:50:25 GMT

Is there some way, then (possibly using Reflection) to get the old behavior?

I can easily imagine a situation where somebody has persisted a hash table (caching web pages with the filename being the URL's hash value in base64) and would want to keep the same behavior after upgrading to Whidbey.

re: Do not use string hashes for security purposes

Eric Lippert — Thu, 27 Oct 2005 00:49:02 GMT

Reflection isn't going to help you -- reflection just turns early-bound calls into late-bound calls, it doesn't change what the call does.

If you are in this unfortunate predicament, the best advice I can give you is to get the Rotor sources, look up the string hash function, and re-implement it in the managed language of your choice. Then start using your now-stable library function rather than String.GetHashCode.

re: Do not use string hashes for security purposes

Lance Fisher — Fri, 28 Oct 2005 02:07:22 GMT

One of my favorite function names:

System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile()

When Breaking Changes Actually Break Stuff

protected virtual void jaysonBlog { — Sun, 26 Feb 2006 08:22:26 GMT

It&rsquo;s funny how breaking changes actually&hellip;well, break stuff sometimes.&nbsp; I&rsquo;ve had...

re: Do not use string hashes for security purposes

Elbie — Tue, 14 Mar 2006 23:34:46 GMT

If I understand correctly, the weaknesses in MD5 and SHA-1 are with respect to collisions, not preimages, and as long as those hashing algorithms remain preimage resistant, then there's really no problems with continuing to use them.

re: Do not use string hashes for security purposes

Reinhard — Thu, 23 Oct 2008 02:18:04 GMT

Gabe: there is a way to get the old functionality:

http://aspalliance.com/1218_NET_String_Hashing_The_Hidden_Knot.all