¿Por qué las sales pueden ser públicas? [duplicar]

El punto de una sal única es este: el trabajo que realiza el atacante para descifrar la contraseña con sal de un usuario no se puede reutilizar contra otro usuario. Por lo tanto, aborda este punto de su pregunta:

  

Incluso si tuviera que volver a calcular el hash para cada usuario, es solo un cálculo para cada usuario. Y si la aplicación de una sal es O (1), ¿no debería deshacer el costo de cada usuario O (n)?

Piénsalo de esta manera. Supongamos que tiene usuarios de n y el atacante va a realizar conjeturas de contraseña de m . Si no tiene sales, el atacante puede verificar cada una de sus contraseñas m contra todos los usuarios de n , lo que significa que pueden realizar m × n usuario / contraseña par conjeturas.

Por otro lado, con las sales únicas, cada una de las conjeturas de contraseña del m del atacante solo es aplicable a un usuario. Por lo tanto, solo pueden realizar m usuarios / contraseñas de par de contraseñas. Esta es una gran victoria para el defensor.

Y este análisis asume que el atacante conoce todas las sales. Entonces, la respuesta a su pregunta, estrictamente hablando, es que las sales pueden ser públicas porque ofrecen una gran mejora de seguridad incluso si el atacante las conoce. (En contraste con las claves, por ejemplo, los cifrados ofrecen seguridad no contra un atacante que conoce la clave).

Podemos modificar un poco tu pregunta y preguntar: ¿por qué no mantener las sales en secreto? Bueno, eso es realmente una cosa; el nombre popular para "sales secretas" es Pimienta , y hay personas que los usan: ofrecen más seguridad más allá de lo que hacen las sales públicas. Pero muchas personas simplemente no creen que la seguridad adicional valga la pena el tiempo y la molestia de mantener secretos adicionales. Otros son realmente escépticos de que agrega más seguridad en la práctica:

• enlace
• enlace

Sin embargo, otros son más positivos sobre los pimientos. Cabe destacar que la llamada a presentación de la Competencia de hash de contraseña permitió específicamente que los algoritmos acepten una "clave secreta" (pepper) además de una sal

Pero una cosa es segura: usar pimientos es mucho más complejo que usar sales públicas, debido a las medidas adicionales necesarias para asegurarse de que un compromiso de la base de datos de contraseñas no comprometa los pimientos.

  

Por lo que entiendo, las sales se llaman "sales" en lugar de "claves" porque se les permite ser públicas.

Eso es solo una parte de la historia. Las claves se utilizan en una operación de cifrado reversible. Un hash está diseñado para ser irreversible . Un Salt en un Hash es más parecido a lo que las rutinas de encriptación llaman un Vector de Inicialización. La intención es hacerlo único.

  

Sin embargo, ¿no es trivial pasar de una contraseña con sal a una contraseña con hash si la sal es pública?

La sal no es pública. Se almacena junto al hash. Una base de datos de hashes robados es más difícil de descifrar si cada uno tiene una sal única, incluso si se conocen todas las sales.

de mi otra respuesta a una pregunta relacionada:

Deberías usar un hash de contraseña lento. (es decir, bcrypt) Por "lento" quiero decir computacionalmente costoso, tomando más de 100 ms (en su hardware) ^{con protección DoS *} para probar una sola contraseña. Esto es para aumentar la potencia de procesamiento necesaria (en el hardware del atacante) para encontrar la contraseña por fuerza bruta, en caso de que el hash sea robado.

Por usuario la sal única es altamente recomendada. (en el caso de bcrypt se genera automáticamente) Salt debe ser altamente único (es decir, largo y aleatorio). Usar sal única significa que un atacante tendría que ejecutar un trabajo de fuerza bruta separado para cada usuario .

Si no hubiera 'sal', el atacante podría usar instantáneamente una Rainbow Table y sin fuerza bruta.

Si solo usas 'sal compartida', entonces un atacante podría descifrar las contraseñas de todos los usuarios con un single brute force Job. (no es tan rápido como una mesa de arco iris, pero es mucho más fácil que un Job de fuerza bruta separado para cada uno)

_{* Como comentó @Navin , este sería un posible vector de ataque DoS. Una solución es limitar el número de intentos por hora por IP y por nombre de usuario. También es posible que reduzcas la "lentitud" de tu hash para tomar solo 10 ms. Esto no es tan bueno como 100 ms desde una perspectiva de "hash robado", pero sigue siendo mucho mejor que "microsegundos".}

Resolvamos un problema más simple. Pretenda que el atacante tiene una lista de todas las contraseñas únicas utilizadas en la base de datos, pero no sabe a quién pertenecen. Esta lista contiene contraseñas de p . Hay usuarios n . p no puede ser mayor que n pero en la práctica siempre será estrictamente menor que n .

