Passwork vs KeePass: como difere a arquitetura de cifragem

O KeePass tem primitivas criptográficas melhores do que muitos gestores de palavras-passe disponíveis no mercado, e é daí que parte esta comparação. O formato KDBX 4 inclui uma função de derivação de chave com utilização intensiva de memória, autentica o texto cifrado antes de decifrar seja o que for e cifra a base de dados inteira, e não apenas os campos de palavra-passe.

O que o KDBX não tem é gestão de chaves para mais de uma pessoa. Existe uma única chave, que pertence a um ficheiro e não a uma pessoa, e que abre tudo. Todas as propriedades multiutilizador de que uma equipa acaba por precisar (revogar o acesso de uma pessoa, saber quem leu uma credencial, limitar o que fica exposto por uma única chave divulgada) têm de ser construídas fora do formato, normalmente à base de permissões do sistema de ficheiros e de boas intenções.

Este é o verdadeiro eixo da questão, e manifesta-se em três momentos: quando duas pessoas guardam em simultâneo a base de dados partilhada, quando alguém sai da empresa e quando um auditor pergunta quem abriu uma credencial no trimestre passado.

Em resumo

KDBX cifra um único ficheiro com uma única chave mestra composta. Passwork atribui a cada cofre a sua própria chave AES-256, encapsulada separadamente para cada utilizador com a chave pública RSA desse utilizador.
KeePass documenta claramente que não existem listas de controlo de acesso (ACL) por grupo nem por entrada. O controlo de acesso é delegado nos direitos do sistema de ficheiros, fora da criptografia.
KeePass 2.x deteta e funde, de facto, as edições simultâneas. Um conflito é decidido pela data e hora da última modificação, e não pelas permissões.
Revogar o acesso a um ficheiro KDBX que alguém já copiou não é possível. Alterar a chave mestra protege as gravações futuras, não as cópias existentes.
Em matéria de derivação de chave e de autenticação do texto cifrado, KeePass oferece a resposta mais sólida, e este artigo indica onde.

O que o KDBX 4 faz na realidade

Um ficheiro KDBX 4 é cifrado com AES-256 em modo CBC com preenchimento PKCS#7 ou com ChaCha20, segundo a especificação do formato. A chave resulta do cálculo de um hash dos componentes da chave mestra, que produz um valor de 256 bits; este passa por uma função de derivação de chave e o resultado é novamente processado por hash com uma semente nova em cada gravação. Três funções de derivação são fornecidas sem plugins: AES-KDF, Argon2d e Argon2id.

A integridade é o ponto em que o KDBX 4 superou o seu antecessor. O ficheiro guarda um hash SHA-256 do cabeçalho, pelo que a corrupção é detetável sem a chave mestra, depois um HMAC-SHA-256 do cabeçalho, e a carga útil é dividida em blocos de 1 MB, cada um com o seu próprio HMAC. A especificação designa este mecanismo como «um esquema Encrypt-then-MAC», o que significa que a autenticidade é verificada antes de qualquer decifragem. O KDBX 3.1 calculava o hash do texto simples, e a nota do autor sobre a alteração merece ser citada pela sua contenção:

Embora o esquema Encrypt-then-MAC (KDBX 4) seja, em geral, considerado mais seguro do que um esquema MAC-then-Encrypt (KDBX 3.1), não acreditamos que os ficheiros KDBX 3.1 fossem inseguros.

Duas ressalvas são relevantes para uma equipa. O KDBX 3.1 continua a ser um formato nativo no KeePassXC, pelo que «KeePass significa Argon2 e HMAC» só se verifica depois de alguém ter efetivamente migrado a base de dados, o que é um passo manual nas definições de cifragem. E o parâmetro de memória do Argon2 é limitado pelo dispositivo mais fraco que abre o ficheiro: o KeePass sugere metade da RAM do dispositivo mais pequeno e avisa que, no iOS, um parâmetro de memória elevado pode prejudicar o AutoFill, pelo que recomenda aí 64 MB ou menos. Uma KDF só é tão forte quanto os parâmetros que o telemóvel suporta.

