security - que - ¿Dónde almacena sus cadenas de sal?

que es salt en criptografia

Question

Siempre he usado una cadena adecuada de sal por entrada cuando hash las contraseñas para el almacenamiento de la base de datos. Para mis necesidades, almacenar la sal en la base de datos junto a la contraseña hash siempre ha funcionado bien.

Sin embargo, algunas personas recomiendan que la sal se almacene por separado de la base de datos. Su argumento es que si la base de datos está comprometida, un atacante aún puede construir una tabla de arco iris teniendo en cuenta una cadena de sal en particular para romper una cuenta a la vez. Si esta cuenta tiene privilegios de administrador, es posible que ni siquiera necesite descifrar otros.

Desde una perspectiva de seguridad, ¿vale la pena almacenar sales en un lugar diferente? Considere una aplicación web con el código del servidor y la base de datos en la misma máquina. Si las sales se almacenan en un archivo plano en esa máquina, es probable que si la base de datos está comprometida, el archivo de sales también lo estará.

¿Hay alguna solución recomendada para esto?

Answer 1

A menudo, se añaden al hash y se almacenan en el mismo campo.

No hay necesidad de almacenarlos por separado: el punto es usar un salt aleatorio para cada contraseña, de modo que una sola tabla de arco iris no se pueda usar contra todo su conjunto de hashes de contraseña. Con sales aleatorias, un atacante debe forzar con fuerza bruta cada hash por separado (o calcular una tabla de arco iris para todas las sales posibles, mucho más trabajo).

Si tuviera una ubicación de almacenamiento más segura, tendría sentido simplemente almacenar los hashes allí.

Answer 2

Basado en el libro Developing ASP.NET MVC 4 Web Applications de William Penberthy:

1. Obtener acceso a las sales almacenadas en una base de datos separada requiere que los piratas informáticos pirateen dos bases de datos diferentes para obtener acceso a la sal y la contraseña con sal. Almacenarlos en la misma tabla que la contraseña, o incluso en otra tabla de la misma base de datos, significaría que cuando los piratas informáticos obtengan acceso a la base de datos, tendrán acceso tanto al salt como al hash de la contraseña. Debido a que la seguridad incluye el proceso de hacer que el pirateo en el sistema sea demasiado costoso o lento para que valga la pena, duplicar la cantidad de acceso que un pirata informático tendría que obtener debería hacer que el sistema sea más seguro.
2. La facilidad de uso es la razón principal para mantener las sales en la misma base de datos que las contraseñas de hash. No tendría que asegurarse de que dos bases de datos estén siempre disponibles al mismo tiempo y siempre sincronizadas. La ventaja de tener una sal es mínima si cada usuario tiene una sal aleatoria porque, aunque podría facilitar el descubrimiento de la contraseña de un individuo, la cantidad de fuerza necesaria para descifrar las contraseñas del sistema en general será alta. En este nivel de discusión, eso es realmente lo que se espera: proteger las contraseñas. Si los hackers han adquirido una copia de la base de datos, los datos de su aplicación ya están comprometidos. En este punto, el problema es mitigar los riesgos de los usuarios debido al potencial de las contraseñas compartidas.
3. El requisito de mantener dos bases de datos vinculadas separadas es extenso. Por supuesto, agrega la percepción de seguridad, pero la única ventaja que brinda es que protege una contraseña, un solo elemento de datos. Si todos los campos de la base de datos estuvieran cifrados individualmente, y este mismo sal se utilizara para eso, tendría más sentido almacenarlo por separado de los datos porque se mejora la seguridad básica de su sistema.

Answer 3

El punto de las tablas del arco iris es que se crearon de antemano y se distribuyeron en masa para ahorrar tiempo de cálculo para los demás. Se necesita tanto tiempo para generar tablas del arco iris sobre la marcha como lo sería simplemente descifrar la combinación de contraseña y sal directamente (ya que efectivamente, lo que se está haciendo al generar tablas de arco iris es la ejecución previa de los cálculos para forzar brutalmente el hash), por lo tanto, el argumento de que al saber la sal que alguien podría "generar una tabla de arco iris" es falso.

