La necesidad de esconder la sal para un hachís.

Question

En el trabajo tenemos dos teorías que compiten por las sales. Los productos en los que trabajo utilizan algo como un nombre de usuario o un número de teléfono para agregar el hash. Esencialmente, algo que es diferente para cada usuario pero está disponible para nosotros. El otro producto genera aleatoriamente una sal para cada usuario y cambia cada vez que el usuario cambia la contraseña. La sal se encripta en la base de datos.

Mi pregunta es si el segundo enfoque es realmente necesario. Desde una perspectiva puramente teórica, puedo entender que es más seguro que el primer enfoque, pero desde un punto de vista práctico. Ahora mismo para autenticar a un usuario, el salt debe estar sin encriptar y aplicarse a la información de inicio de sesión.

Después de pensarlo, no veo una ganancia real de seguridad con este enfoque. Cambiar la sal de una cuenta a otra, todavía hace que sea extremadamente difícil para alguien intentar forzar el algoritmo de hash, incluso si el atacante era consciente de cómo determinar rápidamente qué era para cada cuenta. Esto se da por supuesto que las contraseñas son lo suficientemente fuertes. (Obviamente, encontrar el hash correcto para un conjunto de contraseñas donde están todos los dos dígitos es mucho más fácil que encontrar el hash correcto de las contraseñas que tienen 8 dígitos). ¿Soy incorrecto en mi lógica o hay algo que me falta?

EDITAR: Bueno, he aquí la razón por la que creo que es realmente discutible cifrar la sal. (Déjame saber si estoy en el camino correcto).

Para la siguiente explicación, asumiremos que las contraseñas siempre tienen 8 caracteres y la sal es 5 y que todas las contraseñas están compuestas por letras en minúsculas (solo facilita las matemáticas).

Tener una sal diferente para cada entrada significa que no puedo usar la misma tabla de arco iris (en realidad, técnicamente podría si tuviera una de tamaño suficiente, pero ignoremos eso por el momento). Esta es la verdadera clave de la sal de lo que entiendo, porque para descifrar todas las cuentas tengo que reinventar la rueda por así decirlo para cada una. Ahora, si sé cómo aplicar el salt correcto a una contraseña para generar el hash, lo haría porque un salt realmente solo extiende la longitud / complejidad de la frase hash. Por lo tanto, reduciría el número de combinaciones posibles que necesitaría generar para " saber " Tengo la contraseña + sal de 13 ^ 26 a 8 ^ 26 porque sé qué es la sal. Ahora eso lo hace más fácil, pero sigue siendo muy difícil.

Así que en el cifrado de la sal. Si sé que la sal está encriptada, no intentaría descifrarla (asumiendo que sé que tiene un nivel de encriptación suficiente) primero. Yo lo ignoraría. En lugar de tratar de averiguar cómo descifrarlo, volviendo al ejemplo anterior, solo generaría una tabla arco iris más grande que contiene todas las claves para el 13 ^ 26. No saber que la sal definitivamente me ralentizaría, pero no creo que agregue la tarea monumental de tratar de descifrar el cifrado de sal primero. Por eso no creo que valga la pena. Pensamientos?

Aquí hay un enlace que describe el tiempo que durarán las contraseñas bajo un ataque de fuerza bruta: http://www.lockdown.co.uk/?pg=combi

Answer 1

La respuesta aquí es preguntarte de qué estás tratando de protegerte realmente. Si alguien tiene acceso a su base de datos, entonces tienen acceso a las sales encriptadas, y probablemente también tengan acceso a su código. ¿Con todo lo que pudieron descifrar las sales encriptadas? Si es así, el cifrado es bastante inútil de todos modos. La sal realmente está ahí para hacer que no sea posible formar una tabla de arco iris para descifrar toda la base de datos de contraseñas de una sola vez si se la rompe. Desde ese punto de vista, siempre que cada sal sea única, no hay diferencia, se requerirá un ataque de fuerza bruta con sus sales o las sales encriptadas para cada contraseña individualmente.

Answer 2

Es innecesario ocultar una sal.

Se debe usar una sal diferente para cada hash. En la práctica, esto es fácil de lograr al obtener 8 o más bytes del generador de números aleatorios de calidad criptográfica.

De una respuesta anterior mía :

  

La sal ayuda a frustrar los ataques de diccionario previamente calculados.

     

Supongamos que un atacante tiene una lista de contraseñas probables. Él puede hash cada uno   y compararlo con el hash de la contraseña de su víctima, y ??ver si   partidos. Si la lista es grande, esto podría llevar mucho tiempo. El no   quiere pasar tanto tiempo en su próximo objetivo, por lo que registra el resultado   en un " diccionario " donde un hash apunta a su entrada correspondiente. Si   La lista de contraseñas es muy, muy larga, puede usar técnicas como una   Rainbow Table para ahorrar algo de espacio.

     

Sin embargo, supongamos que su próximo objetivo sea su contraseña. Incluso si el   el atacante sabe lo que es la sal, su tabla precalculada es   Sin valor: la sal cambia el hash resultante de cada contraseña. Él   tiene que volver a hash todas las contraseñas en su lista, colocando el objetivo   Sal a la entrada. Cada sal diferente requiere una diferente   diccionario, y si se usan suficientes sales, el atacante no tendrá espacio   para almacenar diccionarios para todos ellos. El espacio de comercio para ahorrar tiempo es no   una opción más larga; El atacante debe recurrir al hash de cada contraseña.   en su lista para cada objetivo que quiera atacar.

     

Por lo tanto, no es necesario mantener el secreto de la sal. Asegurando que el   El atacante no tiene un diccionario precalculado correspondiente a ese   La sal particular es suficiente.