O âmbito da cifragem é, de facto, superior ao de vários concorrentes alojados na nuvem: «O KeePass cifra toda a base de dados, ou seja, não só as palavras-passe, mas também os nomes de utilizador, os URLs, as notas, etc.» Um ficheiro KDBX roubado não revela nada sobre o seu conteúdo, nem sequer os títulos das entradas.

Há algo que parece uma segunda camada, mas não é. O KDBX aplica também Salsa20 ou ChaCha20 aos campos protegidos dentro do XML, e a especificação desfaz diretamente o equívoco:

Salientamos que o único objetivo da cifragem interna é permitir a proteção da memória do processo. A cifragem interna não tem qualquer efeito na segurança criptográfica do formato de ficheiro KDBX.

A sua chave reside no cabeçalho interno e não depende da chave mestra.

Onde reside a chave e porque é que isso decide tudo o resto

A chave mestra do KeePass é composta: uma palavra-passe mestra, um ficheiro de chave e uma chave associada à conta Windows atual através de DPAPI, em qualquer combinação. Todos os componentes escolhidos são obrigatórios, e a documentação sobre a chave mestra é direta a esse respeito:

Se esquecer/perder qualquer um dos componentes da chave mestra (ou esquecer a composição), todos os dados armazenados na base de dados são perdidos. Não existe nenhuma backdoor nem chave universal capaz de abrir a base de dados.

Note-se o que estes componentes têm em comum. Uma palavra-passe é conhecimento, um ficheiro de chave é posse, uma chave DPAPI é uma conta de máquina. Nenhum deles é uma identidade que a base de dados reconheça e consiga depois distinguir de outra. A chave é uma propriedade do ficheiro.

Passwork parte da pessoa e aplica o mesmo princípio de arquitetura zero-knowledge (o servidor só processa texto cifrado), construído em torno da identidade individual e não de um segredo de ficheiro único. Cada utilizador tem o seu próprio par de chaves RSA gerado no cliente, com a metade privada cifrada por uma chave derivada da sua palavra-passe mestra. Um cofre recebe a sua própria chave AES-256 na criação, e cada utilizador com acesso possui uma cópia separada dessa chave do cofre, encapsulada com a respetiva chave pública (hierarquia de chaves). O servidor só processa texto cifrado (visão geral da criptografia).

A partilha decorre desta estrutura. A concessão de acesso volta a encapsular a chave do cofre para a chave pública do destinatário, em vez de voltar a cifrar os dados (mecanismos de partilha). A revogação elimina a cópia encapsulada dessa pessoa. Todos os restantes continuam com a mesma chave do cofre, e nada é novamente cifrado.

	KeePass (KDBX)	Passwork
O que a chave protege	O ficheiro inteiro	Um cofre
A que a chave está associada	O próprio ficheiro, não uma pessoa	A identidade de cada utilizador (par de chaves RSA)
Quem o pode abrir	Qualquer pessoa com a chave mestra composta	Cada utilizador, através da sua própria cópia encapsulada da chave do cofre
Adicionar ou remover alguém	Partilhar, ou deixar de partilhar, a própria chave mestra	Encapsular, ou eliminar, a cópia da chave do cofre dessa pessoa

Onde a criptografia do KeePass é mais forte para um único utilizador

A derivação de chave é onde isso se nota. O Argon2 é intensivo em memória (memory-hard), que é precisamente a propriedade que torna dispendiosa a quebra por GPU e ASIC, e o KeePass explica por que razão prefere o Argon2d neste cenário: «uma melhor proteção contra uma ameaça realmente existente (o cracking de palavras-passe com GPUs/ASICs é o estado da arte) é mais importante do que uma proteção contra certos ataques de canal lateral que podem vir ou não a ser um problema em dispositivos cliente no futuro.» O Passwork deriva a chave mestra com PBKDF2 a 300 000 iterações sobre SHA-256, uma configuração defensável e reconhecida pelo NIST, mas sem utilização intensiva de memória, e perante hardware de cracking dedicado essa distinção é relevante.

