2010-09-04 14 views
7

Tengo dificultades para entender cómo una sal que se agrega a un hash ayuda a mejorar la seguridad cuando una base de datos de contraseñas u otra información importante se ve comprometida.¿Alguien puede explicar cómo las sales ayudan a almacenar contraseñas hash?

Si la sal es, por ejemplo, "Hola", y se adjunta a la contraseña "contraseña", entonces la sal y la contraseña se almacenan juntos, "hellopassword" y hash para producir:

94e66f94517d606d5ad6d9191b980408952f2ed2 (sha1) 

con la sal luego anexada:

hello$94e66f94517d606d5ad6d9191b980408952f2ed2 

¿Cómo es esto más seguro? El atacante conoce la sal, por lo que ahora puede calcular las contraseñas con poca dificultad adicional ... ¿verdad? ¿O estoy básicamente malentendiendo algo?

+3

Normalmente no agrega la sal después del sha1, como lo hizo en su ejemplo. En su lugar, agregaría la sal a la contraseña 'salt $ password' y generaría un sha1 a partir de ese '94e66f94517d606d5ad6d9191b980408952f2ed2'. De esta forma, la sal y la contraseña nunca se exponen en ninguna estructura de datos. – tidwall

+0

¿Cómo mantendría la sal en secreto? ¿Lo tendría como un valor secreto codificado en el programa? –

+0

No es necesario mantener la sal en secreto; de hecho, todos los esquemas de hash de contraseñas de Linux que usan sal (que son todos los comunes) añaden la sal al hash tanto como lo has hecho. El trabajo principal de Salt (hacer que las tablas del arco iris sean inviables) se logra independientemente de si el atacante conoce la sal o no, y tenerlo almacenado con la contraseña facilita cambiar la sal a voluntad sin tener que hacer que todos los usuarios restablezcan sus contraseñas. Incluso podría tener una sal diferente para cada contraseña. – cHao

Respuesta

8

No, no con "poca dificultad adicional" - con una dificultad significativamente mayor.

Imagine que hay dos mil millones de contraseñas comunes. Es fácil hacer hash y almacenar los resultados. Entonces, si tiene un hash de contraseña sin sal , puede verificar qué contraseñas comunes coinciden con el hash proporcionado.

Ahora compara eso con un hash salado ... ahora tienes dos mil millones de contraseñas comunes, pero también varios miles de sales posibles. Computing all las posibles combinaciones de sal/contraseña tomarán mucho, mucho más tiempo, con suerte se vuelven inviables.

Además, significa que incluso si dos personas tienen la misma contraseña, es muy probable que tengan hashes diferentes, por lo que el descuido de un usuario al revelar su contraseña no pone en riesgo la seguridad del otro.

Consulte el Wikipedia entry (si no lo ha hecho ya) para obtener más información al respecto.

6

sal ayuda de 2 maneras:

1) Cuando dos (o más) personas utilizan la misma contraseña, sin sal se puede ver que utiliza la misma contraseña (los hashes son todos iguales). Entonces, en teoría, si esa persona conoce una de las contraseñas de esa persona, conoce las contraseñas de todos con el mismo hash. Esta es una razón menor.

2) La razón principal es para prevenir ataques comúnmente llamados ataques de diccionario o arcoiris. En estos ataques, alguien usa una base de datos de hashes precalculados para contraseñas comunes. Muchas veces estas bases de datos son gigs de tamaño. Pero es muy fácil en ese momento hacer una búsqueda de los hash que tienes (la contraseña hash) en la lista de hashes precalculados y ver cuál es la contraseña asociada.

Al usar un valor de sal (normalmente desea que sea un número aleatorio), el hash no coincidirá con el diccionario (la probabilidad de que precalculen todas las contraseñas con todos los valores de sal posibles es exponencialmente más difícil). Entonces, incluso si su usuario usa una contraseña fácil de atacar, diga "Contraseña", que se garantiza que es cualquier tabla de diccionario/arcoiris de contraseñas. Dependiendo de su valor de sal aleatorio, hace que el hash sea prácticamente inútil. para el atacante Mientras tanto, para usted, dado que la sal se almacena en texto sin formato, le resulta muy fácil agregarla a su texto sin formato para comparar la contraseña que ingresó el usuario.

+0

Pregunta rápida. Si tiene las contraseñas con sal diferente cada vez, y almacena el valor resultante en lugar de la contraseña. ¿Cómo sabe cuál es la sal que debe usar para cifrar la contraseña que el usuario ingresa al iniciar sesión si no almacena el hash en ninguna parte? No almacena la sal aleatoria en la base de datos, ¿verdad? –

+2

Si usa sal aleatoria, la almacena con la contraseña. De lo contrario, no puede volver a crear el hash para verificar la contraseña. – cHao

+0

Eso es lo que quería leer;) Marque esta interesante respuesta (el comentario de Ian en la primera respuesta): http://stackoverflow.com/questions/615704/preferred-method-of-storing-passwords-in-database –

3

La sal no se adjunta al hash, se agrega a la contraseña THEN hashed. Esto es más seguro porque los piratas informáticos deben conocer la sal y la contraseña real, que ambos deberían proteger en gran medida.: D

+0

Si quiere probar que la "contraseña" es la contraseña correcta, ¿cómo puede hacer esto sin conocer la sal, "hola"? Por lo que yo entiendo, tienes que guardar la sal ... ¿verdad? –

+0

Tienes que almacenarlo, pero podría ser "almacenado" como una variable en tu script. Sin embargo, las sales de codificación dura solo son marginalmente mejores que no saladas, IMO. – cHao

Cuestiones relacionadas