Passwork vs KeePass: Cómo difiere la arquitectura de cifrado

KeePass tiene mejores primitivas criptográficas que muchos gestores de contraseñas de pago, y por ahí empieza esta comparación. El formato KDBX 4 admite una función de derivación de claves de uso intensivo de memoria, autentica su texto cifrado antes de descifrar nada y cifra toda la base de datos, no solo los campos de contraseña.

Lo que KDBX no tiene es gestión de claves para más de una persona. Hay una sola clave, pertenece a un archivo y no a una persona, y lo abre todo. Toda propiedad multiusuario que un equipo acaba necesitando —revocar el acceso de una persona, saber quién leyó una credencial, limitar lo que expone una única clave filtrada— hay que construirla fuera del formato, normalmente a partir de permisos del sistema de archivos y buenas intenciones.

Ese es el verdadero eje de esta comparación, y se manifiesta en tres momentos: cuando dos personas guardan a la vez la base de datos compartida, cuando alguien deja la empresa y cuando un auditor pregunta quién abrió una credencial el trimestre pasado.

Qué hace realmente KDBX 4

Un archivo KDBX 4 se cifra con AES-256 en modo CBC con relleno PKCS#7, o con ChaCha20, según la especificación del formato. La clave se obtiene a partir de un hash de los componentes de la clave maestra en un valor de 256 bits, que después pasa por una función de derivación de claves; al resultado se le aplica un hash con una semilla nueva en cada guardado. Tres funciones de derivación vienen incluidas sin plugins: AES-KDF, Argon2d y Argon2id.

En integridad es donde KDBX 4 se adelantó a su predecesor. El archivo guarda un hash SHA-256 de la cabecera, con lo que la corrupción se detecta sin la clave maestra, después un HMAC-SHA-256 de la cabecera, y la carga útil se divide en bloques de 1 MB que llevan cada uno su propio HMAC. La especificación lo llama «un esquema Encrypt-then-MAC», es decir que la autenticidad se verifica antes de descifrar nada. KDBX 3.1 aplicaba el hash al texto en claro, y la nota del autor sobre el cambio merece citarse por su contención:

Aunque en general se considera que el esquema Encrypt-then-MAC (KDBX 4) es más seguro que un esquema MAC-then-Encrypt (KDBX 3.1), no creemos que los archivos KDBX 3.1 fueran inseguros.

Dos advertencias importan en un equipo. KDBX 3.1 sigue siendo un formato nativo en KeePassXC, así que «KeePass significa Argon2 y HMAC» solo se cumple una vez que alguien ha migrado realmente la base de datos, un paso manual en los ajustes de cifrado. Y el parámetro de memoria de Argon2 está limitado por el dispositivo más débil que abra el archivo: KeePass sugiere la mitad de la RAM del dispositivo más pequeño, y advierte de que en iOS un parámetro de memoria elevado puede romper AutoFill, por lo que recomienda 64 MB o menos. Una KDF no es más fuerte que los parámetros que resista el teléfono.

El alcance del cifrado es realmente mejor que en varios competidores alojados: «KeePass cifra toda la base de datos, es decir, no solo las contraseñas, sino también los nombres de usuario, las URL, las notas, etc.» Un KDBX robado no filtra nada sobre su contenido, ni siquiera los títulos de las entradas.

Algo parece una segunda capa, pero no lo es. KDBX también aplica Salsa20 o ChaCha20 a los campos protegidos dentro del XML, y la especificación se adelanta directamente a esa lectura errónea:

Insistimos en que el único propósito del cifrado interno es dar soporte a la protección de la memoria del proceso. El cifrado interno no influye en la seguridad criptográfica del formato de archivo KDBX.

Su clave reside en la cabecera interna y no depende de la clave maestra.

Dónde reside la clave y por qué eso decide todo lo demás