Isto não altera a conclusão para uma equipa que partilha credenciais entre mais de uma pessoa: tudo se resume à gestão de chaves, e não à força da cifra, e é a questão em que se concentra o resto desta comparação. Para um único utilizador com um só portátil e um só ficheiro, sem partilhar nada com ninguém, essa é a propriedade que mais importa contra tentativas de cracking offline.

O que acontece quando uma equipa partilha o ficheiro

É aqui que se revela o objetivo de conceção. A documentação do KeePass sobre vários utilizadores não deixa margem para dúvidas:

Todos os utilizadores usam a mesma palavra-passe mestra e/ou ficheiro de chave para abrir a base de dados. Não existem listas de controlo de acesso (ACL) por grupo ou por entrada. Para restringir o acesso de escrita ao ficheiro da base de dados (isto é, para que apenas um conjunto selecionado de utilizadores possa alterar os dados armazenados), utilize os direitos de acesso do sistema de ficheiros.

O controlo de acesso existe, mas reside no NTFS ou na partilha SMB, não no produto nem na criptografia. O acesso de leitura é do tipo tudo ou nada por construção, porque a leitura exige a única chave que decifra tudo.

O KeePass 2.x deteta conflitos. Ao guardar, «verifica primeiro se o ficheiro em disco foi modificado desde que foi carregado» e, se for o caso, propõe sincronizar em vez de substituir. A fusão é feita ao nível da entrada, e a versão perdedora de uma entrada em conflito é mantida no histórico dessa entrada, em vez de ser descartada.

Os conflitos são resolvidos por comparação das datas e horas da última modificação, pelo que o árbitro é o relógio do sistema de cada utilizador e não qualquer noção de autoridade. O aviso é acionado apenas ao guardar: «o aviso de sincronização só é acionado pelo comando ‹Guardar›, e não pelo comando ‹Guardar como›. Ao executar o comando ‹Guardar como› e selecionar manualmente um ficheiro, esse ficheiro será sempre substituído.» As entradas do histórico sobrevivem a uma fusão, mas «podem ser eliminadas pela manutenção automática do histórico», que se baseia no tamanho. E o KeePass 1.x não tem qualquer sincronização, pelo que aí uma gravação substitui mesmo o que foi alterado entretanto nos bastidores.

O KeePassXC difere de uma forma que importa se for esse o cliente em uso. Tem uma função de fusão na interface gráfica e como keepassxc-cli merge, que compara as entradas por UUID e data de modificação. Mas não tem sincronização na nuvem integrada, propositadamente, e a FAQ apresenta o raciocínio: colocar a base de dados numa pasta partilhada na nuvem e deixar que o serviço de sincronização trate dela, o que «mantém baixa a complexidade do nosso código». Engenharia defensável, com uma consequência operacional específica. O Dropbox, o Nextcloud e o OneDrive nada sabem sobre o KDBX, pelo que edições simultâneas produzem cópias em conflito do ficheiro, e a reconciliação é uma fusão manual de que alguém tem de se lembrar.

O padrão que o próprio KeePass recomenda para ficheiros partilhados é um trigger (acionador): manter uma cópia local e sincronizar com o ficheiro principal, um esquema que a documentação descreve como forma de evitar «a perda de dados quando os ficheiros de base de dados são substituídos por outras aplicações (por exemplo, software de serviços de armazenamento na nuvem).» Funciona. Significa também que o modelo de acesso passa a depender de um trigger guardado num ficheiro de configuração que, como a página Triggers refere, não está cifrado e «aplica-se a todos os utilizadores desta instalação do KeePass.»

Retirar o acesso

Esta é a primeira pergunta a fazer em qualquer avaliação. Um modelo baseado em ficheiros não tem boa resposta para ela, e a que tem tende a surpreender.

