2010-04-06 31 views
12

He leído muchas de las preguntas sobre SO sobre esto, pero muchas respuestas se contradicen entre sí o no entiendo.Sal, contraseñas y seguridad

Siempre debe almacenar una contraseña como un hash, nunca como texto sin formato. Pero debe almacenar la sal (única para cada usuario) junto a la contraseña + sal hash en la base de datos. Esto no me parece muy inteligente ya que nadie podría acceder a la base de datos, buscar dice la cuenta llamada Admin o lo que sea y luego descifrar la contraseña.

+0

http://stackoverflow.com/questions/213380/the-necessity-of-hiding-the-salt-for-a-hash/215165#215165 – tanascius

Respuesta

25

Mucha gente dice "para detener tablas de arcoiris" sin explicar qué tablas de arcoíris hacen o por qué esto los detiene.

Las tablas Rainbow son una forma inteligente de predefinir una gran cantidad de hashes y almacenarlos en menos memoria de lo que sería necesario, y puede usarlos para invertir rápidamente un hash. Las tablas para funciones simples como hash = md5(password) y hash = sha1(password) son comunes.

Sin embargo, se pueden generar para CUALQUIER función hash que se puede describir como output = f(input). Si utiliza una sal para todo el sitio para todas las contraseñas de usuario, por ejemplo hash = md5(salt+password), puede construir una función f, f(password) = md5(salt+password). Por lo tanto, podría generar tablas rainbow para esta función, lo que llevaría mucho tiempo, pero luego le permitiría descifrar cada contraseña en la base de datos con gran rapidez.

Si la sal es diferente para cada contraseña, no puede generar una tabla de arcoiris que descifrará todas las contraseñas en la base de datos. Podrías generar uno nuevo para cada usuario, pero eso sería inútil: la fuerza bruta ingenua no sería más lenta. Por lo tanto, tener una sal separada para cada usuario detiene el ataque de las tablas del arco iris.

Hay varias maneras de lograr esto.formas populares incluyen:

  • Una sal separada para cada usuario, almacenado junto con sus otros detalles en la base de datos: hash = hashfunction(salt + password)
  • Una sal global y un valor único para cada usuario: hash = hashfunction(salt + password + user_id) por ejemplo
  • Una sal global y una sal por usuario: hash = hashfunction(global_salt + user_salt + password)

Tener una sal global podría añadir un poco de complejidad adicional al agrietamiento las contraseñas, ya que podría ser almacenado fuera de la base de datos (en el código, por ejemplo) que los atacantes no pueden ganar el acceso a los en el caso de una violación de la base de datos. Criptográficamente, no creo que agregue mucho, pero en la práctica podría retrasarlos.

Por último, para responder a su pregunta fue:

Almacenamiento de la sal junto con los datos de usuario no debilita el hash. Las funciones hash son unidireccionales: dado el hash de una contraseña, incluso una sin sal, es muy difícil encontrar esa contraseña. La motivación detrás de la salazón no es hacer un hash individual más seguro, sino hacer que la recolección de hashes múltiples sea más segura. Existen varios vectores de ataque para una colección de hashes sin sal:

  • tablas Rainbow
  • contraseñas hashing comunes (123, password, god) y ver si existen en la base de datos, y luego poner en peligro las cuentas
  • Buscar hash idénticos en la base de datos, lo que significa contraseñas idénticas (probablemente)
+0

Por "Un hash global y un hash por usuario" quiere decir "A ** ** salt ** y un ** usuario ** salt **", ¿verdad? Similar en otras oraciones ... –

+0

¡De hecho! Gracias por señalar eso :) – ZoFreX

+0

¿significa "+" en "sal + contraseña" la suma literal? – HopefullyHelpful

3

La sal está destinada a alterar las rainbowtables existentes. No es una amenaza a la seguridad conocer la sal. Si conoces la sal, igual deberías saber la contraseña.

+0

pero seguramente si salt + password = hash then hash - salt = password? –

+1

sin apretar, pero recuerde que el algoritmo hash es unidireccional. [do_hash (salt + password) = hashed_password. ] Si se conoce una sal, el atacante debe ejecutar do_hash (salt + password_guess) para cada intento de contraseña, para construir una tabla rainbow o ataque de fuerza bruta/diccionario cada contraseña. Cambia la sal para cada usuario y esto deja un espacio de búsqueda muy grande. – Cheekysoft

+0

, pero ¿por qué el atacante querría todas las contraseñas de los usuarios? Seguro que solo buscaría a un administrador, etc. –

2

Bueno, en primer lugar, el objetivo principal de la sal es deshabilitar la fuerza bruta de las contraseñas, por ejemplo, evita el uso de tablas rainbow para comprometer rápidamente una contraseña.

Incluso si un atacante obtiene acceso a una base de datos, no es tan fácil encontrar las contraseñas reales de las sales (especialmente si no tiene el código y no sabe cómo se codifica la contraseña). Sin embargo, lo que me gusta hacer para obtener seguridad adicional es también hash una contraseña con un hash estático que se especifica en el código. De esta forma, no es suficiente comprometer la base de datos. Un ejemplo de tal método (en PHP):

$hashed_password = sha1($user_password . $user_salt . $static_salt); 

$user_salt es la sal en la base de datos única para cada usuario, $static_salt es la sal se especifica en la configuración de su código en algún lugar.

+0