Con un salt no único , el atacante debe calcular cada hash de contraseña con el salt aplicado. Eso es O (p) cálculos de hash.

Sin sal, si ya existe una tabla de arco iris para el algoritmo hash, el atacante simplemente busca los valores de hash para cada contraseña en la tabla de búsqueda, lo que requiere exactamente cero cálculos de hash.

Con un sal único , el atacante debe calcular aproximadamente la mitad de todos los hash de contraseña para cada usuario , por lo que requiere O (n × p) cálculos de hash.

En este ejemplo muy simplificado, con p≅n , es la diferencia entre O (1) , O (n) y O (n²) . En realidad, el atacante NO debe tener una lista de todas las contraseñas únicas en su base de datos y debe malgastar muchos cálculos de hash al intentar contraseñas que ni siquiera están en la base de datos; en otras palabras, p≫n . Por lo tanto, en los escenarios de la vida real, el impacto es aún más extremo, especialmente para el caso de hash único.

Estoy hablando de la cantidad de cálculos de hash para el tamaño del cálculo aquí, porque si su sistema está bien diseñado con un hash lento, esa será la parte más cara del ataque. Si su parte más costosa es enumerar y comparar un hash calculado para cada usuario, entonces tiene un problema más grave.

Recuerde que una tabla de arco iris es esencialmente una tabla precalculada que se puede aplicar a cualquier conjunto de contraseñas sin sal. Eso significa que no solo se trata de SU tabla de contraseñas, sino también de todos los demás. Crear la tabla del arco iris es difícil e informático. Pero una vez que se crea, puede reutilizarse una y otra vez, y distribuirse a otros como cualquier otra herramienta.

Imagina el escenario en el que no saltaste las contraseñas. Alguien puede ( y ha ) creado conjuntos de tablas precalculadas que esencialmente pueden descifrar las contraseñas de 1-7 o 1-9 o incluso 1-10 caracteres si usaste varios hashes comunes.

La aplicación de una sal suficientemente grande a las contraseñas hace que este ataque de precálculo sea imposible, ya que el precálculo generalmente es mucho más difícil que solo calcular las sales en el archivo de contraseñas.

Sentí que no entendías cómo funcionaba la tabla del arco iris o cómo se usaba, pero no pude ubicar qué sentí así que fui a cavar un poco más y volví a leer el artículo de wikipedia y creo que He aclarado las cosas por mi cuenta y puedo responder tu pregunta.

La respuesta corta es que la tabla del arco iris funciona porque hace coincidir su contraseña en algún lugar de la cadena y la sal hace que la contraseña sea mucho más larga, lo que significa que, para obtener coincidencias, su tabla del arco iris crece hasta el punto de ser impráctico / imposible o sus probabilidades de generar una coincidencia para la contraseña disminuyen.

Una cadena de hash básica utiliza una función de reducción para convertir un hash nuevamente en una posible contraseña y luego hash y repite el proceso. La tabla hash luego almacena la contraseña de inicio que generó el primer hash y la última contraseña "posible" generada por la función de reducción. Para descifrar una contraseña, ejecútela a través de la función de reducción y verifique la tabla para ver si tiene eso como uno de sus resultados registrados. Si no lo hace, lo aplasta, lo reduce de nuevo y lo vuelve a comprobar. Repita ese proceso hasta que haya encontrado una coincidencia o haya recorrido toda la longitud de sus cadenas. Si encuentra una coincidencia, básicamente sigue la cadena hacia atrás hasta que encuentre el resultado original de la función de reducción y el aspecto de la contraseña "posible" anterior que se había copiado y luego se redujo para darle su coincidencia y usted tiene su contraseña. Si no encontró una coincidencia, la tabla de arco iris no cubrió su contraseña.

El proceso tiene problemas de colisión pero no puede detectarlos si no están en el mismo paso de la cadena, por lo que la tabla del arco iris utiliza una función de reducción única para cada paso de reducción realizado en la cadena, por lo que es solo una colisión si sucede en el mismo paso y pueden detectar eso porque ambas cadenas tendrán el mismo resultado final y construirán una nueva cadena que no sea una colisión. Las contraseñas que la tabla del arco iris puede descifrar están determinadas por las posibles contraseñas generadas en la cadena, por lo que el número total de contraseñas cubiertas es el número de pasos en la cadena multiplicado por el número de cadenas almacenadas. Hacer que sus funciones de reducción generen contraseñas mucho más largas posibles para que cubra la contraseña + sal o el resultado de hash de la contraseña + sal hace que la tabla del arco iris sea menos efectiva. Terminas cubriendo muchas menos contraseñas posibles o tus cadenas tardan más tiempo en computar para hacer tu tabla y verificar la contraseña y tu tabla se vuelve más grande y más difícil de almacenar / buscar.

enlace