¿Cuáles de los algoritmos hash incluidos .NET son lo suficientemente seguros para el hashing de contraseñas?

El password leak of LinkedIn demostró lo importante que es codificar de forma segura sus contraseñas. Sin embargo, incluso las contraseñas hash con sal no son seguras con los algoritmos hash 'normales' (como MD5 y SHA), ya que están optimizados para la velocidad, lo que permite que los hackers calculen 2300 millones de hashes por segundo (fuerza bruta).¿Cuáles de los algoritmos hash incluidos .NET son lo suficientemente seguros para el hashing de contraseñas?

Hay algoritms hash que son seguros de usar, ya que son mucho más intensivas de cálculo, tales como PBKDF2, Bcrypt, PBMAC y scrypt. Sin embargo, estos algoritmos de hash no parecen estar incluidos en .NET Framework.

Entonces, ¿qué algoritmos hashing intensivos de rendimiento se incluyen en .NET Framework?

RESPUESTA: PBKDF2 está incluido en el marco y this site shows how to use it properly.

Fuente

2012-06-08 Steven

Interesante pregunta, me preguntaba lo mismo debido a las mismas razones. :) – pyrocumulus

Nada es "Seguro". Lo que elija para la seguridad siempre será una compensación con otros requisitos como la velocidad, el uso de la memoria, la utilización de la CPU, etc. Lo que considera "lo suficientemente seguro" se basa en * sus * requisitos, que no ha proporcionado. –

@PeterRitchie: Es por eso que me refiero a "algoritmos hashing que son más seguros" y de eso se trata la pregunta. – Steven

Creo que no es realmente un nombre de clase significativo, pero creo que está incluido en .NET Framework. Según múltiples fuentes, Rfc2898DeriveBytes es en realidad una implementación de PBKDF2. MSDN también lo dice así.

Ver Why do I need to use the Rfc2898DeriveBytes class (in .NET) instead of directly using the password as a key or IV? y PBKDF2 implementation in C# with Rfc2898DeriveBytes

por ejemplo.

Fuente

2012-06-08 12:43:21 pyrocumulus

-1

No hay ningún algoritmo hash que sea 100% seguro. El hack de linkedin se debió más a la seguridad de infraestructura/código que el algoritmo de hash. Se puede calcular cualquier hash, solo tarda más tiempo cuanto más complicado sea el hashttihm. Algunos ataques, como los ataques de colisión, en realidad no son mucho más lentos en un hash más complicado.

Siempre me aseguro de tener contraseñas hash (nunca cifrar), restringir el acceso a los servidores. Todos los desarrolladores que trabajan para mí entienden al menos los conceptos básicos de seguridad (inyección de SQL, desbordamientos, etc.) y cualquier sitio de alto perfil en el que yo trabaje está probado a lápiz.

Fuente

2012-06-08 13:24:47 Ketchup

No creo que Steven piense que la elección de un algoritmo de hash seguro lo protegerá de los piratas informáticos. Pero lo protege en caso de que su acceso a la base de datos se vea comprometido. LinkedIn usó hashes SHA1 (!!) sin sal (!!); eso es increíblemente malo. Steven quiere elegir un algoritmo más seguro y tiene razón al hacerlo. Nada es 100% seguro obviamente; solo puedes intentar que sea muy poco probable que un hash sea forzado en un tiempo factible. – pyrocumulus

Bueno, en realidad quería hacer que mi lista de usuarios fuera públicamente accesible desde el sitio web e incluir las contraseñas hash ya que nadie puede descifrarlas. No, por supuesto que no, es broma :-P. @Cloud tiene toda la razón, pero la culpa está en mí. Debería haber hecho un mejor trabajo al describir en mi pregunta que sé esto, pero esto es algo que es tan obvio para mí, que es fácil de olvidar. – Steven

Pero atacar a un hash decente en comparación con lo que hizo linkedin es más caro por un factor de al menos mil millones. – CodesInChaos

También hay:

http://bcrypt.codeplex.com/ (bcrypt)

http://www.zer7.com/software.php?page=cryptsharp (scrypt, etc)

Fuente

2012-06-08 15:15:51