No estoy seguro de que esto haga mucho más que dar una falsa sensación de seguridad. –

+1

Como dijo Grimmy, si alguien compromete la base de datos y obtiene las contraseñas y saldos hash del usuario, puede usarlas para generar nuevas tablas rainbow (suponiendo que conozcan el método hash utilizado, que puede deducir fácilmente en caso de software de código abierto) . Si también incluye una sal no almacenada en la base de datos en la contraseña de hash, un atacante no puede generar una nueva tabla de arcoiris solo comprometiendo la base de datos. No es solo un falso sentido de seguridad. –

+0

No puede generar tablas de arcoiris si hay diferentes sales para cada usuario. Veo lo que reko_t sugirió usar mucho y tampoco estoy seguro de si realmente agrega seguridad. Tengo una idea para una situación en la que sí lo hace: Si tuvieras una base de datos muy grande, y cada contraseña hash fuera como él dijo, pero sin la sal estática: Podrías ejecutar algunas consultas, por ejemplo, para cada usuario, hash "1234" + user_salt y almacenar coincidencias. Tendrás la garantía de comprometer un puñado de cuentas. Si hubiera un hash desconocido en todo el sitio, este vector no sería posible, y encontrar el hash sería extremadamente difícil. – ZoFreX

1

Si no almacena la sal, ¿cómo comprobará si se proporcionó la contraseña correcta?

+1

Quería decir que debería almacenarlo en la base de datos principal en lugar de en otro lugar –

+1

@Jonathan - Guárdelo en la misma tabla de la base de datos además de las columnas de loginid y contraseña. No importa si la sal está comprometida. –

6

Salt se usa para aumentar el tiempo que un atacante tendría que pasar para encontrar una contraseña que coincida con el hash almacenado en la base de datos. Normalmente, la tabla de búsqueda, como la tabla arcoiris (consulte http://en.wikipedia.org/wiki/Rainbow_table), se utiliza para lograr esto.

Lo que cuesta tiempo no es la búsqueda en sí misma, sino el momento de calcular la tabla del arco iris. Agregar una sal obliga al atacante a volver a calcular una nueva tabla de arcoiris, incluso si el atacante sabe que pondría en peligro la base de datos

+7

Una sal también hace que los hash almacenados sean únicos, incluso si dos usuarios tienen la misma contraseña. –

+0

@Anders Abel: solo estadísticamente hablando. Por supuesto, esto depende del tamaño de la sal y de la base de usuarios, pero con los viejos hashes de contraseñas basados ​​en UNIX DES, solo hay 12 bits de sal, así que si tenemos 4097 usuarios con la misma contraseña, al menos dos tendrá hashes de contraseña idénticos. – Vatine

+0

La computación de una mesa de arcoiris vale totalmente la pena para, digamos, 100,000 usuarios. El punto es que no se puede hacer si la sal es diferente para cada usuario: computar 100,000 tablas de arcoiris no tendría sentido. – ZoFreX

2

Bien, bien, bien ... tantas discusiones ... tanta información. tantas preguntas ... veo que después de todas las preguntas son respuestas aquí está el resumen.

  1. ¿Por qué Salt?
  2. ¿Por qué Salt se almacena junto con el hash de (contraseña + sal).

Aquí está mi comprensión.

  1. Los hackers tienen la tabla del arco iris para todas las palabras del diccionario que él hizo con gran esfuerzo. Cada tabla de arcoiris se saca del hacker. En palabras simples, es muy difícil.
  2. Como en el punto 1, si hacemos que el hacker calcule la tabla de arcoíris para cada usuario, entonces se volverá viejo cuando sepa la contraseña. Y si el usuario cambia frecuentemente la contraseña, incluso los nietos del hacker se volverán viejos cuando sepan la contraseña.
  3. Ok. Entonces usa sal diferente para cada usuario. Esto hace que el hacker use un ataque separado para conocer la contraseña de cada usuario.
  4. Veo que varios lectores señalaron que, en lugar de golpear frontalmente a cada usuario, un gran hacker pondrá todo su esfuerzo en la cuenta de administrador y entonces estará listo :). Entonces, en este caso, daremos un paso adelante y luego utilizaremos un método diferente para calcular el hash. Digamos que la sal no es exactamente lo que se almacena. Puede ser la mitad del hash real. La otra mitad está almacenada en otro lugar de alguna otra manera (calculada de alguna otra manera). Esta es solo una medida de seguridad adicional. Y sabemos que en los tiempos actuales, el poder de cálculo de las computadoras está aumentando.Así que la gente ética sabe que la supercomputadora más rápida del mundo tardará 1 año en descifrar la contraseña de administrador (solo un ejemplo). Entonces fuerzan una política que dice cambiar la contraseña de administrador cada 3 meses. cuando el hacker conoce la contraseña anterior, la nueva está en efecto. O digamos que la base de datos está en peligro, y luego los buenos se enteran cuando el pirata informático descifra la contraseña. Y los buenos cambian las cosas para entonces (recuerden la actualización de alogorithms ..sha1 sha2 y ahora sha3) .....

Ok ... aunque no está completo, pero mi punto es que los chicos toman mucha tiempo ... pero los buenos están un paso adelante para asegurarse de que conozcan la tecnología que usarán los malos para crackear. Entonces, conciba una mejor tecnología por tiempo.

Tenga cuidado ....

Cuestiones relacionadas