Um colaborador que está de saída tinha a chave mestra. Pode também ter uma cópia do KDBX num portátil, numa cópia de segurança, numa pasta de sincronização ou numa cópia em conflito que ninguém limpou. Alterar a chave mestra volta a cifrar a base de dados daí em diante e nada faz às cópias que já existem. Estas continuam decifráveis com a chave com que foram guardadas, indefinidamente. O histórico das entradas agrava a situação: rodar uma palavra-passe dentro da base de dados mantém o valor anterior no histórico dessa entrada, pelo que uma cópia antiga contém tanto o segredo antigo como o novo.

A única revogação real consiste em efetuar a rotação de todas as credenciais a que essa pessoa tinha acesso, o que, num modelo de ficheiro único, significa todas. O trabalho escala com o tamanho da base de dados e não com o âmbito das funções dessa pessoa.

No Passwork, o mesmo evento fica delimitado. Remover o acesso do utilizador elimina a sua cópia encapsulada da chave do cofre, e os restantes membros continuam com a chave inalterada. A rotação após a saída do colaborador continua a ser o controlo adequado para tudo o que essa pessoa efetivamente leu, e nenhum produto consegue reverter a divulgação de uma credencial que alguém memorizou. A diferença é que o raio de impacto é um cofre e não tudo, e a revogação é uma operação e não um projeto.

Quando a integração LDAP/Active Directory do Passwork estiver configurada, essa operação nem precisa de ser manual: desativar a conta no AD revoga automaticamente o acesso ao Passwork, de acordo com o estado do diretório, pelo que a saída de um colaborador no diretório equivale à saída no cofre. E o painel de segurança não deixa as consequências entregues à memória: sinaliza como risco de comprometimento as credenciais ainda acessíveis a um utilizador cujo acesso foi revogado, o que transforma aquilo a que essa pessoa tinha acesso numa lista de tarefas visível, em vez de algo a reconstituir manualmente.

Quem leu o quê

O KeePass é uma aplicação de desktop sem componente de servidor, um ponto que as suas próprias notas reconhecem ao rejeitar um relatório sobre um ataque de temporização: o KeePass «não dispõe de quaisquer capacidades de servidor (em especial, não é possível acionar externamente nenhuma abertura automática da base de dados).»

Isto tem uma consequência para a auditoria. O KDBX regista datas e horas de modificação e o histórico das entradas, que são um registo de alterações ao ficheiro, não um registo de acessos. Nada regista que alguém abriu a base de dados e leu uma credencial, porque a leitura ocorre inteiramente no cliente. Com uma única chave mestra partilhada, nem sequer um registo de alterações permite saber de forma fiável que pessoa as fez.

O Passwork regista as ações no servidor e pode reencaminhá-las em CEF para o syslog ou para o registo de eventos do Windows, para um SIEM (registo de atividade, lista de eventos). As concessões, alterações e revogações são registadas individualmente e atribuídas a uma conta.

Confiar num ficheiro que todos editam

O argumento mais contundente contra o padrão da base de dados partilhada provém da própria documentação do KeePass.

O KeePass permite usar marcadores de posição nas entradas. {CMD:...} executa uma linha de comandos, e as referências de campo podem obter dados de outras entradas, pelo que um URL manipulado pode exfiltrar uma credencial diferente. A página Security apresenta ela própria o exemplo: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. A orientação que se segue é inequívoca:

Ao abrir uma base de dados criada/modificada por outra pessoa, deve verificar cuidadosamente todos os dados que pretende utilizar. Se não confiar plenamente no criador da base de dados, não abra quaisquer ficheiros anexados às entradas.

Leia-se isto no contexto de uma implementação em unidade de rede partilhada. Uma base de dados de equipa é, por definição, criada e modificada por outras pessoas, e qualquer pessoa com acesso de escrita pode adicionar entradas em que as outras irão clicar. O modelo de confiança que o KeePass documenta pressupõe que a base de dados tem um único proprietário que garante o seu conteúdo, o que é precisamente o que um ficheiro de equipa partilhado não é.

Vulnerabilidades documentadas

