¿Dónde guardas tus cuerdas de sal?

Daré una opinión ligeramente diferente sobre esto.

Siempre almaceno la sal mezclada con el hash salted-password.

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

Mi justificación para este enfoque:

Si el los datos de contraseña / hash se ven comprometidos y caen en manos de un atacante, el atacante no sabrá qué es la sal al 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 no conoce el hash para empezar y no tiene forma de saber qué partes de los datos son partes de la sal o partes del hash de la contraseña salada (a menos que conozca la autenticación de su aplicación lógica).

Si el hash salted-password se almacena tal cual, entonces se puede realizar un ataque de fuerza bruta para obtener una contraseña que cuando salted y hash produce los mismos datos que el hash salted-password.

Sin embargo, por ejemplo, incluso si el hash salted-password se almacena tal cual, pero pre-colgado con un solo byte aleatorio, siempre y cuando el atacante no sepa que este primer byte debe ser descartado, esto también aumentaría la dificultad del ataque. Su aplicación sepa descartar el primer byte de los datos cuando se use para autenticar a su usuario.

La conclusión de esto..

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

2) Si es posible, mantenga su lógica de autenticación en secreto 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, mucha gente sabe cómo se almacenan sus datos en la base de datos. Y supongamos que ha decidido almacenar el hash de contraseña salada mezclado con la sal, con parte de la sal anteponiendo el hash de contraseña salada, y el resto de la sal agregándolo.

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

Por ejemplo, se genera una sal aleatoria de 512 bytes. Agregas la sal a tu contraseña, y obtienes el hash SHA-512 de tu salado-contraseña. También genera un entero aleatorio 200. A continuación, almacena los primeros 200 bytes de la sal, seguidos por el hash salted-password, seguido por el resto de la sal.

Al autenticar la entrada de contraseña de un usuario, su aplicación pasará la cadena y asumirá que el primer 1 byte de los datos es el primer 1 byte de la sal, seguido por el hash salado. Este pase fallará. La aplicación continuará utilizando los primeros 2 bytes de los datos como los primeros 2 bytes de la sal, y repita 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 su lógica de autenticación es conocida, la lógica exacta es desconocida en tiempo de 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á aún más la seguridad.

Los contras de este enfoque:

Dado que la lógica exacta se infiere en tiempo de ejecución, este enfoque es muy intensivo en CPU. Cuanto más larga sea la longitud de la sal, más intensivo será este enfoque.

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

Este enfoque puede ser implementado de varias maneras, y se puede hacer aún más seguro mediante el uso de sales de ancho variable y / o hashes de contraseñas saladas.

A menudo, se anteponen al hash y se almacenan en el mismo campo.

No hay necesidad de almacenarlos por separado - el punto es usar una sal aleatoria para cada contraseña para que una sola tabla rainbow no se pueda usar contra todo su conjunto de hashes de contraseñas. Con sales aleatorias, un atacante debe forzar brutalmente cada hash por separado (o calcular una tabla rainbow para todas las sales posibles - mucho más trabajo).

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

Basado en el Desarrollo ASP.NET MVC 4 Aplicaciones Web libro de William Penberthy:

1. Obtener acceso a las sales almacenadas en una base de datos separada requiere que los hackers pirateen dos diferentes bases de datos para obtener acceso a la sal y la contraseña salada. Almacenarlos en la misma tabla que la contraseña, o incluso otra tabla de la misma base de datos, significa que cuando los hackers obtienen acceso a la base de datos, tendrán acceso tanto a la salt y el hash de contraseña. Porque la seguridad incluye el proceso de hacer hacking en el sistema demasiado caro o consume mucho tiempo para valer la pena, duplicando la cantidad de acceso un hacker tendría que ganar debe hacer el sistema más seguro.
2. La facilidad de uso es la razón principal para mantener las sales en la misma base de datos que el contraseñas con hash. No tendría que asegurarse de que dos bases de datos estén siempre disponibles al mismo tiempo, y siempre en sincronía. La ventaja de tener una sal es mínima si cada usuario tiene una sal aleatoria porque aunque podría hacer el descubrimiento de un individuo contraseña más fácil, la cantidad de fuerza necesaria para descifrar las contraseñas de la el sistema en general será alto. En este nivel de discusión, eso es realmente lo que la expectativa es: para proteger las contraseñas. Si los hackers han adquirido una copia de la base de datos, su los datos de la aplicación ya están comprometidos. En este punto, el problema es mitigar los riesgos debido al potencial de las contraseñas compartidas.
3. El requisito de mantener dos separado vinculado, bases de datos es extensa. Concedido, it añade la percepción de seguridad, pero la única ventaja que da es que protege una contraseña, un único elemento de datos. Si cada campo de la base de datos fuera individual encriptado, y esta misma sal se usó para eso, tendría más sentido almacenarlo por separado de los datos porque la seguridad básica de su sistema está mejorada.