Seguridad criptográfica de sales no aleatorias generadas dinámicamente

12

Entonces, cuando se trata de seguridad, cuando tengo una idea que parece buena, pero parece que nadie más lo está haciendo, trato de asumir que estoy pasando por alto algo obvio o significativo. Este es uno de esos casos ...

El contexto de esta pregunta es un sistema de autenticación en el que estoy empezando a trabajar. He implementado sistemas similares en el pasado, y generalmente tengo mi cabeza en torno a la cuestión de "sal y hash", pero de ninguna manera soy un experto en seguridad criptográfica.

Cuando estaba en el proceso de definir el almacenamiento para 16 bytes aleatorios de sal en mis registros de usuario, se me ocurrió que podría haber una manera de reducir la superficie de ataque en caso de que alguien haya robado o haya accedido a mi datos del usuario. Estoy operando a partir de los siguientes supuestos:

  1. Si un pirata informático roba los datos de mi usuario, tendrá acceso a una representación hash + (repetida) con sal de la contraseña del usuario, y el valor de sal en sí.
  2. Si el pirata informático quiere determinar el valor de texto sin formato de esa contraseña, tiene un poco de trabajo de fuerza bruta frente a ellos.
  3. Sin embargo, dada la sal, el espacio de búsqueda de ese ataque de fuerza bruta se reduce considerablemente. *

* No estoy 100% seguro de que el punto tres sea correcto, pero tiene sentido para mí si un algoritmo de fuerza bruta puede suponer que el valor de hash previo consiste en <8-or-so-bytes-of-password> + <16-bytes-from-stolen-salt> (o una combinación similar de la contraseña y valores de sal), entonces hemos reducido el espacio de búsqueda por cantidades algorítmicamente significativas.

< obligatorio a mitad de la pregunta disculpa por la longitud de esta pregunta aquí >

Entonces, dado que mi línea de pensamiento actual es la anterior, la solución que considero esencialmente se reduce a usar valores constantes y conocidos sobre un usuario para generar dinámicamente una sal para usar durante el paso de hashing.

Dado que los valores de sal realmente no tienen que ser criptográficamente "nada", siempre y cuando no se puedan adivinar hasta el punto de requerir el descubrimiento de fuerza bruta, ¿es suficiente para tomar una transformación de, digamos, el nombre de usuario y la contraseña proporcionados? (por ejemplo, aplique algo de SHA-2 y sistemas de cifrado de propiedad), y úselo en el paso de hash.

Por supuesto, si alguien también robara el código, la generación de sal "secreta" no tiene sentido. La única seguridad adicional que estoy tratando de lograr es forzar al pirata informático a robar mis datos y mi código si quieren la comodidad del espacio de búsqueda reducido descrito anteriormente en el punto 3.

Espero haber descrito adecuadamente (y no demasiado verbalmente) mi pregunta y mi razonamiento. La pregunta específica que espero haber respondido es si se trata o no de un medio criptográfico (o no) seguro para almacenar y comparar las contraseñas de los usuarios.

Editar: Parece que los puntos clave de mi pregunta pueden haberse perdido en el ruido de arriba. Déjame intentar ser más explícito:
  1. ¿Tener acceso a la sal utilizada para generar un valor de hash ayuda sustancialmente a un ataque de fuerza bruta en el descubrimiento de la contraseña real?
  2. Si es así, ¿por lo tanto tiene sentido que los hackers tengan que robar mi código además de los datos en sí?
  3. ¿Es el enfoque general de generar dinámicamente la sal (utilizando medios reproducibles, no aleatorios, pero no presumibles) desaconsejable?
pregunta jmar777 15.09.2011 - 17:16
fuente

3 respuestas

15

Estás un poco equivocado sobre el papel de la sal. No se supone que no sea "indiscutible por el atacante". Si estuviera destinado a ser indiscutible, sería un dato confidencial y lo llamaríamos "clave", no "sal".

La sal está ahí para hacer que el proceso de derivación de la contraseña sea único, a fin de evitar que un atacante haga economías de escala al atacar varias contraseñas. Si el atacante intenta adivinar tres contraseñas, debe costarle tres veces más que atacar una. Un gran ejemplo de "economía de escala" es una gran tabla de hashes precomputados para contraseñas comunes (o su descendencia malvada, la tabla de arco iris , que es solo una enorme tabla precomputada con un truco para mantenerla simplemente enorme). En presencia de una sal, no hay un función hash, sino uno por valor de sal ; o, dicho de otro modo, una tabla precomputada sería específica para un determinado salt (el que se usó durante el cálculo) y no tendría valor para atacar cualquier contraseña que no use ese salt.

