Keepass2 ¿cómo separar la clave y la base de datos en dispositivos como "iPhone"?


0

La forma más segura de usar keepass es separar el archivo de clave y la base de datos.

Mi primera idea fue utilizar una tarjeta USB / flash con el archivo de clave como una clave normal (y DB en Dropbox), pero a Apple no le gustan los dispositivos de almacenamiento externo.

Por lo tanto, solo se pueden usar soluciones de nube o Internet Una vez autenticado por iOS, generalmente cualquiera puede acceder a Dropbox, Google Drive, etc., porque esas cuentas son manejadas por iOS (al menos si desea que su experiencia móvil sea al menos un poco fácil)

Mi flujo de trabajo ahora es inseguro, ambos archivos están en Dropbox. Usar un servidor SFTP en mi red local funcionaría, pero hasta donde yo sé es demasiado problemático acceder desde Internet (sin IP fija) y prefiero no abrir mi red local en absoluto a Internet.

Después de esta introducción demasiado larga, mi pregunta práctica es: ¿alguien conoce un buen flujo de trabajo seguro para la base de datos keepass2 y los archivos clave para todos los dispositivos de escritorio y dispositivos móviles (iPhone / ipad)?

Una solución donde no necesito muchas contraseñas para iniciar sesión en los servicios para obtener mis contraseñas.

EDITAR:

He releído algunos de los documentos de keepass: http://keepass.info/help/base/security.html

Para generar la clave de 256 bits para los cifrados de bloque, se utiliza el algoritmo de hash seguro SHA-256. Este algoritmo comprime la clave de usuario proporcionada por el usuario (que consta de contraseña y / o archivo de clave) a una clave de tamaño fijo de 256 bits. Esta transformación es unidireccional, es decir, es computacionalmente inviable invertir la función hash o encontrar un segundo mensaje que se comprima al mismo hash. Derivación de clave: si solo se usa una contraseña (es decir, ningún archivo de clave), la contraseña más una sal aleatoria de 128 bits se codifica con SHA-256 para formar la clave final (pero tenga en cuenta que hay algún preprocesamiento: Protección contra ataques de diccionario). La sal aleatoria evita ataques basados ​​en hashes precalculados.

Cuando se utiliza la contraseña y el archivo de clave, la clave final se deriva de la siguiente manera: SHA-256 (SHA-256 (contraseña), contenido del archivo de clave), es decir, el hash de la contraseña maestra se concatena con los bytes del archivo de clave y el byte resultante la cadena se vuelve hash con SHA-256 nuevamente. Si el archivo de clave no contiene exactamente 32 bytes (256 bits), también se combinan con SHA-256 para formar una clave de 256 bits. La fórmula anterior cambia a: SHA-256 (SHA-256 (contraseña), SHA-256 (contenido del archivo clave)).

Si entiendo esto correctamente en ambos sentidos, solo contraseña y contraseña + archivo de clave, el resultado es una "clave / hash" de 256 bits. Por lo tanto, la fuerza de la base de datos es la misma, siempre que tenga una buena contraseña. Por lo tanto, la fuerza adicional proviene del hecho de que el atacante necesita su archivo de clave para completar los 256 bits.

También, dada la mención de las medidas de contador de ataque del diccionario en el enlace, ¿puedo concluir que con una contraseña adecuada, la seguridad adicional del archivo de clave no supera los inconvenientes en este caso particular?


1
¿Por qué utilizar un archivo de clave en primer lugar?
Daniel B


apple.stackexchange.com (y elimine esta pregunta)
DavidPostill

Por lo que he leído, la combinación de los dos es la más segura. Si este no es el caso, ¿por qué el archivo de claves en primer lugar? Y si es correcto, esta sería una buena solución.
CodeRogier

lo siento, esto no es solo apple, es un problema para todos los dispositivos que no admiten susch de almacenamiento externo como usb o flash. Simplemente tengo un producto de manzana. pero el problema aún persiste.
CodeRogier
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.