Almacenamiento de contraseñas - ¿Auto cifrado frente a hash?

Lo que estás haciendo aquí es, de hecho, definir una función hash: dada una función de cifrado Cifrar (K, M) donde K es la clave y M es el texto plano para cifrar, tú defines Hash (P) = Encrypt (P, PAG). Así que estás inventando una nueva función criptográfica.

Primero, para el hashing de contraseñas, no necesitas ninguna función hash antigua, ya que debe ser resistente al intento de craqueo de fuerza bruta, donde el atacante adivina cuál podría ser la contraseña, calcula Hash (adivina) y compara el resultado con el hash almacenado. Cualquiera que sea el algoritmo de hash que hagas, debes reforzarlo para incluir sal (para que los atacantes tengan que descifrar cada hash individualmente en lugar de ir a todas las cuentas a la vez y hacer que caigan las contraseñas más débiles) y hacer que la función del hash sea lenta (porque eso duele). el atacante, que necesita hacer muchas suposiciones erróneas, más que el defensor, que en su mayoría verificará los intentos correctos). Consulte ¿Cómo hash seguro de contraseñas? para obtener una explicación más detallada.

Puede crear una función hash lenta, salada a partir de una función hash normal, con una construcción como SSH (P, S) = Hash (Hash (... Hash (P + S)…)) (donde P + S es concatenación ). Esta no es necesariamente la mejor manera de hacerlo; por ejemplo, una buena función de hash de contraseñas para usos típicos debería requerir mucha memoria, ya que los servidores tienen mucha más memoria que el hardware especializado para descifrar contraseñas. Pero es un buen comienzo.

El problema sigue siendo si Hash (P) = Encrypt (P, P) es una buena función de hash. Esto no es automático; tenga en cuenta que algunos análisis de la seguridad de los algoritmos criptográficos se basan en que la clave y el texto en claro sean independientes.

Una de las principales dificultades es que el tamaño de la clave en la mayoría de los algoritmos de cifrado está muy limitado, a menudo constante. Por ejemplo, el algoritmo de cifrado estándar AES solo acepta tres tamaños de clave (8, 12 o 16 bytes). Si la contraseña (más sal) es demasiado corta, puede rellenarla con un carácter no válido, pero ¿qué puede hacer si es demasiado larga? La forma habitual de usar una clave basada en un material que es más largo que el tamaño de la clave es ... para aplicar una función hash (que acepta una longitud de entrada arbitraria) al material.

Si desea derivar una función hash a partir de un algoritmo de cifrado, en realidad hay una forma más simple: en lugar de Hash (P) = Encrypt (P, P), defina Hash (P) = Encrypt (P, 0), es decir cifre un bloque de texto sin formato de todos los ceros (o algún otro bloque de texto sin formato conocido). Eso es lo que hizo la función de hashing de contraseña original de Unix . La ventaja de este enfoque sobre Cifrado (P, P) es que puede beneficiarse de los análisis existentes del algoritmo: los algoritmos de cifrado están diseñados para resistir ataques de texto simple conocido. La limitación con la contraseña y el tamaño de sal permanece.

Pensamiento muy interesante.

Pero tenemos un problema aquí, los hashes regulares siempre tienen el mismo tamaño, su hash tendrá diferentes tamaños dependiendo de la entrada.

Por lo tanto, puede considerarse menos seguro que un hash regular.

Definición de la función hash:

  

Una función hash es cualquier función que se puede usar para mapear datos digitales   de tamaño arbitrario a datos digitales de tamaño fijo (...)

Las propiedades que las personas buscan cuando almacenan contraseñas es hacer que sea increíblemente tedioso y lento intentar adivinar el texto original, pero debe ser relativamente rápido cuando se hace una vez en software.

Tampoco desea que dos usuarios que utilicen la misma contraseña generen el mismo texto cifrado. Para hacer frente a esto, necesitará una sal en caso de hashing o una IV en caso de autocifrado.