La clave maestra de KeePass es compuesta: una contraseña maestra, un archivo de clave y una clave vinculada a la cuenta de Windows actual mediante DPAPI, en cualquier combinación. Todos los componentes elegidos son obligatorios, y la documentación de la clave maestra es tajante al respecto:

Si olvida/pierde cualquiera de los componentes de la clave maestra (u olvida la composición), se pierden todos los datos almacenados en la base de datos. No hay puerta trasera ni clave universal que pueda abrir su base de datos.

Observe lo que comparten esos componentes. Una contraseña es conocimiento, un archivo de clave es posesión, una clave DPAPI es una cuenta de máquina. Ninguno es una identidad que la base de datos reconozca y pueda después distinguir de otra. La clave es una propiedad del archivo.

Passwork parte de la persona y aplica el mismo principio de arquitectura de conocimiento cero (el servidor nunca maneja más que texto cifrado), construido en torno a la identidad individual y no a un único secreto de archivo. Cada usuario tiene su propio par de claves RSA generado en el cliente, con la mitad privada cifrada bajo una clave derivada de su contraseña maestra. Una bóveda recibe su propia clave AES-256 al crearse, y cada usuario con acceso conserva una copia independiente de esa clave de bóveda, cifrada con su propia clave pública (jerarquía de claves). El servidor nunca maneja nada más que texto cifrado (introducción a la criptografía).

El uso compartido se deriva de esa estructura. Conceder acceso vuelve a cifrar la clave de la bóveda con la clave pública del destinatario, en lugar de volver a cifrar los datos (mecánica del uso compartido). Revocarlo elimina la copia cifrada de esa persona. El resto continúa con la misma clave de bóveda y no se vuelve a cifrar nada.

Dónde la criptografía de KeePass es más fuerte para un solo usuario

En la derivación de claves es donde se nota. Argon2 es de uso intensivo de memoria, que es precisamente la propiedad que encarece el descifrado con GPU y ASIC, y KeePass explica por qué prefiere Argon2d en este contexto: «una mejor protección frente a una amenaza realmente existente (el descifrado de contraseñas con GPU/ASIC es lo más avanzado hoy) es más importante que una protección frente a ciertos ataques de canal lateral que pueden convertirse o no en un problema en los dispositivos cliente en el futuro». Passwork deriva la clave maestra con PBKDF2 y 300 000 iteraciones sobre SHA-256: un ajuste defendible y reconocido por NIST, pero no de uso intensivo de memoria, y frente a hardware dedicado al descifrado esa distinción importa.

Eso no cambia la conclusión para un equipo que comparte credenciales entre más de una persona: ahí lo decisivo es la gestión de claves, no la fuerza del cifrado, y es la cuestión en la que se centra el resto de esta comparación. Para un solo usuario con un portátil y un archivo, que no comparte nada con nadie, esa es la propiedad que más importa frente a los intentos de descifrado sin conexión.

Qué ocurre cuando un equipo comparte el archivo

Aquí se ve el objetivo de diseño. La documentación de KeePass sobre varios usuarios no se anda con rodeos:

Todos los usuarios utilizan la misma contraseña maestra o el mismo archivo de clave, o ambos, para abrir la base de datos. No hay listas de control de acceso (ACL) por grupo ni por entrada. Para restringir el acceso de escritura al archivo de base de datos (es decir, que solo un conjunto seleccionado de usuarios pueda modificar los datos almacenados), utilice los permisos de acceso del sistema de archivos.

El control de acceso existe, pero reside en NTFS o en el recurso compartido SMB, no en el producto ni en la criptografía. El acceso de lectura es todo o nada por construcción, porque leer requiere la única clave que descifra todo.

KeePass 2.x sí detecta conflictos. Al guardar, «comprueba primero si el archivo en disco se ha modificado desde que se cargó» y, en ese caso, ofrece sincronizar en lugar de sobrescribir. La fusión se produce a nivel de entrada, y la versión perdedora de una entrada en conflicto se conserva en el historial de esa entrada en lugar de descartarse.

