Sal “real” y sal “falsa”

43

Durante un período de Q & A en DEFCON este año, un miembro de la audiencia mencionó que estamos usando "sal falsa" cuando concatenamos un valor aleatorio y una contraseña antes de hacer hash. Definió "sal real" como algo visto en la implementación de la cripta de Unix original que cambió la forma en que se ejecutó el algoritmo, por lo que requirió que se usara un código diferente para descifrar cada contraseña y los ataques de GPU muy preocupantes.

¿Hay algún mérito para la discusión de sal "real" y "falsa"?

    
pregunta Jeff Ferland 09.08.2011 - 15:32
fuente

6 respuestas

45

La distinción es arbitraria. Un algoritmo que reconoce la sal funciona al tomar datos de entrada y mezclarlos de varias maneras, y no hay ningún método para insertar la sal que sea más o menos "falsa" que cualquier otra.

Intentar diseñar un algoritmo de procesamiento de contraseñas que sea eficiente en una CPU de propósito general pero no se adapte bien a una GPU (o un FPGA o ASIC personalizado) es un tema de investigación real. De esto se trata scrypt , y podría decirse que bcrypt ya hace un buen trabajo. La idea aquí es usar accesos en tablas que se modifican constantemente; el acceso a la tabla en la RAM es algo para lo que la CPU de propósito general es buena, pero lo que dificulta las cosas para la GPU (pueden hacerlo, pero no con el paralelismo completo que se obtiene con una GPU).

    
respondido por el Thomas Pornin 09.08.2011 - 16:27
fuente
21

Sí, hay una distinción válida para ser dibujada; necesitaría un criptólogo para decirle cuán significativa es la diferencia.

Una "sal real" como la que describiste se usa para "perturbar el algoritmo de cifrado". Entiendo esto vagamente, pero no lo suficiente como para describirlo correctamente. Basta con decir que con una sal real, el texto de la contraseña original está cifrado pero con diferentes salidas, dependiendo de cómo el algoritmo incorpore la entrada de sal (el algoritmo tiene (al menos dos) entradas, la sal y (por separado) el texto de la contraseña original).

Una "sal falsa" implica modificar el texto de la contraseña original con la sal antes de cifrarlo con el algoritmo criptográfico. Por ejemplo, si mi contraseña es "nezperce", y mi salt es "qp", entonces el algoritmo recibirá el texto de contraseña "qpnezperce" modificado para codificar. Si Alicia también intenta usar la contraseña "nezperce", pero tiene sal "w4", el algoritmo codificará el texto de la contraseña modificada "w4nezperce" para ella. Como resultado, su hash cifrado será diferente del mío, aunque ambos usamos la misma contraseña.

Ambos métodos proporcionan el beneficio principal de la sal; para garantizar que la misma contraseña no siempre se cifre de la misma manera. El uso de sales aumenta la dificultad de montar un ataque hash pre-computado (anteriormente dije diccionario o ataque de fuerza bruta, ver comentarios).

Creo que hay otras ventajas al usar una "sal real", como el aumento de la sobrecarga computacional (que ralentiza los ataques). Pero, una vez más, necesitarías a alguien con más habilidad de criptografía que yo para saber si eso es cierto o no.

Creo que la ventaja de una "sal falsa" es que es más fácil de implementar y requiere menos conocimientos de criptografía. Sé que el lugar donde más frecuentemente he visto sales falsas son las aplicaciones web que administran su propia base de datos de autenticación.

    
respondido por el gowenfawr 09.08.2011 - 16:08
fuente
7

Como señaló Thomas, la noción general de que solo se aplica la sal como una modificación al algoritmo de hash realmente no le otorga ninguna protección adicional. Puede requerir que el atacante adapte los ataques de hardware y software existentes, pero también puede meterte en problemas si realmente no sabes lo que estás haciendo.

Pero se perdieron la otra innovación anterior en el documento original sobre la salazón, lo que normalmente se llama "pimienta": una clave personalizada que forma parte de la implementación y no se almacena junto con las contraseñas. Me refiero a la forma en que Morris y Thompson introdujeron ese concepto también en su artículo seminal de Unix en la discusión en Password Hashing ¿agregar sal + pimienta o es suficiente sal?