No hay un punto real en el almacenamiento de sales en un archivo separado, siempre que estén en una base por usuario; el objetivo de la sal es simplemente hacer que una tabla de arco iris no pueda romper todas las contraseñas en la base de datos.

Answer 4

Proporcionaré una versión ligeramente diferente de esto.

Siempre almaceno la sal mezclada con el hash de contraseña salada.

Por ejemplo, colocaré la primera mitad de la sal antes del hash con sal de la contraseña, y la última mitad de la sal después del hash con sal de la contraseña. La aplicación es consciente de este diseño, por lo que puede obtener estos datos y obtener el hash de sal y contraseña con sal.

Mi razonamiento para este enfoque:

Si los datos de la contraseña / hash están comprometidos y caen en manos de un atacante, el atacante no sabrá de qué se trata el hecho de mirar los datos. De esta manera, un atacante prácticamente no puede realizar un ataque de fuerza bruta para obtener una contraseña que coincida con el hash, ya que, para empezar, no conoce el hash y no tiene forma de saber qué partes de los datos forman parte de la sal, o partes del hash de contraseña con sal (a menos que conozca la lógica de autenticación de su aplicación ).

Si el hash de contraseña con sal se almacena tal como está, entonces se puede realizar un ataque de fuerza bruta para obtener una contraseña que, cuando se sala y hash, produce los mismos datos que el hash de contraseña con sal.

Sin embargo, por ejemplo, incluso si el hash de contraseña con sal se almacenó tal como está, pero se suspendió con un solo byte aleatorio, siempre que el atacante no sepa que se debe descartar este primer byte, esto también aumentaría la dificultad. de ataque. Su aplicación sabría descartar el primer byte de los datos cuando se utiliza para autenticar a su usuario.

La conclusión a esto ..

1) Nunca almacene los datos que utiliza su aplicación de autenticación en su forma exacta.

2) Si es posible, mantenga en secreto su lógica de autenticación para mayor seguridad.

Vaya un paso más allá ..

Si no puede mantener en secreto la lógica de autenticación de su aplicación, muchas personas saben cómo se almacenan sus datos en la base de datos. Y supongamos que ha decidido almacenar el hash de contraseña con sal mezclado con la sal, con parte de la sal ante el hash de contraseña con sal, y el resto de la sal agregándolo.

Al generar la sal aleatoria, también podría decidir qué proporción de su sal almacenará antes / después del hash de contraseña salada.

Por ejemplo, generas una sal aleatoria de 512 bytes. Usted agrega la sal a su contraseña y obtiene el hash SHA-512 de su contraseña con sal. También genera un entero 200 aleatorio. A continuación, almacena los primeros 200 bytes de la sal, seguido del hash de contraseña con sal, seguido del resto de la sal.

Al autenticar la entrada de la contraseña de un usuario, su aplicación pasará sobre la cadena y asumirá que el primer byte de los datos es el primer byte de la sal, seguido del hash con sal. Este pase fallará. La aplicación continuará utilizando los primeros 2 bytes de los datos como los primeros 2 bytes de la sal, y se repetirá hasta que se encuentre un resultado positivo después de usar los primeros 200 bytes como los primeros 200 bytes de la sal. Si la contraseña es incorrecta, la aplicación continuará probando todas las permutaciones hasta que no se encuentre ninguna.

Los pros de este enfoque:

Mayor seguridad: incluso si se conoce su lógica de autenticación, la lógica exacta se desconoce en el momento de la compilación. Es prácticamente imposible realizar un ataque de fuerza bruta, incluso con el conocimiento de la lógica exacta. El aumento de la longitud de la sal aumentará la seguridad aún más.

Los contras de este enfoque:

Dado que la lógica exacta se infiere en tiempo de ejecución, este enfoque requiere un gran uso de la CPU. Cuanto más larga es la longitud de la sal, más se requiere este uso de CPU.

Autenticar contraseñas incorrectas implicará el mayor costo de la CPU. Esto puede ser contraproducente para las solicitudes legítimas, pero aumenta la seguridad contra los atacantes.

Este enfoque se puede implementar de varias maneras y se puede hacer aún más seguro usando sales de ancho variable y / o hashes de contraseña con sal.