¿Está utilizando el nombre de usuario cifrado con la contraseña como clave en un buen esquema de almacenamiento de contraseña?

33

En las aplicaciones web que construyo, no hago hash de las contraseñas. En su lugar, cifro simétricamente el nombre de usuario con la contraseña del usuario y almaceno el resultado en el campo de contraseña. Utilizo RijndaelManaged en dotnet.

Al iniciar sesión, lo hago de nuevo y verifico si hay una coincidencia.

Mi pregunta es, ¿qué tan seguro es esto ahora cuando se piratean cada vez más bases de datos? No sé en ningún momento la contraseña real del usuario. Lo que el hacker obtendría de db es el nombre de usuario cifrado con una contraseña desconocida. Con el hashing está el problema de las tablas arcoiris, pero con este método no.

¿Ya conoces el valor descifrado (nombre de usuario) hace que sea más fácil encontrar la contraseña?

    
pregunta Rudy 23.09.2015 - 13:08
fuente

3 respuestas

85

Lo que haces realmente es el hashing: has creado una función de hashing a partir de un cifrado de bloque. Por cierto, el "cifrado de un valor conocido con la contraseña como clave" es la forma tradicional del esquema de cifrado basado en DES para Unix fue diseñado.

En el lado positivo, su construcción incluye el nombre de usuario, que proporciona parcialmente el efecto de una sal: se desaconseja el craqueo paralelo porque dos usuarios que usan la misma contraseña terminarán con dos salidas de hash distintas. "Parcialmente", porque al cambiar la contraseña, el usuario mantiene su nombre de usuario, por lo que todavía es posible alguna forma de paralelismo aquí; y, quizás más importante, el mismo nombre de usuario puede usarse en varias aplicaciones web (por ejemplo, 'admin'), lo que hace que las tablas precomputadas valgan la pena (y el objetivo de la sal es evitar el paralelismo, en particular el uso eficiente de las tablas precomputadas).

En el lado negativo:

  • Esta es una construcción casera . 50 años de investigación en criptografía nos han enseñado que la criptografía casera rara vez es buena. De hecho, podemos "saber" que un algoritmo dado es correcto solo a través de años de revisión por parte de otros investigadores expertos, y los esquemas hechos en casa, por definición, nunca obtuvieron una gran revisión.

  • Esto es limitado. Rijndael es un cifrado de bloque que puede aceptar claves de hasta 256 bits; por lo tanto, si usa la contraseña como clave, entonces debe encajar dentro de 256 bits. Esto evita el uso de las llamadas "frases de contraseña", que pueden ser fuertes pero fáciles de memorizar contraseñas al usar mucho espacio para su entropía (a los cerebros humanos no les gusta la entropía concentrada, pero están contentos con la entropía diluida).

  • Esto es demasiado rápido, y este es el mayor problema inmediato en su esquema. Con una PC básica, un atacante puede probar muchas contraseñas por segundo, en particular porque las PC modernas tienen opcodes dedicados para AES . Con una PC de cuatro núcleos, uno debería poder probar hasta alrededor de 500 millones de contraseñas por segundo . No muchas de las contraseñas elegidas por los usuarios pueden sobrevivir a tal ataque por mucho tiempo.

Si está interesado en cómo funciona el hashing de contraseñas, lea esto . Sin embargo, la respuesta corta sigue siendo la misma: no utilice un esquema casero; utilice bcrypt .

    
respondido por el Thomas Pornin 23.09.2015 - 14:36
fuente
11

Las otras respuestas ya dicen No, "roll your own" is rarely a good password storage scheme and yours is no exception.