Una pimienta tiene la ventaja de que puede usarla junto con una sal, de manera que incluso si alguien roba la base de datos de contraseñas (que tiene las sales), también necesitaría robar la pimienta (tal vez incorporada en la aplicación). o el código de la biblioteca de hash o almacenado en un sistema completamente separado) para descifrar las contraseñas. En muchos casos eso no será mucho más difícil, pero en algunos casos puede ser mucho más difícil.

    
respondido por el nealmcb 15.08.2011 - 19:06
fuente
5

No está familiarizado con los detalles de la implementación de criptografía Unix original. Pero eso no parece realmente tener sentido para mí. Especialmente teniendo en cuenta cuál es el propósito de eliminar las contraseñas en primer lugar. Creo que si el uso de un salt cambia su algoritmo para hacerlo "más fuerte", en primer lugar está utilizando el algoritmo incorrecto.

    
respondido por el M15K 09.08.2011 - 16:04
fuente
3

También estuve en la charla y fui la que se sentó con los dos criptógrafos durante la charla. La verdadera sal en comparación con una sal falsa realmente me intrigó. Ahora perdóneme, ya que no tengo mis notas frente a mí, pero hay una gran diferencia en la seguridad de la verdadera sal en comparación con una sal falsa. Una sal verdadera altera la clave a medida que ingresa en el cifrado de bloque, por lo que no solo es el texto plano (contraseña) la clave para determinar cómo se llevarán a cabo las iteraciones, también es única. Ahora, una sal falsa simplemente altera el texto sin formato (contraseña) y la clave sigue siendo la misma. Al ajustar el algoritmo, la sal verdadera se vuelve exponencialmente más difícil de descifrar que una sal falsa.

Así que vamos a usar un ejemplo para describir esto. En este ejemplo, usaré un hash MD5 (no recuerdo si puedes usar una sal verdadera en MD5, así que no me llames por esto) con una sal verdadera y una sal falsa. Ahora digamos que estoy usando CUDA-Multiforcer como mi cracker de contraseñas de GPU. Me gustaría establecer que se ejecute contra el estándar MD5 para intentar descifrar la contraseña, pero desde que ingresé a la contraseña, podría ejecutarse para siempre según la sal (verdadera o falsa). Ahora, parte de la descripción que se me dio fue la capacidad de descifrar la sal falsa y la forma en que solo demoró un poco más en procesarse / romperse al romper el hash en pedazos. No seguí lo que decían, así que podría estar muy equivocado con eso. Ahora supongamos que pudimos adquirir la contraseña salt (true of falso). Usando una sal falsa, simplemente la ingresamos en nuestro cracker de contraseñas y continuamos con fuerza bruta hasta que podamos hacer coincidir los hashes. No es muy difícil de hacer y se ejecutará con bastante rapidez.

Ahora, si estuviéramos usando una verdadera sal, sería exponencialmente más difícil y más largo para romper los hashes. Usando una sal verdadera, tendría que reescribir realmente parte de CUDA-Multiforcer para usar una sal verdadera con el algoritmo específico que se estaba usando. Recuerde que cambia la clave en el cifrado, lo que significa que no es solo un simple cambio de texto, es un cambio de algoritmo, así que ahora tengo que modificar el código para hacer esto. Bien, ahora hemos cambiado la forma en que se ejecuta el cracker de contraseñas, ahora tenemos un problema de velocidad. Con el cambio de la clave, ahora toma un poco más de tiempo probar cada contraseña, ya que ahora está cambiando la iteración que utiliza para cada contraseña forzada. Ambos me dieron algunos ejemplos de la diferencia en la velocidad, y creo que con una sal falsa fue de alrededor de 1 millón por segundo, y una sal verdadera estaba alrededor.

    
respondido por el GuloGulo 15.08.2011 - 16:57
fuente
2

La distinción entre sal falsa y sal real solo hace una diferencia si los algoritmos de hash están ocultos para el atacante. una "sal real" que determina una variación del hashing algo en un hashing estándar abierto se implementaría fácilmente mediante un ataque distribuido / GPU, ya que el atacante conoce todas las entradas y, por lo tanto, el sub-algo se puede determinar fácilmente antes de tiempo.

El primer hashing de Unix para contraseñas (como lo recuerdo en Bell System V7) NO proporcionó el algoritmo para el hashing de contraseñas, era la única parte del sistema para la que solo podía obtener el archivo .o donde las universidades pudieron obtener el código fuente para todo lo demás.

    
respondido por el Soren 09.08.2011 - 19:34
fuente

Lea otras preguntas en las etiquetas