¿Es útil proteger la contraseña con hash con cifrado?

¿Cuál es el modelo de amenaza? podría ser beneficioso proteger el almacenamiento de contraseñas con un secreto del lado de la aplicación, pero solo si cree que es un escenario realista que su base de datos se verá comprometida, sin su servidor de aplicaciones, que contiene el secreto, también habiendo sido comprometido.

Generalmente, la capa de aplicación se considera la parte más vulnerable y la capa de base de datos más protegida, y por esta razón no se considera útil proteger los datos con un secreto del lado de la aplicación. Pero puede que ese no sea el caso de todas las aplicaciones y, personalmente, cuestionaría este supuesto dado el predominio de la inyección de SQL.

El inconveniente de introducir un secreto del lado de la aplicación es que ahora tiene que preocuparse por los procesos de administración clave. ¿Cuál es su mecanismo para reemplazar la llave si se compromete? ¿Lo vas a rotar como cuestión de rutina? ¿Cómo se almacena su clave para poder mover servidores y no perderla (haciendo que todos sus datos sean inútiles)? Es posible que no le importe para las claves de corta duración (utilizadas para, por ejemplo, firmar tokens de sesión), pero para el almacenamiento de contraseñas a largo plazo se vuelve importante.

La desventaja adicional con los cifrados simétricos (especialmente los cifrados en bloque) es implementarlos correctamente. Dado que está haciendo hash y no necesita recuperabilidad, podría incluir el secreto en el hash (como un 'pimiento') ... pero no podría volver a hacer hash de todos los datos de la contraseña en un cambio clave. , por lo que tendrías que tener un método de clave múltiple para la transferencia.

ETA re comentario @Pacerier:

Hashing no evita un ataque de adivinación fuera de línea por parte de alguien que haya obtenido la base de datos de contraseñas. Solo aumenta la cantidad de tiempo que toma ese ataque para dar frutos; con un esquema de hashing de dificultad apropiada (es decir, rondas de derivación clave en lugar de longitud de sal bruta per se), es de esperar que aumente esa cantidad de tiempo lo suficiente como para que note que ha sido hackeado y que cambie las contraseñas de todos antes de muchas sus cuentas se pierden.

La protección del contenido con una clave secreta (ya sea mediante el cifrado o la inclusión de la clave secreta en el material con hash) evita el ataque de adivinación fuera de línea, pero solo mientras la clave secreta no se filtre. Si la clave secreta está en el servidor de la aplicación por separado del servidor de la base de datos, las contraseñas solo se pueden atacar si ambas máquinas están comprometidas.

¿Cuánto de un beneficio es discutible, dado que muchos tipos de ataques pueden terminar comprometiendo a ambos, especialmente si el servidor de aplicaciones y el servidor de bases de datos son la misma máquina? También hay un precio a pagar en la capacidad de administración según lo discutido. Por lo tanto, si existe un beneficio neto debe evaluarse caso por caso con referencia al modelo de amenaza.

Soy un gran fanático de agregar capas de protección sobre un sistema seguro como parte de una defense en profundidad política. Sin embargo, en este caso particular, el uso del cifrado simétrico para esta tarea crea otro problema en el sistema; Tendrá que hacerse cargo de la gestión de claves. La clave debe estar almacenada en algún lugar, y si su aplicación tiene acceso a ella, entonces un atacante que comprometió su sistema muy probablemente tendrá acceso a la clave.

Este procedimiento agrega complejidad adicional al sistema. La complejidad es uno de los enemigos de la seguridad. Aconsejo altamente no hacerlo.

El cifrado de los hashes de contraseña puede proteger las contraseñas en una situación muy específica.

Hay situaciones en las que un atacante obtiene acceso de lectura a su base de datos, la inyección de SQL es una posibilidad, una copia de seguridad con fugas o un servidor desechado. En este caso, puede forzar con fuerza bruta los hashes de contraseña. Con un algoritmo hash apropiado (función de derivación de clave), las contraseñas seguras serán seguras, aunque las contraseñas débiles se pueden recuperar más o menos rápido con un ataque de diccionario (pruebe las 1000 contraseñas más utilizadas ...).