A CVE-2023-32784 (CVSS 7,5) permitia recuperar a palavra-passe mestra em texto simples a partir de um dump de memória no KeePass 2.x anterior à versão 2.54, inclusive a partir de um ficheiro de swap ou de hibernação e mesmo depois de o processo ter terminado, com apenas o primeiro carácter irrecuperável. A causa era uma caixa de texto personalizada que deixava vestígios de cada carácter na memória do .NET. Foi corrigida na versão 2.54, e o investigador elogiou a rapidez da resposta.

A CVE-2023-24055 (CVSS 5,5) está assinalada como disputada pela MITRE. Um atacante com acesso de escrita ao ficheiro de configuração XML podia adicionar um trigger de exportação e recolher palavras-passe em texto simples. A entrada do NVD regista a posição do fabricante: «a base de dados de palavras-passe não se destina a ser segura contra um atacante com esse nível de acesso ao PC local.» Essa posição é coerente, e a página Security Issues defende-a em termos gerais: quem consegue escrever no ficheiro de configuração pode, em regra, substituir antes o executável.

Para equilíbrio, o KeePassXC foi alvo de uma auditoria externa, concluída em janeiro de 2023, e afirma abertamente que uma auditoria «é válida apenas para um ‹instantâneo› do código».

Tabela comparativa

Aspeto	Passwork	KeePass (KDBX 4)
Limite criptográfico	Cada cofre tem a sua própria chave	O ficheiro inteiro, uma só chave
Chave raiz	Chave AES-256 por cofre, encapsulada por utilizador com RSA	Uma chave mestra composta: palavra-passe, ficheiro de chave, DPAPI
Identidade do utilizador na criptografia	Par de chaves RSA por utilizador	Nenhuma; a chave pertence ao ficheiro
Controlo de acesso	ACL da aplicação ao nível do cofre, da pasta e do registo individual	«Sem ACL por grupo ou por entrada»; direitos do sistema de ficheiros
Concessão de acesso	Voltar a encapsular a chave do cofre para a chave pública do destinatário	Entregar o ficheiro e a chave mestra
Revogação de acesso	Eliminar a chave do cofre encapsulada desse utilizador	Não é possível para as cópias existentes; rodar tudo
Derivação de chave	PBKDF2, 300 000 iterações, SHA-256	Argon2d / Argon2id (intensivo em memória) ou AES-KDF
Cifra	AES-256	AES-256 ou ChaCha20
Proteção dos metadados	Palavra-passe, campos personalizados, TOTP e anexos cifrados no cliente; nomes de registos/cofres, nomes de utilizador, URLs e etiquetas apenas do lado do servidor	Toda a base de dados, incluindo títulos, URLs e notas
Auditoria de acessos	Registo no servidor, CEF para syslog ou SIEM	Sem componente de servidor, logo sem registo de acessos
Edição simultânea	Mediada pelo servidor, sem conflitos de ficheiros	Fusão ao nível da entrada, prevalece a última data de modificação
Recuperação	Contas de recuperação do tipo cofre (palavra-passe mestra armazenada offline); sem chave única obrigatória	Nenhuma, por conceção: «nenhuma backdoor nem chave universal»

Migrar e o que vigiar durante o processo

O Passwork importa o XML do KeePass, a par de JSON e CSV. Não lê o binário KDBX cifrado, e a análise é feita no cliente e não no servidor, que é a única disposição coerente com o facto de o servidor nunca ver texto simples.

A consequência merece ser afirmada de forma explícita, e não diluída. Exportar do KeePass para XML produz um ficheiro não cifrado com todas as credenciais, que permanece no disco enquanto durar a migração. Convém fazê-lo numa máquina sob controlo próprio, em armazenamento local e não numa pasta sincronizada, e eliminar o ficheiro com uma ferramenta que sobrescreva os dados em vez de apenas remover a referência. É o único passo de uma migração em que uma tarde descuidada anula de uma só vez a criptografia dos dois produtos.

Quando o KeePass é a resposta certa

