views:

465

answers:

3

Three SHA512Managed related questions:

  1. Is SHA512Managed considered the best one-way hash available in .NET 3.5 for security?
  2. What Salt size should be used with SHA512Managed? The application is for strong passwords with at least 8 characters.
  3. Is 512 overkill compared to 256 for small strings?
+3  A: 

If you're looking for preventing brute force attacks take a loot at bcrypt or scrypt. They're designed to be algorithmically slow. So even if an attacker did get a hold of the password database, calculating everything would take forever.

http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-strong-password-hashing-for-dotnet-and-mono.ashx

http://www.tarsnap.com/scrypt.html

Min
Those look interesting, but I'm looking for a Hash Function that is part of the .NET Framework (version 3.5).
Josh
I think you need to rethink how the longer hash is making it more secure. The main reason to have a longer hash is to decrease the probability of collisions. So how exactly does a longer hash improve security? You're basically trying to do it by reducing the probability of a clash which doesn't seem like a great metric imo.For storing passwords pretty much all of this is overkill. Just salt the passwords.Keep in mind that bcrypt is designed for the password storing scenario.
Min
+3  A: 
  1. Sha512Managed does not depend on system calls, and has the largest hash size of the built-in hashes. If you're not optimizing for anything else, it would be considered the most secure.

  2. For password cracking purposes, a salt essentially increases the size of the password. Though 'bigger is better,' anything beyond the number of bits of the password itself is largely wasted. So, for a min 8 ASCII character password, you might go for a 64 bit salt.

  3. Yes and no. It's overkill for modern technology; the size of the strings are irrelevant. If you need your passwords to be secure for the next 100 years, well, go for 512.

A reference: http://www.codeproject.com/KB/security/Cryptography%5FNET.aspx

Ben Walther
Re point #2 (purpose of salt):No. The salt is to prevent two things:1. Unsalted Dictionary Attacks (ie MD5 databases)2. If there are two identical plaintext values encrypted in your database, if it is unsalted, then the probability of finding a valid collision in your DB for any tested value is multiplied by N records if it is unsalted. Basically, any big database unsalted means while you might not collide with a specific row, the chance of colliding with any row is higher. Adding a salt returns you to needing individualised per-row attacks providing the salt is unique for each record.
Adam Frisby
+6  A: 

Ben's answer is incorrect, you should not be using SHA* functions to hash passwords. You should be using a hash function that is specifically designed for hashing passwords, such as PBKDF2, BCrypt or SCrypt. Min's answer and comments are correct.

Since you want to use standard .NET library I suggest Rfc2898DeriveBytes which is an implementation of PBKDF2.

http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

DenNukem
I was looking for a one-way hash, Rfc2898DeriveBytes uses keys.
Josh
Your interpretation of Rfc2898DeriveBytes is incorrect, please look again. Also read this on why you shouldn't be using SHA* http://news.ycombinator.com/item?id=995840
DenNukem