Al cifrar sus hashes de contraseña, agrega un secreto del lado del servidor a sus hashes. Eso significa que, además de la base de datos, un atacante necesita ahora privilegios en el servidor (para obtener la clave). Esta es la misma ventaja que un pimiento puede darte, pero tiene la ventaja de que puedes intercambiar la clave siempre que sea necesario.

Si la clave se almacena de forma segura no es tan importante, son importantes los privilegios adicionales que necesita el atacante. En el peor de los casos, el atacante obtendrá los hashes de contraseña y tendrá la misma situación que sin cifrado.

Creo que hay un caso para cifrar un resumen seguro.

Parece generalmente aceptado que la mejor práctica hoy es utilizar bcrypt, PBKDF2 o Algoritmos similares a Salt y aplicar un factor de trabajo a la generación de la contraseña. digerir. El uso de un pimiento es también una excelente manera de mitigar la mala o bien conocida. las contraseñas no se pueden forzar fácilmente, independientemente del algoritmo / factor de trabajo que se esté utilizando.

Sin embargo, el uso de algoritmos lentos requiere que el factor de trabajo se actualice como hardware el rendimiento mejora y debe elegirse para mitigar los ataques de fuerza bruta pero no de forma indebida verificación lenta de la contraseña para los usuarios que inician sesión en su sistema. Mediante el uso de cifrado simétrico de un hash de contraseña, ya no se requieren los requisitos de carga de trabajo y pimienta. Previsto la clave simétrica está bien protegida (utilizando un HSM, por ejemplo) y una buena gestión de claves Se han establecido procesos. No puedo ver un inconveniente para este enfoque. La dificultad de un ataque de fuerza bruta es lo mismo que la fuerza bruta forzando la clave independientemente de si el La contraseña es de buena calidad o no.

Ciertamente no crearía la infraestructura para hacer esto como todos los comentarios anteriores con respecto a la administración de claves y mantener la clave separada del servidor de aplicaciones aplicaría. Pero si la infraestructura ya está en su lugar y bien establecida ciertamente hay algunos aspectos positivos para cifrar un hash de contraseña con sal.

Yo diría que no. Por las razones que Adnan ha dicho, la clave debe ser accesible y, por lo tanto, este paso es simplemente agregar complejidad al sistema, que es innecesario.

Un mejor enfoque de la OMI sería ver el cifrado como la informática que podría pagar, pero no usó, y considerar si podría utilizar esa informática para un enfoque de hashing diferente.

Hay una idea errónea de que la combinación de diferentes prácticas de criptografía da como resultado algo más seguro que cualquier práctica individual por sí sola. Sin embargo, ese es raramente el caso.

El cifrado de contraseñas correctamente implementado con una sal larga es criptográficamente seguro. El propósito de las contraseñas de hashing y salado es proteger los datos en reposo. Lo que significa que nadie que obtenga una retención de su base de datos de contraseñas debe saber cuáles son las contraseñas e incluso si logran descifrar una o más contraseñas que no deberían dar ninguna ventaja al descifrar otra.

Como Adobe nos ha mostrado en las últimas semanas, los cifrados de bloques simétricos no son muy buenos en esta tarea. El hash con sal evita este problema por completo.

Otros han señalado que el cifrado adicional de sus contraseñas con hash introduce el problema de la administración de claves y no ofrece ninguna seguridad / robustez adicional para los datos almacenados. El cifrado es bueno para garantizar que solo aquellos con las credenciales adecuadas puedan acceder a los datos. El cifrado es reversible por esta razón. Este no es un paradigma de autenticación.

Cuando nos autenticamos queremos que el servidor use algo que sabe (el salt) y un secreto que solo su usuario conoce (la contraseña) para generar de manera consistente el mismo blob de datos único. Sabemos que el usuario es quien dice ser porque podemos reproducir este blob gigante una y otra vez. La sal garantiza que incluso dos contraseñas idénticas no tengan el mismo hash en la base de datos. El cifrado adicional tampoco ofrece ayuda en ese frente.