2010-06-17 17 views
5

No soy de ninguna manera un experto en seguridad o incluso un novato. Soy novato en seguridad, en el mejor de los casos.¿Qué debo usar para los campos de contraseña en una tabla; MD5 o SHA1?

Alguien me sugirió que use SHA1 en lugar de MD5. ¿Por qué iba a elegir uno sobre el otro? ¿Es uno más seguro?

+2

Tenga cuidado con las respuestas de "culto a la carga" que afirman que un algoritmo hash está "roto" o "defectuoso" sin indicar para qué propósito el algoritmo es defectuoso. Si almacena hashes de contraseñas SHA-1 simples en una base de datos, su enfoque es tan erróneo como con MD5 (vea http://en.wikipedia.org/wiki/Rainbow_table). Creo que el costo requerido para generar colisiones hash no es muy importante en el caso de uso de almacenamiento seguro de las contraseñas de los usuarios en una base de datos. Las respuestas correctas se basan en el uso de una sal, hash con clave, PBKDF2, etc. – dtb

+0

+1 - Este es un gran ejemplo de una pequeña pregunta que parece perfectamente inocente en la superficie pero que en realidad es un brillante punto de entrada a un mucho más grande, muy turbio y muy importante campo de minas. –

Respuesta

10

me gustaría utilizar SHA2 (256) como mínimo - sin embargo:

Hay poco o ningún punto en hash simplemente una contraseña en una base de datos debido a ataques rainbow table. Del mismo modo, el hash salado es mejor, pero si alguien tiene acceso a su base de datos, entonces es probable que tenga acceso a su código, en cuyo caso probablemente puedan desensamblar una sal fija. Igualmente, si usa una sal aleatoria, entonces la está almacenando dentro de la fila de todos modos, por lo que, aunque ralentiza a la gente, puede atacarla con una tabla de arcoiris.

Una mejor solución es usar Password Stretching que usa una sal aleatoria así como un número aleatorio (alto) de iteraciones para que intentar un ataque de fuerza bruta contra cada contraseña demore significativamente más y por lo tanto es más difícil crackear todo las contraseñas

Creo en .Net esto se puede lograr utilizando PBKDF, pero he perdido un enlace (alguien me lo proporcionó una respuesta a una pregunta que hice hace un tiempo). EDITAR-Encontrado el enlace para .Net: Rfc2898DeriveBytes Class.

En MD5

Mientras MD5 de hecho se ha demostrado que ser 'roto' como se ha mencionado por las otras respuestas, la razón principal por la que podría no usarlo - y por lo que he leído que es aconsejable usarlo - es porque en realidad es muy rápido, lo que aumenta la posibilidad de una grieta dentro de un período de tiempo determinado.

+0

+1. Esta es la única respuesta que lo hizo bien hasta ahora. – dtb

+0

Las contraseñas son tontas. Si desea seguridad definida (aunque no comprobada), debe usar certificados de cliente. Las contraseñas siempre se romperán sin importar lo que una vez que el atacante obtenga su base de datos, por ejemplo, podría configurar un registrador para registrar las contraseñas antes de que se salaran y se verifiquen contra la base de datos si tiene control sobre el lugar correcto. O podría montar un ataque paralelo de fuerza bruta contra el hash. Por otra parte, generalmente se atornilla una vez que el atacante posee algo en su infraestructura. –

+0

Incluso si tuviera una contraseña que fuera demasiado larga para aplicar el hash de fuerza bruta, probablemente no tenga esa contraseña en ningún otro sitio (si lo hace, ya la perdió). Si no tiene esa contraseña en ningún otro sitio, entonces no tiene sentido esconderla del atacante, ya que esta es la seguridad a través de la oscuridad en el mejor de los casos. Piénselo, el único caso que lo salvará es que el atacante solo tenga acceso de lectura a su base de datos y, por alguna razón, no pueda secuestrar las sesiones desde su DB (por ejemplo, la sesión se restablece en el cambio de IP). Ese es un escenario muy poco probable. –

0

MD5 ha sido "roto", y los niveles más altos de seguridad ahora requieren SHA-2, en realidad. Es una lectura bastante interesante aquí http://en.wikipedia.org/wiki/MD5.

Editar: 9 segundos finales :)

1

Cualquiera que sea su funcionamiento, utilizar hashes salados.

Buena suerte.

1

El almacenamiento es económico y los procesadores son rápidos. usa una sal de 1 kilobyte con SHA-512.

3

MD5 y SHA1 se consideran inseguros, con SHA-1 siendo mejor. Sin embargo, hay 2 cosas que usted debe considerar:

  1. por "inseguridad", que significan para decir que es matemáticamente más fácil que la fuerza bruta para determinar el valor de pre-hash. A veces esto significa que podrían reducir de mil millones de cálculos a 900 millones, otras veces es significativamente menor. Esto no es tan inseguro como mi punto 2.

  2. Dado que está creando un hash, es fácil para un pirata informático determinar las contraseñas de su base de datos completando una tabla llena de contraseñas comunes y ejecutándola con el mismo algoritmo hash, independientemente de cuál use.Esto se llama una tabla de arco iris.

Por ejemplo, muchas personas usan "contraseña" y "john" como contraseñas. En MD5, estas dos contraseñas siempre generan a: contraseña: 5f4dcc3b5aa765d61d8327deb882cf99 John: 527bd5b5d689e2c32ae974c6229ff785

Así que si sólo MD5 sus contraseñas, y alguien tan ingenuo como para hacer que su contraseña, es probable que se vea comprometida si un hacker controla su base de datos y lo ejecutó contra una tabla de arco iris.

Sin embargo, si agrega algún tipo de galimatías a todos los valores prehechizos, como "password12345" y "johnxyz", obtendrá 2 hashes completamente diferentes que no serían los mismos que los de arriba. Esto se llama valor de sal e impide que las tablas de arco iris sean tan efectivas.

Mi recomendación sería utilizar el más alto nivel de los algoritmos SHA que pueda en su lenguaje de programación, y hash contra un valor de sal (puede crear uno "aleatorio" si lo desea) usted almacena en el registro de la base de datos con la contraseña hash.

DB columns: Nombre de usuario | Contraseña | Sal

Este no es el sistema más seguro en el que nadie haya pensado, pero es probable que funcione para el suyo.

+2

También puede hacer hash con el nombre de usuario, que probablemente sea único en un usuario base de datos, es decir, una "sal aleatoria". – Patrick

+0

Sí, prácticamente todo lo que quisieras funcionaría si no tuvieras la necesidad de que fuera verdaderamente aleatorio. Hay, por supuesto, generadores de números aleatorios que podría hash si realmente le importa. – Jordan

+0

+1 Aunque hay muchas maneras en que un hash puede volverse * "inseguro" * a los ojos de la comunidad de seguridad; ese es solo uno de ellos. Si las vulnerabilidades conocidas afectan actualmente a su aplicación no viene al caso: ** ¿Por qué usar un hash teóricamente inseguro cuando se usa una seguridad teórica es tan fácil? ** Además, es mejor que lamentar porque, como siempre dice Bruce Schneier, , * "¡Los ataques solo mejoran, nunca empeoran!" * :) –

Cuestiones relacionadas