---

Después de pensar un poco más en esto, me di cuenta de que engañarte a ti mismo pensando que la sal puede estar oculta es peligroso. Es mucho mejor asumir que la sal no se puede ocultar y diseñar el sistema para que sea seguro a pesar de eso. Ofrezco una explicación más detallada en otra respuesta.

Answer 3

Mi comprensión de " sal " es que hace que el craqueo sea más difícil, pero no trata de ocultar los datos adicionales. Si está tratando de obtener más seguridad al hacer que sal "secreto", entonces realmente solo desea más bits en sus claves de cifrado.

Answer 4

El segundo enfoque es solo un poco más seguro. Las sales protegen a los usuarios de ataques de diccionario y ataques de tabla arco iris. Hacen que sea más difícil para un atacante ambicioso comprometer todo su sistema, pero aún son vulnerables a los ataques que se enfocan en un usuario de su sistema. Si usa información que está disponible públicamente, como un número de teléfono, y el atacante se da cuenta de esto , entonces les ha guardado un paso en su ataque. Por supuesto, la pregunta es discutible si el atacante obtiene toda su base de datos, sales y todo.

EDITAR: Después de volver a leer esta respuesta y algunos de los comentarios, se me ocurre que parte de la confusión puede deberse al hecho de que solo estoy comparando los dos muy específicos Casos presentados en la pregunta: sal aleatoria vs. sal no aleatoria. La cuestión de usar un número de teléfono como una sal es discutible si el atacante obtiene toda su base de datos, no la cuestión de usar una sal en absoluto.

Answer 5

Una sal oculta ya no es sal. Es pimienta Tiene su uso. Es diferente de la sal.

Pepper es una clave secreta agregada a la contraseña + sal que convierte el hash en un HMAC (Código de autenticación de mensaje basado en hash). Un pirata informático con acceso a la salida de hash y al salt puede teóricamente forzar la fuerza bruta adivinar una entrada que generará el hash (y, por lo tanto, pasar la validación en el cuadro de texto de la contraseña). Al agregar pimienta, aumenta el espacio del problema de forma criptográfica aleatoria, lo que hace que el problema sea intratable sin hardware serio.

Para obtener más información sobre el pimiento, consulte aquí .

Consulte también hmac .

Answer 6

Aquí hay un ejemplo simple que muestra por qué es malo tener la misma sal para cada hash

Considera la siguiente tabla

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)    

Caso 1 cuando la sal 1 es lo mismo que la sal2 Si Hash2 se reemplaza por Hash1, el usuario 2 podría iniciar sesión con la contraseña del usuario 1

Caso 2 cuando la sal 1 no es la misma sal2 Si Hash2 se reemplaza con Hash1, user2 no puede iniciar sesión con la contraseña de los usuarios 1.

Answer 7

  

... algo así como un nombre de usuario o número de teléfono para saltear el hash. ...

     

Mi pregunta es si el segundo enfoque es realmente necesario. Puedo entender desde una perspectiva puramente teórica que es más seguro que el primer enfoque, pero ¿desde qué punto de vista práctico?

Desde un punto de vista práctico, una sal es un detalle de implementación. Si alguna vez cambia la forma en que se recopila o mantiene la información del usuario & # 8211; y tanto los nombres de usuario como los números de teléfono a veces cambian, para usar sus ejemplos exactos & # 8211; entonces es posible que haya comprometido su seguridad. ¿Desea que un cambio tan externo tenga preocupaciones de seguridad mucho más profundas?

¿Detener el requisito de que cada cuenta tenga un número de teléfono debe implicar una revisión de seguridad completa para asegurarse de que no haya abierto esas cuentas a un compromiso de seguridad?

Answer 8

Hay dos técnicas, con diferentes objetivos:

• La " sal " Se utiliza para hacer dos contraseñas de lo contrario igual cifrar de manera diferente. De esta manera, un intruso no puede usar de manera eficiente un ataque de diccionario contra una lista completa de contraseñas encriptadas.

• El (compartido) " secreto " se agrega antes de incluir el hashing de un mensaje, para que un intruso no pueda crear sus propios mensajes y hacer que los acepten.

Answer 9

Tiendo a esconder la sal. Utilizo 10 bits de sal al anteponer un número aleatorio del 1 al 1024 al principio de la contraseña antes de escribirla. Al comparar la contraseña que el usuario ingresó con el hash, hago un bucle de 1 a 1024 e intento todos los valores posibles de sal hasta que encuentre la coincidencia. Esto toma menos de 1/10 de segundo. Tengo la idea de hacerlo de esta manera desde el PHP password_hash y password_verify . En mi ejemplo, el "costo" es 10 por 10 bits de sal. O por lo que otro usuario dijo, oculto " sal " Se llama " pimienta " ;. La sal no está encriptada en la base de datos. Es brutal expulsado. Haría la tabla del arco iris necesaria para revertir el hash 1000 veces más grande. Uso sha256 porque es rápido, pero aún se considera seguro.

Answer 10

En realidad, depende de qué tipo de ataque intenta proteger sus datos.

El propósito de una sal única para cada contraseña es evitar un ataque de diccionario contra toda la base de datos de contraseñas.

Cifrar la sal única para cada contraseña haría que sea más difícil descifrar una contraseña individual, sí, pero debe evaluar si realmente hay un gran beneficio. Si el atacante, por fuerza bruta, encuentra que esta cadena:

Marianne2ae85fb5d

hash a un hash almacenado en el DB, ¿es realmente tan difícil averiguar qué parte es el pase y qué parte es la sal?