Por supuesto, si un atacante podría obtener una copia de las contraseñas con hash pero no las sales correspondientes, su tarea se vuelve muy difícil. Pero este no es un escenario plausible: si tiene un área de almacenamiento donde puede poner las sales fuera del alcance del atacante, ¿por qué no almacenó las contraseñas de hash allí también? Así que el análisis de seguridad asume que las sales son conocidas por el atacante. Su utilidad radica en su singularidad: no hay dos contraseñas hash distintas, en el mismo sistema o en diferentes, en el mismo o diferente momento, tienen el mismo valor de sal (ni siquiera dos contraseñas sucesivas para el mismo usuario: cuando cambia la contraseña, también cambiar la sal).

Puede generar y almacenar sales de cualquier forma que considere conveniente, incluso con un "generador dinámico", siempre que la probabilidad de reutilizar un valor de sal sea despreciable. Esto es precisamente porque se supone que deben ser públicos y el atacante no tiene que ser "indiscutible". Las cosas indiscutibles requieren artillería pesada .

Hay un concepto ligeramente relacionado que a veces se llama "pimienta": una clave secreta que se también se inserta en el proceso de hashing (consulte esta pregunta anterior ). Esa clave se comparte en todo el sistema. La idea sería que una clave única sea más fácil de mantener confidencial que una base de datos completa de contraseñas con hash, al menos en algunas configuraciones (por ejemplo, la mantiene en un archivo de configuración privado, no en la base de datos SQL). El concepto de "pimienta" implica una administración más compleja (una cosa más para respaldar y no perder, o compartir entre servidores front-end) y vale nada solo en el escenario marginal donde un atacante puede volcar la base de datos del usuario pero el sistema host completo. En cualquier caso, el "pimiento" no se da cuenta de la propiedad de singularidad que proporciona la sal, por lo que el pimiento no debe reemplazar la sal, solo es posible que lo complemente .

    
respondido por el Thomas Pornin 16.09.2011 - 01:23
fuente
3

Esto fue un poco largo para comentarios.

La sal sí les da un punto de partida.

Sin embargo, normalmente es un problema discutible ya que el valor de saber una contraseña en particular casi siempre está relacionado solo con el número total de contraseñas que pueden revertir de su tabla de usuarios. En otras palabras, si tienen que gastar literalmente años de tiempo en la computadora para extraer, por ejemplo, 10 contraseñas, los datos en efecto no tienen valor.

El levantamiento de nombres de usuario y contraseñas de un sitio solo tiene valor porque los usuarios tienden a reutilizar la misma contraseña en múltiples servicios. Obviamente, no es importante para un pirata informático iniciar sesión como usuario en el mismo sitio desde el que obtuvieron la contraseña porque si pudieron obtener las contraseñas de usted, entonces es muy probable que también puedan extraer cualquier otra información que deseen.

Al vender esos nombres de usuario y contraseñas tienen valor porque esas claves podrían abrir otros bloqueos, como cuentas de Facebook y sitios bancarios. La única otra situación en la que tienen valor es en avergonzarte públicamente al publicar los nombres de usuario / contraseñas en un foro público, como Sony.

Por lo tanto, si está utilizando un salt aleatorio por contraseña, ya está aumentando el tiempo que toma obtener algo de valor hasta el punto de estupidez. Además, las personas con los recursos necesarios para descifrar todas esas contraseñas en un tiempo razonable son, probablemente, agencias gubernamentales ... lo que es un problema completamente diferente.

Lo que me lleva a mi voto: encuentra un problema diferente para resolver.

    
respondido por el NotMe 15.09.2011 - 19:07
fuente
-1

Una importante ley de seguridad es "deja de intentar hacer tu propio criptografía". Deje de crear sus propios sistemas de autenticación y solo use los sistemas estándar. No hay nada particularmente malo en lo que propones, pero al preguntar, demuestras que no entiendes completamente el problema. Es como ver a un carpintero martillar un clavo con una llave. No es tanto que no funcione como el hecho de que desconfiarías de su competencia.

Si quieres hacer la vida más difícil para los piratas informáticos, haz el cambio más pequeño posible.

Simplifiquemos su pregunta: ¿qué puedo hacer para que sea más difícil descifrar las contraseñas? ¿Forzarlos a robar el código fuente ayuda?

Por ejemplo, usar SHA-2 hace que sea más difícil para los hackers. Sus herramientas están optimizadas para SHA-1 y MD5, y muchas herramientas no funcionan con SHA-2.

O, si realmente quiere un secreto en el código fuente, las cosas complejas que sugiere no mejorarán la situación más que simplemente agregar "x" al valor de sal. De esa manera, el hacker podría robar las sales y los hashes, pero no podría hacer mucho con ellos sin saber el código fuente.

Recuerde que algunos programadores lo perseguirán y tendrán que mantener su código. Si es un sistema extraño, se van a arrancar el cabello con frustración. Si es el sistema de autenticación normal o un sistema normal con un cambio menor, entonces no maldecirán tu nombre.

    
respondido por el Robert David Graham 21.09.2011 - 18:45
fuente

Lea otras preguntas en las etiquetas