Seguridad de contraseña: cifrado de sal [duplicado]

Question

Seguridad de contraseña: cifrado de sal [duplicado]

#1 de Eric Fleischman (0 votos)
#2 de Maarten Bodewes (0 votos)
#3 de ChrisF (-1 votos)

2

Soy nuevo en seguridad y trato de entender por qué no se considera útil encriptar u ocultar un salt. He leído la publicación anterior enlace sobre por qué ocultar o cifrar la sal no es necesario, pero la respuesta se basó en la suposición

Si alguien tiene acceso a su base de datos, entonces tiene acceso a la Sales encriptadas, y probablemente también tengan acceso a su código

Pregunta

Solo porque un atacante tiene acceso a su base de datos, ¿por qué debemos asumir que tiene acceso al código que interactúa con él? Por ejemplo, tiene sus contraseñas con sal en un servidor MySQL en una máquina junto con las sales encriptadas. Y tiene la clave para descifrar las sales o alguna intrincada lógica de cifrado / descifrado en un servidor web en una máquina separada. Un atacante obtiene acceso a la base de datos a través de inyección SQL o por algún otro medio. ¿No ha guardado el cifrado y la arquitectura distribuida el día aquí?

hash salt encryption

pregunta Usman Mutawakil 24.10.2012 - 17:53

fuente

3 respuestas

Lea otras preguntas en las etiquetas hash salt encryption

¿Puede mi administrador de red examinar los archivos que subo en un sitio HTTPS? [duplicar] ¿Qué pasará con mi PC con Windows si visito un sitio desde una red marcada como maliciosa por google safebrowsing [cerrado]

score 0 · Answer 1

Escuchará diferentes argumentos aquí pero, al final del día, todo se reduce a cómo funciona su sistema en el mundo real.

Ciertamente, es posible construir un sistema en el que el compromiso del nivel de la base de datos no produzca el compromiso del nivel de la aplicación. Podrías imaginarte endurecer contra cosas como:

La inyección de datos arbitrarios desde la capa db no causa un problema de seguridad en el extremo frontal (es decir, supone que obtendrá datos incorrectos)
El acceso físico al nivel de db no implica acceso físico al nivel de aplicación.
Los servicios de infraestructura (credenciales de administrador, servicios compartidos para cosas como la administración de parches, etc.) están aislados, de modo que no hay manera de cruzar la isla.
La capacidad de insertar código en el nivel de db no implica la capacidad de insertar código en el nivel de aplicación.

... y así sucesivamente.

Así que sí, podría hacerse. Pragmáticamente, muy pocas aplicaciones funcionan de esta manera. He visto muy pocos en mi carrera que honestamente podrían decir que han logrado esto.

OMI, esta es la razón por la que las personas tienden a no ver esto como muy valioso, ya que muy pocas aplicaciones pueden hacer este tipo de reclamo de seguridad.

score 0 · Answer 2

Encriptar sales no es muy útil, ya que necesitarías almacenar la clave en algún lugar . La mayoría de las veces, la clave (o el acceso a la clave) se puede recuperar del código. En general, cada vez que piense en un protocolo que utiliza cifrado debe especificar cómo se accede a las claves. Si no tiene una respuesta directa a eso, es probable que se encuentre en un nuevo diseño.

En vez de eso, podrías recuperar la sal de un secreto almacenado en el código y una parte puramente aleatoria almacenada en la base de datos. Como no hay límite de tamaño para una sal, simplemente puede concatenar las partes para obtener la sal completa. Esto puede ser útil ya que el atacante ahora también tiene que obtener acceso al código. Por supuesto, el código no debería estar disponible para el atacante. La razón por la que esto no se implementa mucho es que la mayoría de las veces el acceso a la base de datos es igual al acceso al código.

score -1 · Answer 3

Si el atacante encuentra las contraseñas (y las sales) utilizando una vulnerabilidad de inyección de SQL, solo tiene acceso a la información a la que tiene acceso la base de datos. En este caso, no importa si el código está en la misma máquina que la base de datos, ya que la base de datos en general no puede acceder al código que se conecta a ella.

La situación es diferente cuando el atacante ha obtenido acceso a la máquina que ejecuta la base de datos, en este caso probablemente podrá acceder tanto a la base de datos como al código (si el código está en la misma máquina).

Entonces, si el servidor web y la base de datos se ejecutan en máquinas separadas, y el atacante solo tiene acceso a través de una vulnerabilidad de inyección de SQL, de hecho le será muy difícil descifrar esas contraseñas.