Los conflictos se resuelven comparando las marcas de tiempo de última modificación, así que el árbitro es el reloj del sistema de cada usuario y no ninguna noción de autoridad. El aviso aparece solo al guardar: «el aviso de sincronización solo lo activa el comando ‹Save›, no el comando ‹Save As›. Al ejecutar el comando ‹Save As› y seleccionar un archivo manualmente, ese archivo se sobrescribe siempre». Las entradas del historial sobreviven a una fusión, pero «pueden ser eliminadas por el mantenimiento automático del historial», que se basa en el tamaño. Y KeePass 1.x no tiene sincronización alguna, de modo que allí un guardado sí sobrescribe lo que haya cambiado por debajo.

KeePassXC se diferencia de una forma que importa si es su cliente. Tiene una función de fusión en la interfaz gráfica y como keepassxc-cli merge, que compara las entradas por UUID y hora de modificación. Pero no incluye sincronización en la nube de forma deliberada, y las preguntas frecuentes explican el razonamiento: colocar la base de datos en una carpeta compartida en la nube y dejar que el servicio de sincronización se encargue, lo que «mantiene baja la complejidad de nuestro código». Ingeniería defendible, con una consecuencia operativa concreta. Dropbox, Nextcloud y OneDrive no saben nada de KDBX, así que las ediciones simultáneas generan copias en conflicto del archivo, y conciliarlas es una fusión manual que alguien tiene que acordarse de ejecutar.

El patrón que KeePass recomienda para archivos compartidos es un disparador (trigger): mantener una copia local y sincronizarla con el archivo maestro, un esquema que su documentación describe como una forma de evitar la «pérdida de datos cuando otras aplicaciones sobrescriben los archivos de base de datos (por ejemplo, software de servicios de almacenamiento en la nube)». Funciona. También significa que el modelo de acceso depende ahora de un disparador guardado en un archivo de configuración que, como señala la página de disparadores, no está cifrado y «se aplica a todos los usuarios que utilizan esta instalación de KeePass».

Retirar el acceso

Pregunte esto primero en cualquier evaluación. Un modelo basado en archivos no tiene una buena respuesta, y la que tiene suele sorprender.

Un empleado que se marcha tenía la clave maestra. Puede que también tenga una copia del KDBX en un portátil, en una copia de seguridad, en una carpeta sincronizada o en una copia en conflicto que nadie limpió. Cambiar la clave maestra vuelve a cifrar la base de datos a partir de ese momento y no afecta a las copias que ya existen. Esas siguen siendo descifrables indefinidamente con la clave con la que se guardaron. El historial de entradas lo agrava: rotar una contraseña dentro de la base de datos conserva el valor anterior en el historial de esa entrada, de modo que una copia desactualizada contiene tanto el secreto antiguo como el nuevo.

La única revocación real es rotar todas las credenciales a las que esa persona podía llegar, lo que en un modelo de un solo archivo significa todas. El trabajo escala con el tamaño de la base de datos, no con el alcance del puesto de esa persona.

En Passwork ese mismo suceso está acotado. Retirar el acceso del usuario elimina su copia cifrada de la clave de la bóveda, y los miembros restantes continúan con la clave sin cambios. La rotación tras la baja del empleado sigue siendo el control adecuado para todo lo que esa persona haya leído realmente, y ningún producto puede deshacer la filtración de una credencial que alguien memorizó. La diferencia es que el radio de impacto es una bóveda y no todo, y que la revocación es una operación y no un proyecto.

Cuando está configurada la integración con LDAP/Active Directory de Passwork, esa operación no tiene por qué ser manual: desactivar la cuenta en AD revoca el acceso a Passwork de forma automática, en consonancia con el estado del directorio, así que dar de baja en el directorio equivale a dar de baja en la bóveda. Y el panel de seguridad no deja las consecuencias a la memoria: marca como riesgo de compromiso las credenciales que siguen siendo accesibles para un usuario cuyo acceso se ha revocado, con lo que convierte lo que esa persona podía alcanzar en una lista de trabajo visible y no en algo que reconstruir a mano.

