Dice que no puede confiar en un administrador de contraseñas debido a los riesgos inherentes al almacenamiento de contraseñas . Pero realmente no puedo entender dónde están las mejoras con sus soluciones:

1. Confidencialidad:

   Un administrador de contraseñas normalmente depende de algo que tienes (un archivo cifrado) y algo que sabes (una contraseña maestra). Suponiendo que utiliza una contraseña maestra correcta y un administrador de contraseñas bien implementado, se acepta la seguridad del archivo cifrado en reposo, y puede mejorarlo utilizando el almacenamiento local para el archivo si no está tan seguro con su contraseña maestra. La principal vulnerabilidad es que, cuando lo usa, un atacante podría leer en la memoria del proceso para extraer la base de datos desencriptada o qué es lo mismo que la clave simétrica utilizada para el cifrado, pero eso supone que el sistema en el que se usa se ha comprometido. p>

   En tu sistema, todavía tienes un administrador de contraseñas, por lo que es posible el mismo ataque, y solo agregas algo que sabes (tu contraseña maestra). Si su sistema está comprometido, puede ser interceptado también con un keylogger o leyendo la memoria del proceso. Además, como es común a todas las contraseñas del sitio, no las cambiará fácilmente, por lo que es realmente vulnerable a las escuchas ilegales.

2. Integridad:

   Su sistema depende de un administrador de contraseñas, por lo que no puede tener ninguna mejora aquí: si la bóveda de contraseñas se modifica, finaliza con una herramienta que ya no se puede usar, y tiene que implementar la misma forma de identificar cambios no deseados

3. Disponibilidad:

   Su sistema depende de un administrador de contraseñas, por lo que debe tener una copia de seguridad de la bóveda. Puede argumentar que, como tiene una contraseña maestra adicional, su sistema no es vulnerable a que se ponga en peligro esa copia de seguridad.

   En mi humilde opinión no es una buena práctica, ya que la contraseña maestra es solo algo que usted conoce y es poco probable que cambie porque tendría que cambiar todas sus contraseñas. Así que estás a punto de reducir la defensa en la parte algo que tienes porque piensas que has mejorado la parte algo que sabes , mientras que en mi humilde opinión no.

TL / DR: es poco probable que su algoritmo sea adoptado por una aplicación de administrador de contraseñas importante porque realmente agrega poca seguridad, si la hay. Y como en los detalles de implementación de seguridad es donde se ocultan las vulnerabilidades, le recomiendo encarecidamente no rodar las suyas. Debería pensar nuevamente en cuáles son los riesgos inherentes al almacenamiento de contraseñas y preguntarse cómo puede mitigarlos.

Pregunta original

Con una sola contraseña maestra, tanto para el hash final como para el almacén de claves.

Su esquema no agrega seguridad adicional a lo que ya ofrecen los administradores de contraseñas estándar.

Así que digamos que el archivo de contraseña de su administrador de contraseñas está filtrado. En general, estos se cifran utilizando una clave que se deriva de la contraseña maestra. Por lo tanto, un atacante tendrá que descifrar la contraseña maestra para obtener las contraseñas específicas de su sitio.

Si su contraseña maestra y el algoritmo de estiramiento de clave son buenos, es una tarea difícil. Pero por el bien de la discusión, digamos que el atacante tiene éxito. Luego, ella conoce (a) la contraseña maestra y (b) todas las contraseñas específicas de su sitio. Nada le impide calcular el hash que propusiste.

Un ataque en su esquema funcionaría exactamente igual que un ataque en el caso de LastPass, con la adición del cálculo un simple hash al final.

Pregunta actualizada

Con diferentes contraseñas maestras para el hash final y el almacén de claves.

Estás usando dos contraseñas aquí. El punto de referencia relevante para comparar es el uso de un administrador de contraseñas normal con una contraseña que sea tan larga como las dos contraseñas combinadas.

Puede argumentar si esto es un beneficio de seguridad o no. Para obtener acceso a todas sus contraseñas, un atacante debe aplicar fuerza bruta primero la contraseña del almacén de claves y luego la contraseña para el hash final. Para hacer esto último, el atacante necesitaría una contraseña correcta que esté en el almacén de claves para comparar los resultados.

Si el atacante no tiene esa contraseña, entonces su sistema es mejor.

Si el atacante tiene dicha contraseña, un administrador de contraseñas normal es mejor. Brute forzar dos contraseñas de longitud n/2 es mucho más fácil que brute forzando una contraseña de longitud n .

Por lo tanto, mi recomendación sería utilizar un administrador de contraseñas normal con una contraseña segura. Si usas una contraseña segura, un atacante no tendrá chans de todos modos.

Con un administrador de contraseñas, que elige las contraseñas del sitio al azar y las almacena en un archivo cifrado:

• Un atacante que roba una contraseña de sitio individual generada aleatoriamente por el administrador no puede aprender nada más, porque es una contraseña aleatoria, no relacionada con ninguna otra cosa. Dado que muchos sitios practican el almacenamiento inseguro de contraseñas (y la defensa contra eso es, de hecho, uno de los principales motivos para usar una solución de administración de contraseñas), esta es una muy buena garantía de tener.
• Un atacante que roba una copia de la bóveda de contraseña encriptada necesita al menos para adivinar su contraseña maestra para hacer uso de ella. (Con algunos administradores de contraseñas, también debe robar una clave criptográfica almacenada por separado de la bóveda; por lo general, lo importante es que la bóveda cifrada se puede cargar en la nube, pero la clave de seguridad nunca abandona los dispositivos).
• Un atacante que obtenga una retención de su archivo de contraseña cifrada, contraseña maestra y cualquier otra clave requerida inevitablemente accederá a todas sus contraseñas.

Por otro lado, con el enfoque "hash una contraseña maestra":

• Un atacante que roba una contraseña de sitio individual y nada más puede usarla para lanzar un ataque de descifrado de contraseñas contra su contraseña maestra. Esto se debe a que site_password = hash(master_password, site_metadata) y site_metadata es un valor de baja entropía que admite los mismos ataques de adivinación que las contraseñas. Dado que muchos sitios practican el almacenamiento inseguro de contraseñas, esto es muy preocupante.
• Un atacante que adivine su contraseña maestra no necesita robar un archivo de almacenamiento de contraseñas para lanzar un ataque de adivinaje en su site_metadata , lo que les da buenas posibilidades de descubrir las contraseñas de su sitio.
• Algunos proponentes de hash de contraseñas maestras también proponen el uso de una clave secreta como un argumento para el hash, o para almacenar site_metadata en archivos para que el usuario no tenga que (mal) recordarlo, etc. Si haga algo de eso, entonces no menos que el enfoque de bóveda encriptada que ha creado un archivo que el atacante podría robar para ayudarles en su esfuerzo.

La ventaja que los defensores del hash de la contraseña maestra reclaman con mayor frecuencia por su enfoque es que no hay una bóveda de contraseña cifrada para robar. Pero el problema con esta afirmación es que, esto es en realidad una desventaja ; si no hay un archivo así, eso significa que las contraseñas deben se pueden recuperar sin dicho archivo. , a partir de datos que un usuario puede memorizar. Por lo tanto, un atacante podría atacar el esquema sin robar ningún archivo . El hashing de la contraseña maestra es estrictamente peor que las bóvedas encriptadas.