Para quem esteja a avaliar especificamente se o KeePass chega para uma pequena equipa, o artigo Gestão de palavras-passe e de acessos para PMEs: O KeePass é suficiente? trata essa questão diretamente. Este artigo mantém-se mais restrito, apenas no eixo da arquitetura de cifragem, para equipas de qualquer dimensão.

Para uma só pessoa, ou para duas pessoas que, de qualquer forma, partilham tudo, o KeePass com uma base de dados KDBX 4 e parâmetros Argon2 sensatos é uma excelente escolha, e é gratuito. A criptografia é sólida, o formato está documentado publicamente e, sem servidor, não existe nenhum serviço a violar.

O modelo deixa de servir quando são necessárias respostas que um ficheiro não consegue dar. Quem tem acesso a isto, em concreto. O que exatamente se perdeu quando aquele portátil desapareceu. O que deixa de funcionar quando esta pessoa sai na sexta-feira. Provar que o prestador externo nunca viu credenciais de produção.

Um teste útil antes de decidir: contar quantas pessoas possuem hoje a chave mestra da base de dados partilhada e perguntar o que seria necessário rodar se qualquer uma delas saísse amanhã. Se a resposta for «tudo», não se trata de um problema de configuração que se resolva com ajustes. É o modelo de ficheiro a funcionar como concebido. A referência da hierarquia de chaves mostra como é o limite alternativo.

Um ficheiro tem uma chave para todos. Um modelo de cofres tem uma chave por cofre, encapsulada por pessoa. Essa diferença não diminui à medida que a equipa cresce; agrava-se. Se o KeePass não for a única alternativa na pré-seleção, a comparação entre as arquiteturas de cifragem de cofres do Passwork e do Bitwarden percorre os mesmos três momentos (gravações simultâneas, saída de colaboradores, auditoria) para um concorrente nativo da nuvem em vez de um formato de ficheiro.

Aplicar o teste da chave mestra à própria equipa e ver depois a alternativa. Iniciar um teste gratuito do Passwork.

Perguntas frequentes

É possível dar a uma pessoa acesso apenas a algumas entradas de um ficheiro KDBX?

Não do ponto de vista criptográfico. O KeePass documenta que não existem listas de controlo de acesso por grupo nem por entrada, e a leitura de qualquer entrada exige a chave mestra que decifra toda a base de dados. É possível restringir o acesso de escrita através das permissões do sistema de ficheiros.

O KeePass substitui as alterações de outras pessoas numa unidade partilhada?

O KeePass 2.x não. Verifica se o ficheiro foi alterado em disco antes de guardar, propõe sincronizar, funde ao nível da entrada e mantém a versão perdedora no histórico da entrada. Os conflitos são resolvidos pela data e hora da última modificação. O KeePass 1.x não tem sincronização e substitui efetivamente o ficheiro.

O que acontece quando sai um colaborador que tinha o ficheiro KDBX?

Qualquer cópia que já possua continua decifrável com a chave mestra com que foi guardada. Alterar a chave mestra afeta apenas as gravações futuras. Na prática, a revogação implica rodar todas as credenciais da base de dados, e o histórico das entradas nas cópias antigas continua a conter os valores anteriores.

É possível saber quem consultou uma credencial no KeePass?

Não. Não existe componente de servidor e, por conseguinte, registo de acessos, e uma chave mestra partilhada significa que as alterações também não podem ser atribuídas a um indivíduo. As datas e horas do KDBX e o histórico das entradas registam modificações, não leituras.

Qual é melhor para uma equipa, o KeePass ou o KeePassXC?

Nenhum foi concebido para a gestão de chaves de equipa, mas falham de formas diferentes. O KeePassXC exclui deliberadamente plugins e triggers (classifica os plugins como «inerentemente perigosos») e não tem sincronização na nuvem integrada, pelo que a resolução de conflitos fica a cargo do fornecedor de sincronização. O KeePass 2.x mantém os triggers, que é a forma como a sua documentação recomenda automatizar a sincronização de ficheiros partilhados, ao custo de um trigger num ficheiro de configuração não cifrado que se aplica a todos os utilizadores dessa instalação.