Almacenamiento de contraseñas hash: iteraciones vs entropía [duplicado]

Suponga que su sistema está completamente comprometido. Un atacante tiene todos tus pimientos, todas las sales requeridas y el conocimiento de cómo los estás combinando. Esta es la situación equivalente para un atacante que obtiene una tabla de contraseñas cifradas.

En este punto, para su esquema, romper contraseñas es rápido. SHA-512 se puede calcular en millones de hashes por segundo. Para el consejo general actual, bcrypt, romper contraseñas sigue siendo lento. Al ajustarlo, el hardware estándar podría limitarse a 100 segundos por segundo, y el hardware especializado solo dará 10.000 segundos por segundo.

Ahora, si puede estar absolutamente seguro de que nadie puede robar sus datos de pimienta, está bien. Sin embargo, si los pierde, sus contraseñas se vuelven casi instantáneamente vulnerables: el hash rápido permite que un atacante intente contraseñas comunes con facilidad. Por otro lado, las iteraciones no tienen ese problema.

Las iteraciones también son fáciles de implementar: una función, generalmente integrada,. Es un esfuerzo muy pequeño para los desarrolladores, lo que facilita su implementación correcta. Por otro lado, su esquema requiere código hashing en múltiples lugares, en diferentes servidores. Debe asegurarse de que los hashes intermedios no estén expuestos en ningún momento. Debe asegurarse de que el código en cada capa sea correcto. Es posible que necesite ejecutar software adicional en algunos sistemas (¿el DBMS es compatible de forma nativa con el método de hash?). Hay muchas partes móviles. Es mucho más fácil cometer un error en alguna parte.

En resumen, las iteraciones conservan la seguridad en caso de un compromiso total y son más fáciles de desarrollar. En un mundo ideal, el chile multicapa ayudaría contra el modo de falla donde la base de datos está comprometida, y ningún otro sistema lo está. Sería adecuado para agregar a un sistema con altos requisitos de seguridad, además de usar hashing lento (iteración alta), pero no en su lugar, a menos que tenga plena confianza de que los pimientos nunca se pueden comprometer.

Un código de autenticación de mensaje con una clave secreta que no está disponible para el atacante efectivamente resistirá muchos ataques que el hash de contraseña de uso intensivo de recursos no hará. No hay duda allí. Ni siquiera necesita la arquitectura de clave de tres niveles excesivamente compleja; solo una clave secreta de 128 bits sería suficiente.

(Nota al margen: resalto "código de autenticación de mensaje" porque esa es la construcción criptográfica adecuada para su propuesta. Su "SHA512 (contraseña + secreto)" revela que no sabe qué estructura es apropiada para lo que usted dice. he propuesto; HMAC-SHA512 (clave, contraseña) sería la mejor opción.)

Pero aquí está el tema grande y difícil que su pregunta elude por completo: ¿cómo protege esas claves secretas? Usted dice esto:

  

Por supuesto, la implementación debería ser segura (hecha a mano frente a scrypt más estándar) y los secretos deben permanecer desconocidos.

... pero esos dos son precisamente en los que los laicos que intentan implementar su propuesta fallarán, una y otra vez. Ya tiene un crypto cuestionable en su propuesta (hash con clave enrollada a mano en lugar de HMAC, tres capas de cómputo de MAC cuando solo una haría), y dice nada sobre cómo se asegurará de que sus claves secretas no No se revele, ¡este es el punto en el que se basa la seguridad del esquema!

  

Además, si se revela un secreto y se debe cambiar, el proceso de actualización sería una molestia.

Esto se puede resolver con un método hash-then-encrypt, como Dropbox ha adoptado (sin embargo, con bcrypt). El equivalente en su enfoque de no iteraciones sería algo como encrypt(key, hash(password)) , o (apenas) mejor encrypt(key, hmac(salt, password)) , lo que le permitiría volver a codificar los hashes cifrados.

  

No veo que tal esquema sea implementado en la producción muy a menudo, sin embargo, en general, el consenso es "iteraciones + sal o avergonzarse", así que tal vez me esté faltando algo.

El almacenamiento inseguro de claves secretas a largo plazo es muy, muy común, y casi todos los que sugieren usar un pimiento no han pensado realmente en el problema de la gestión de claves. Esto es lo que hace que los esquemas sin llave, como el hashing de contraseñas con uso intensivo de recursos, sean tan valiosos y una recomendación tan fuerte; Si podemos evitar o reducir la dependencia de las claves secretas, eso es generalmente una ventaja. Básicamente, la administración de claves es difícil , por lo que cuantas menos claves criptográficas a largo plazo debamos almacenar y defender mejor, y cuanto más podamos mitigar las consecuencias del fracaso, también mejor.

Por lo tanto, las claves secretas solo deben considerarse para el hashing de contraseñas después de:

1. Ha adoptado el hashing de contraseña con uso intensivo de recursos, que sirve al menos como una línea de defensa alternativa si se revelan las claves.
2. Tiene un sistema bien pensado y bien diseñado para proteger y administrar las claves secretas de sus sistemas, idealmente una donde las claves se almacenan en solo uno sistema de administración de claves seguro cuyo único propósito es almacenar claves secretas a largo plazo y nunca filtrarlas a ningún sistema externo. Un KMS no debe revelar las claves ni siquiera a sus clientes, quienes, en cambio, deben recurrir a pedirle al KMS que realice operaciones criptográficas en su nombre. Algunos ejemplos:
   • Un módulo de seguridad de hardware
   • Herramientas secretas de administración como Amazon KMS o HashiCorp Vault 's Backend de Transit .