Quién leyó qué

KeePass es una aplicación de escritorio sin componente de servidor, algo que señalan sus propias notas al descartar un informe sobre un ataque de temporización: KeePass «no ofrece ninguna capacidad de servidor (en particular, no se puede activar externamente la apertura automática de la base de datos)».

Eso tiene una consecuencia para la auditoría. KDBX registra marcas de tiempo de modificación e historial de entradas, que es un log de cambios en el archivo, no un log de accesos. Nada registra que alguien haya abierto la base de datos y leído una credencial, porque la lectura ocurre por completo en el cliente. Con una única clave maestra compartida, ni siquiera un registro de cambios permite saber de forma fiable qué persona lo hizo.

Passwork registra las acciones en el servidor y puede reenviarlas en CEF a syslog o al registro de eventos de Windows para un SIEM (registro de actividad, lista de eventos). Las concesiones, los cambios y las revocaciones se registran de forma individual y se atribuyen a una cuenta.

Confiar en un archivo que todos editan

El argumento más contundente contra el patrón de base de datos compartida procede de la propia documentación de KeePass.

KeePass admite marcadores de posición dentro de las entradas. {CMD:...} ejecuta una línea de comandos y las referencias a campos pueden extraer datos de otras entradas, así que una URL manipulada puede exfiltrar una credencial distinta. La página de seguridad ofrece el ejemplo: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. La recomendación que sigue es inequívoca:

Al abrir una base de datos que ha sido creada/modificada por otra persona, debería comprobar con cuidado todos los datos que quiera utilizar. Si no confía plenamente en el creador de la base de datos, no abra ningún archivo adjunto a las entradas.

Lea eso pensando en un despliegue en una unidad compartida. Una base de datos de equipo está, por definición, creada y modificada por otras personas, y cualquiera con acceso de escritura puede añadir entradas en las que los demás harán clic. El modelo de confianza que KeePass documenta supone que una base de datos tiene un único propietario que responde por su contenido, que es precisamente lo que un archivo de equipo compartido no es.

Vulnerabilidades documentadas

CVE-2023-32784 (CVSS 7,5) permitía recuperar la contraseña maestra en claro a partir de un volcado de memoria en KeePass 2.x anterior a 2.54, incluso desde un archivo de intercambio o de hibernación y aun después de que el proceso hubiera terminado, con solo el primer carácter irrecuperable. La causa era un cuadro de texto personalizado que dejaba restos de cada carácter en la memoria de .NET. Se corrigió en 2.54 y el investigador reconoció una respuesta rápida.

CVE-2023-24055 (CVSS 5,5) está marcado como disputado por MITRE. Un atacante con acceso de escritura al archivo de configuración XML podía añadir un disparador de exportación y recolectar contraseñas en claro. La entrada del NVD recoge la posición del proveedor: «la base de datos de contraseñas no pretende ser segura frente a un atacante que tiene ese nivel de acceso al PC local». Esa posición es coherente, y la página de problemas de seguridad lo argumenta de forma general: quien puede escribir en el archivo de configuración normalmente puede reemplazar el ejecutable.

Para ser justos, KeePassXC ha pasado una auditoría externa, finalizada en enero de 2023, y afirma abiertamente que una auditoría «solo es válida para una ‹instantánea› del código».

Tabla comparativa

Migrar y a qué prestar atención durante la migración

Passwork importa XML de KeePass, además de JSON y CSV. No lee el binario KDBX cifrado, y el análisis se realiza en el cliente y no en el servidor, que es la única disposición coherente con que el servidor nunca vea texto en claro.

