tags:

views:

768

answers:

6

I'm working on an application and I need to store the users password, so I'm thinking I'll store it in the current-user class of the registry, but I also want to hash it for the obvious reason, and I've seen news items that state that SHA1 has been cracked, is there a better (uncracked) hashing algorithm available in the "standard" system or .net?

+2  A: 

As you say in your comment, SHA1 is a hash algorithm, not encryption. It is a one-way function that, even if it is broken, does not allow the password to be retrieved.

If you want stronger hash functions that are already in .NET, look at the SHA2 family - SHA256, SHA384, SHA512. (SHA224 also exists, but isn't implemented in the System.Security.Cryptography namespace.)

The collision attacks on SHA1 are not practically exploitable yet, but you are right to be looking ahead. NIST is currently running a selection process for SHA3 in the light of these attacks, but this is a few years from completion and commercial acceptance. SHA2 on the other hand is an existing family of algorithms that are standardised by NIST and are not subject to the attacks that have been successful against MD5 and SHA1.

David M
Should not that even with a better hash, a salt should still be used to avoid rainbow attacks.
Richard
Yes, agreed, I'm not denying that. But the question was about a better hash algorithm, not best practice for using it.
David M
A: 

What you need to do is salt your passwords. Here is some actual sample code in C# that uses SHA1 and salting.

The problem with SHA1 "being cracked" is all basic possible combinations have been pre-calculated, however salting makes your password nonbasic (it is still vulnerable to a brute force if it is weak or easily guessable but it kills rainbow tables)

Scott Chamberlain
Yes, salt them definitely. But that doesn't get round the fact that SHA1, in cryptographic terms at least, is "broken".
David M
+7  A: 

SHA1 is not encryption, it's a cryptographic hash function. And yes it has been broken, which means it's possible to generate collisions faster than a brute force method. The SHA2 family has not been broken.

But I would advise to use a custom seed per entry so that a rainbow table could not be used for trying out passwords. If you're using the SQL Membership provider the password format "Hashed" already uses a different seed for each user.

More information about seeding your hash can be found in the article What You Need To Know About Secure Password Schemes by Thomas Ptacek.

Davy Landman
A: 

Yes you can use SHA512, just remember how long the actual hash is. You can always add extra security by salting the hash results as well.

SHA512("The quick brown fox jumps over the lazy dog") = 
   07e547d9 586f6a73 f73fbac0 435ed769 51218fb7 d0c8d788 a309d785 436bbb64
   2e93a252 a954f239 12547d1e 8a3b5ed6 e1bfd709 7821233f a0538f3d b854fee6

If you want to look into other Hashing algorythms, here's a short list.

Ólafur Waage
A: 

5 days too late but you could try the highly secure encryption function

uint64_t highly_secure_encrypt(char* password) {
  sleep(1);
  return 0;
}

No way you're getting the passwords back from that.

Now, onto serious matters. If you don't already know the answer to your question you shouldn't be designing security systems.

If you're storing the password in the current-user section of the registry then the only people who can access it (under normal circumstances) are the user and the administrator. I'd trust (somewhat) the current-user section of the registry and use the standard password hashing mechanisms that the OS provides.

Here describes hashes and password storage at a good beginner detail, and here goes on to tell you why you should not try and do it yourself usually.

Choosing a good hash function is less than 1% of the battle. If an attacker can run you hash function millions of times a second then (s)he can test millions of combinations a second. What you need is a slow, tunable secure hash. That's not something that is easy to come by and SHA*, MD5, etc are designed to be bloody fast since they're meant to be used over files and chunks of files usually, where speed is king.

I'd recommend reading up more, since the answers are out there and very easy to find.

Adam Hawes
Your assumption of access assumes that the system has not been compromised which is a very real concern specificly when the common users are under educated and "administer" their own systems.
Unkwntech
+1  A: 

Hash algorithms have been showing some signs of weakness as of late, which is why NIST has offered up a hashing contest much like they had an encryption contest which crowned Rijndael as the new AES.

I personally like what MD6 has to offer, as it is being spearheaded by Ron Rivest, who has been in the cryptography space for over three decades. MD6 has been withdrawn, so I suggest some of the stronger candidates in Round 2 in my humble opinion are Keccak, Blue Midnight Wish, and Fugue.

From there, definitely use good practices such as salting.

Jesse C. Slicer
For the sake of completeness, a [recent development](http://groups.csail.mit.edu/cis/md6/OFFICIAL_COMMENT_MD6_2009-07-01.txt) in the SHA3 contest illustrates the imprudence of using un-reviewed cryptographic algorithms, even those designed by masters like Rivest: "..at this point MD6 doesn't meet our own standards for what we believe should be required of a SHA-3 candidate.." (Of course, we're all entitled to 'like what MD6 has to offer' - just be careful about going too far past that point.)
ladenedge
If by "recent development" you mean 13 months ago :)
Jesse C. Slicer
The current crop (Round 2) can be found here: http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/submissions_rnd2.html
Jesse C. Slicer