Como Herr K ya ha mencionado, si tiene una contraseña, debe derivar una clave para poder cifrarla. Lo que normalmente usas entonces es PBKDF2. Que básicamente también se utiliza para el hashing de contraseñas. Así que al hacer el auto cifrado básicamente construyes otra capa encima de PBKDF2.

¿Eso agrega alguna seguridad? Realmente no. Hay mejores formas, como aumentar las rondas en la función PBKDF2 en lugar de construir una capa de autocifrado en la parte superior.

Hay mejores funciones que en realidad están construidas sobre algoritmos criptográficos simétricos como bcrypt. bcrypt está construido sobre Blowfish. Así que tal vez deberías ir con bcrypt ya que ha sido revisado a lo largo de los años.

Tenga en cuenta que el famoso criptógrafo Tom Leek dijo una vez:

  

Hashing es el marco adecuado para el almacenamiento de contraseñas (donde, de hecho,   la contraseña no se almacena, solo un token de verificación de contraseña).   Sin embargo, se sabe que el crecimiento de las funciones de hachís caseras es difícil; cuando   Los criptógrafos quieren construir una función de hash, toman mucho tiempo.   porque necesitan estar seguros de que la función es segura, y usted   no puedo saberlo con solo mirarlo.

La idea de utilizar la contraseña como clave en un cifrado es bastante similar a cómo se almacenan las contraseñas.

Uno de los primeros enfoques para el almacenamiento de contraseñas se basó en el uso de DES con la contraseña como clave. La sal sirvió como texto simple y el texto cifrado sirvió como valor hash.

Por múltiples razones, este enfoque se considera obsoleto e inseguro en estos días, pero las partes buenas de ese enfoque siguen vigentes en los nuevos diseños de hash de contraseñas.

Problemas con el enfoque basado en DES:

• Sólo 12 bits de sal. No tengo idea de por qué, ya que no parece haber ninguna razón técnica por la que no haya podido usar el tamaño completo de bloque de 64 bits como sal.
• Sólo 8 caracteres de contraseña. La forma en que DES está estructurado la clave consiste en 8 palabras de 7 bits cada una. Usar una contraseña de 8 bytes como clave DES simplemente ignorará el bit más significativo de cada byte. Esto significa 56 bits de clave, y todos los caracteres más allá de los primeros 8 se ignoraron en silencio.

Si observamos cómo funciona MD5, SHA1 y SHA2, es bastante similar a un cifrado de bloque. Cada bloque de datos que se va a hashear se expande de manera muy similar a la forma en que una clave de cifrado se expande en una programación de claves para un cifrado de bloque. Lo que sucede entonces es como sigue:

Una constante (llamada IV) se cifra con el primer bloque de datos que se utiliza como clave, luego se agregan el texto cifrado y el texto plano. El resultado de la adición se pasa a la siguiente ronda. El siguiente bloque de datos se usa luego como clave para cifrar la salida del paso anterior, y nuevamente se agregan texto sin formato y texto cifrado. Esto continúa todo el camino hasta el final de los datos + el relleno.

Como tales, ambos enfoques utilizarán la contraseña como clave en un cifrado de bloque, pero la entrada a ese cifrado de bloque no es la contraseña.

En general, no hay nada fundamental en el cifrado de una contraseña que se use a sí misma como clave para obtener un hash de contraseña. Pero el diablo está en el detalle, y hasta que los detalles estén claramente especificados, nadie puede decir si hay una debilidad en él. En particular, tener una sal con suficiente entropía y soportar contraseñas de longitud arbitraria son dos aspectos importantes que se deben respaldar para tener alguna posibilidad de igualar la seguridad de los hashes de contraseñas modernas.

Cuando esté encriptando, necesitará generar una CLAVE a partir de una frase de contraseña, que sería su contraseña en este caso. Estaría ejecutando su contraseña a través de una función de derivación de claves como PBKDF2 que efectivamente se acercará a un hash.

Básicamente, en mi humilde opinión es interesante, pero no creo que sea necesario en términos de seguridad.