Vale la pena enunciar la consecuencia en lugar de pasarla por alto. Exportar de KeePass a XML produce un archivo sin cifrar que contiene todas las credenciales, y ese archivo permanece en disco todo el tiempo que dure la migración. Hágalo en un equipo que controle, en almacenamiento local y no en una carpeta sincronizada, y elimínelo con una herramienta que sobrescriba en lugar de desvincular. Es el único paso de una migración en el que una tarde descuidada deshace a la vez la criptografía de ambos productos.

Cuándo KeePass es la respuesta correcta

Si lo que está valorando concretamente es si KeePass basta para un equipo pequeño, Gestión de contraseñas y accesos para pymes: ¿Basta con KeePass? aborda esa pregunta directamente. Este artículo es más limitado y se centra solo en el eje de la arquitectura de cifrado, para equipos de cualquier tamaño.

Si es una sola persona, o dos que de todos modos comparten realmente todo, KeePass con una base de datos KDBX 4 y parámetros de Argon2 sensatos es una opción excelente, y es gratuita. La criptografía es sólida, el formato está documentado públicamente y, al no haber servidor, no hay ningún servicio que vulnerar.

El modelo deja de encajar cuando se necesitan respuestas que un archivo no puede dar. Quién tiene acceso a esto, exactamente. Qué se perdió exactamente cuando desapareció aquel portátil. Qué se rompe cuando esta persona se marche el viernes. Demuestre que el contratista nunca vio credenciales de producción.

Una prueba útil antes de decidir: cuente cuántas personas tienen hoy la clave maestra de la base de datos compartida y pregúntese qué tendría que rotar si cualquiera de ellas se marchara mañana. Si la respuesta es «todo», no es un problema de configuración que pueda ajustarse. Es el modelo de archivo funcionando como está diseñado. La referencia de la jerarquía de claves muestra cómo es el límite alternativo.

Un archivo tiene una clave para todos. Una bóveda tiene una clave por bóveda, cifrada para cada persona. Esa brecha no se reduce a medida que crece un equipo; se agrava. Si KeePass no es la única alternativa de su lista, la comparación de la arquitectura de cifrado de bóvedas de Passwork y Bitwarden recorre esos mismos tres momentos (guardados simultáneos, baja de empleados, auditoría) para un competidor nativo de la nube en lugar de un formato de archivo.

Haga la prueba de la clave maestra en su propio equipo y vea después la alternativa. Probar Passwork gratis.

Preguntas frecuentes

Gestión de contraseñas y accesos para pymes: ¿Basta con KeePass?

Todo administrador de TI que usa KeePass para un equipo cuenta la misma historia. Empieza con un único archivo .kdbx compartido en una unidad de red. Luego alguien no puede abrirlo porque un compañero lo tiene bloqueado. Luego un administrador de sistemas junior sobrescribe un cambio que otra persona hizo una hora antes. Luego un empleado se marcha y nadie sabe con certeza a qué contraseñas tenía acceso. KeePass es una herramienta realmente excelente, para una sola persona. En el momento en que la pone delante de un equipo, ya no gestiona contraseñas. Gestiona un s

PassworkAlex Muntyan

¿Qué es el cifrado de conocimiento cero? Cómo funciona en 5 minutos

El cifrado de conocimiento cero significa que el servidor nunca guarda las claves de descifrado, solo texto cifrado. Descubra cómo funciona la cadena de claves, de qué protege, de qué no y cómo verificar la afirmación de un proveedor.

PassworkPasswork Team

Passwork vs Bitwarden: Cómo difiere la arquitectura de cifrado de bóvedas

Passwork cifra cada bóveda con su propia clave. Bitwarden cifra toda una organización con una única clave compartida. Esta comparación desglosa qué implica eso para el radio de impacto, el aislamiento de equipos, la recuperación de cuentas y las respuestas de auditoría cuando se filtra una credencial.

PassworkPasswork Team