Me gustaría agregar: tampoco es un buen esquema para almacenar / comunicar el nombre de usuario.
Básicamente eres hash. No hay nada de malo en eso, excepto:

  • Estás usando una función que no está diseñada como una función hash segura. Al ser un cifrado, seguramente se encuentra en el extremo "seguro" de la escala, pero el hash también implica evitar colisiones de hash. Un cifrado no suele estar optimizado para no tener colisión. Se sabe que las almohadillas de una sola vez son irrompibles, porque tienen el número máximo de colisiones. Por lo tanto, un cifrado fuerte genera un hash pobre en términos de colisiones.
  • Si almacena el nombre de usuario y el nombre de usuario cifrado con contraseña, existen más vulnerabilidades:
    • En este caso, si su base de datos es hackeada, el atacante no solo obtendrá the username encrypted with an unknown password . También obtiene el texto claro aka. nombre de usuario Así que es un análisis de texto claro, que para algunas cifras es mucho más fácil que la fuerza bruta.
    • Colisiones de hash: el atacante no necesita conocer la contraseña , sino cualquiera que produce el mismo cifrado para un texto breve y claro. Esto podría ser incluso más fácil que el análisis de texto claro.
  • Si no almacena el nombre de usuario pero confía en un solo valor de transmisión combinado, todavía hay inconvenientes:
    • En este caso, probablemente no consideraste las colisiones de hash. ¿Qué pasa con dos usuarios, que tienen el mismo nombre de usuario? ¿Qué pasa con dos idiotas, que tienen el mismo nombre de usuario y la misma contraseña? ¿Qué pasa con las colisiones hash de diferentes nombres de usuario y contraseñas por pura casualidad (recuerde: los cifrados no están optimizados para evitar colisiones)?
  • En cualquier caso, existe el ataque "Pasar el hash": la comunicación de la red de rastreo de un atacante puede simplemente emular su aplicación para pasar los mismos datos que el usuario. ¿Hiciste algo al respecto? Si no es así, es por eso que no debes "rodar los tuyos".

Muchas veces, el protocolo de transmisión es tan importante para la seguridad como una función criptográfica sólida, independiente del hash en lugar del cifrado. Un protocolo incorrecto puede exponer su función a ataques para los que no es adecuado, especialmente "ataques de canal lateral" como "pasar el hash" o "hombre en el medio" que están evitando el análisis criptográfico real en el lado del atacante.

El esquema de almacenamiento de su contraseña puede ser propenso a tales ataques, porque no especificó si el nombre de usuario también se almacena en texto sin cifrar. Si lo hace, expone su esquema a los ataques descritos anteriormente. No almacenarlo en texto claro puede requerir un protocolo de transmisión propenso a ataques como se describe anteriormente.

Aquí hay algunas ideas adicionales sobre los protocolos de transmisión en su caso, ligeramente generalizadas:

Si no hiciste nada por el ataque "pasa el hash", entonces tu esquema es peor que muchos otros. Un atacante no necesita hackear su base de datos ni descifrar su cifrado. Obtiene lo que necesita de forma gratuita mediante el rastreo del tráfico de red.

HTTPS puede ser suficiente, aunque puede ser resuelto por "man in the middle": los usuarios no están buscando certificados de autenticación, ¿verdad? Un atacante simplemente abre una conexión no autenticada pero encriptada a su usuario y lo que sea que se espera que lo haga.

Un esquema adicional de desafío-respuesta puede agregar seguridad. Antes de iniciar sesión, el cliente recibe una cadena aleatoria única (desafío) que debe incluir en el hash (respuesta). Un atacante no podría reutilizar un hash rastreado, porque el desafío tampoco se reutiliza.
Pero, de nuevo, no es necesario "rodar".

    
respondido por el NoAnswer 24.09.2015 - 12:29
fuente
5

TL; DR: use scrypt. ¿Por qué rodar el tuyo cuando hay un estándar perfectamente bueno?

(Considero que Scrypt es superior a bcrypt, pero bcrypt todavía es mucho mejor que crecer por tu cuenta)

Una cosa que te falta es el estiramiento. Imagina que te piratean y tu base de datos se descarga en pastebin, puede pasarle a el mejor de nosotros .

Las personas que usan 123456 o una de las otras 20 contraseñas principales serán descubiertas en cualquier cosa que hagas, y no merecen nada mejor. Para las personas que han elegido contraseñas moderadamente buenas, hace una diferencia si el tiempo que el atacante tiene que pasar por entrada es del orden de microsegundos o segundos.

Tampoco estás aprovechando las posibilidades: imagina que dos de tus aplicaciones web son hackeadas y una persona tiene cuentas con el mismo nombre de usuario y la misma contraseña para ambos. A mí me parece que el atacante obtendrá textos cifrados idénticos en ambos volcados, diciéndoles que hay una oferta de crack-one-get-one-free.

    
respondido por el Bristol 23.09.2015 - 20:23
fuente

Lea otras preguntas en las etiquetas