La necesidad de ocultar la sal para un hash

Ocultar una sal es innecesario.

Se debe usar una sal diferente para cada hachís. 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 previa mía :

Salt ayuda a frustrar los ataques de diccionario pre-calculados.

Supongamos que un atacante tiene una lista de posibles contraseñas. Él puede hachís cada uno y compararlo con el hash de la contraseña de su víctima, y ver si coincidir. Si la lista es grande, esto podría llevar mucho tiempo. Él 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 Mesa arco iris para ahorrar algo de espacio.

Sin embargo, supongamos que su próximo objetivo saltó 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. He tiene que re-hash todas las contraseñas en su lista, fijando el objetivo de sal a la entrada. Cada sal diferente requiere una sal diferente diccionario, y si se utilizan suficientes sales, el atacante no tendrá espacio para almacenar diccionarios para todos ellos. Espacio de negociación para ahorrar tiempo no es más larga una opción; el atacante debe recurrir a hash cada contraseña en su lista para cada objetivo que quiere atacar.

Por lo tanto, no es necesario mantener la secreto de sal. Garantizar que la el atacante no tiene un diccionario pre-calculado correspondiente a eso la sal particular es suficiente.

Después de pensar un poco más en esto, me he dado cuenta de que engañarse a sí 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. Proporciono una explicación más detallada en otra respuesta.

Mi comprensión de "salt" es que hace que el agrietamiento sea más difícil, pero no intenta ocultar los datos adicionales. Si está tratando de obtener más seguridad haciendo que la sal sea "secreta", entonces realmente solo desea más bits en sus claves de cifrado.

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

EDIT: Después de releer 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 casos muy específicos presentados en la pregunta: sal aleatoria vs sal no aleatoria. La cuestión de usar un número de teléfono como saltes discutible si el atacante obtiene toda su base de datos, no la cuestión de usar una salt en absoluto.

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

Pepper es una clave secreta añadida a la contraseña + salt que convierte el hash en un HMAC (Código de autenticación de mensajes basado en Hash). Un hacker con acceso a la salida de hash y la salt puede teóricamente adivinar por fuerza bruta una entrada que generará el hash (y por lo tanto pasar la validación en el cuadro de texto contraseña). Al agregar pimienta, aumenta el espacio problemático en un espacio criptográficamente aleatorio manera, haciendo el problema intratable sin hardware serio.

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

Véase también hmac.

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

Considere la siguiente tabla

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

Caso 1 cuando sal 1 es igual a sal2 Si Hash2 se reemplaza con 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 por Hash1, el usuario 2 no puede iniciar sesión con la contraseña de usuarios 1.

... algo así como un nombre de usuario o número de teléfono para salar 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 ¿qué pasa desde un punto de vista práctico?

Desde un punto de vista práctico, un salt es un detalle de implementación. Si alguna vez cambia la forma en que se recopila o mantiene la información del usuario – y tanto los nombres de usuario como el teléfono los números a veces cambian, para usar sus ejemplos exactos, entonces puede haber comprometido su seguridad. ¿Quieres 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 ha abierto esas cuentas a un compromiso de seguridad?

Hay dos técnicas, con diferentes objetivos:

• La "sal" se usa para hacer que dos contraseñas iguales se cifren de manera diferente. De esta manera, un intruso no puede usar eficientemente un ataque de diccionario contra toda una lista de contraseñas cifradas.

• El "secreto" (compartido) se agrega antes de hashear un mensaje, para que un intruso no pueda crear sus propios mensajes y hacerlos aceptar.

Tiendo a esconder la sal. Uso 10 bits de sal anteponiendo un número aleatorio del 1 al 1024 al principio de la contraseña antes de hash. Al comparar la contraseña introducida por el usuario con el hash, hago un bucle del 1 al 1024 y pruebo cada valor posible de salt hasta encontrar 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 desde lo que otro usuario dijo, oculto "sal" se llama "pimienta". La sal no está cifrada en la base de datos. Es bruto forzado a salir. Haría necesaria la tabla rainbow para revertir el hash 1000 veces más grande. Utilizo sha256 porque es rápido, pero todavía se considera seguro.

Realmente, depende del tipo de ataque que esté tratando de proteger sus datos.

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

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

Marianne2ae85fb5d

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