Generación de contraseñas: ¿demasiado primitiva?

Para seguridad , una cosa importante a tener en cuenta es que es posible realizar una búsqueda exhaustiva de la contraseña maestra. Esquemáticamente, un atacante que obtuvo una contraseña específica del sitio (por ejemplo, un administrador malvado en ese sitio) puede ejecutar su aplicación Java (o algún código propio que aplique el mismo algoritmo) y "intentar" posibles contraseñas maestras, para ver si proporciona la contraseña específica del sitio conocida.

Si su contraseña maestra es grande y aleatoria (por ejemplo, al menos 70 bits de entropía), esto no será un problema. Sin embargo, si su contraseña maestra es más "normal" (una contraseña "segura" es, por ejemplo, 45 bits de entropía), entonces esto es una debilidad. La situación se puede mejorar utilizando hashing de contraseña adecuado : / p>

• Necesita que la transformación de la contraseña maestra a la contraseña específica del sitio sea lenta mediante el uso de muchas iteraciones.
• Necesitas un salt . En este caso, imagine que 10000 personas usan su sistema y todas tienen una cuenta en, por ejemplo, google.com (un ejemplo ficticio). Todos usarán "google.com" como "uso de contraseña". En consecuencia, un administrador malvado en google.com podría atacar todas las 10000 contraseñas maestras en paralelo, con una gran cantidad de costos compartidos. Podrías usar tu propio nombre como sal; los nombres no son sales absolutamente buenas, pero esto mejoraría significativamente esta situación.

Este es "fuerza bruta", pero con contraseñas recordadas por humanos, la fuerza bruta tiende a funcionar.

Para facilidad de uso , puede haber algunos problemas:

• Debe recordar la longitud de la contraseña que utilizó en cada sitio.

• Algunos sitios tienen requisitos especiales, y no existe un conjunto de reglas que se adapte a todos los requisitos (por ejemplo, algunos sitios hacen obligatorio el uso de signos de puntuación, mientras que otros prohíben los signos de puntuación).

• Algunos sitios pueden exigir cambios de contraseña. Por definición, su applet no puede tolerar un cambio de contraseña, a menos que use una nueva cadena de "uso", y luego tiene que recordarla .

• Además de ser subóptimo para el hashing de contraseñas, la implementación por defecto de Sun / Oracle de SecureRandom no está bien especificada, y no se garantiza que nunca cambie. Si Oracle decide modificarlo en algún momento, todas sus contraseñas se perderán. Realmente debería confiar en algún algoritmo que no esté sujeto a tales cambios.

• Buena suerte al ejecutar su código Java en su iPhone o iPad. Para una portabilidad real (incluso para hacer que su código se ejecute en la máquina que tendrá dentro de 5 años), es posible que necesite implementar su algoritmo en varios idiomas, porque no existe tal cosa como Un idioma para regirlos a todos. Esto nuevamente implica el uso de un estándar bien definido, y no "lo que Java parece usar por ahora como un algoritmo de PRNG".

Por todas las razones anteriores, crear un "monedero de contraseña" que no necesita espacio de almacenamiento es un desafío. Este concepto ha sido propuesto e incluso implementado muchas veces, y puede funcionar para la mayoría de los sitios, por lo que puede tolerarlo para su propio uso. Dependiendo de su propio contexto (qué sitio usa, qué tipo de hardware y sistema operativo posee ...).

La respuesta de Tom Leek es una excelente revisión de la diversificación de su contraseña esquema, por lo que no intentaré repetir lo que escribió en mis propias palabras inferiores. En esta respuesta me centraré en una comparación con contraseñas únicas.

En cuanto a la seguridad, las contraseñas únicas (generadas de forma independiente) tienen la ventaja de que el incumplimiento de una contraseña no revela nada sobre las otras contraseñas.

En términos de facilidad de uso, su esquema requiere un dispositivo informático para generar la contraseña del sitio a partir de la contraseña maestra. (Supongo que no puede reproducir el cálculo SecureRandom en su cabeza). Se debe confiar en este dispositivo de computación, ya que estará ingresando la contraseña maestra allí.

Con contraseñas únicas, puede tener un archivo de contraseña cifrada y usar la contraseña maestra para descifrarla. Para lograr el mismo nivel de seguridad, debe evitar los ataques de fuerza bruta desde la contraseña maestra, y eso es todo. En particular, si su archivo de contraseña cifrada es público, este esquema alcanza el mismo nivel de seguridad que el suyo: una violación de la contraseña maestra lo revela todo. Por lo tanto, solo necesita seguridad para la fase de descifrado, no para el almacenamiento del archivo de contraseñas cifradas. (Sin embargo, la seguridad del almacenamiento mejoraría la seguridad del esquema).

Por lo tanto, el único requisito para tener contraseñas independientes es una instalación de almacenamiento no confiable a la que se pueda acceder mediante un dispositivo de confianza para el cálculo. En la práctica, este requisito se cumple fácilmente: el dispositivo que está utilizando para el cálculo tiene almacenamiento o confía lo suficiente para descargar su archivo de contraseñas.

El requisito para realizar una copia de seguridad y sincronizar el archivo de contraseñas no es oneroso; dada la ubicua conectividad actual, de hecho es menos restrictiva que su esquema de generación de contraseña. Hay servicios para sincronizar archivos sin problemas en todas las plataformas comunes. Puede sincronizar el archivo de contraseña, protegido con una contraseña segura, a los servicios con un nivel de confianza medio. Si algunos de sus dispositivos son más confiables que otros, puede mantener el archivo completo en los dispositivos más confiables y un subconjunto que consiste en algunas contraseñas menos importantes en dispositivos menos confiables.

Si bien su enfoque no es fundamentalmente incorrecto, no tiene un beneficio práctico sobre el enfoque más seguro de contraseñas únicas y es menos flexible. Así que usa contraseñas únicas.