Encryption and cryptography

Os gestores de palavras-passe empresariais anunciam frequentemente a cifragem AES-256 e servidores que nunca veem as palavras-passe em texto não cifrado. No entanto, a força do algoritmo, por si só, não revela a quantidade de dados que uma única chave comprometida ou uma associação incorreta a um grupo pode expor.

Essa exposição depende do limite de cifragem: se uma chave desbloqueia uma organização, um cofre, uma pasta partilhada ou um segredo individual. Esta comparação analisa onde o Passwork, o Bitwarden, o Passbolt, o 1Password e o Keeper traçam esse limite, e o que os respetivos modelos significam para as permissões, o início de sessão por diretório, a automatização e a implementação.

A pergunta que revela o limite de cifragem

Imagine um gestor de palavras-passe autoalojado. Um administrador de sistemas responsável pelas cópias de segurança tem uma cópia da base de dados e junta-se à organização da empresa para aceder a uma palavra-passe partilhada. Que mais poderia decifrar com as chaves disponíveis na sua conta?

O Bitwarden cifra os itens da empresa com chaves por item, envolvidas por uma única chave simétrica da organização, de acordo com o seu white paper de segurança. Os membros da organização recebem acesso utilizável a essa chave, enquanto as coleções controlam o acesso e as permissões normais fornecidos pelo servidor, em vez de criarem limites criptográficos distintos. Num modelo de ameaça autoalojado, um atacante que obtenha os textos cifrados relevantes da base de dados e a chave de organização utilizável de um membro poderia decifrar itens da organização fora das coleções atribuídas a esse membro.

O Passwork, com a cifragem no lado do cliente ativada, utiliza uma chave distinta para cada cofre. As chaves dos itens situam-se sob as chaves dos cofres, e os utilizadores recebem uma chave de cofre envolvida apenas para os cofres a que têm acesso. Neste modelo de cifragem zero-knowledge, o mesmo administrador de sistemas consegue decifrar os cofres que lhe foram atribuídos, mas não cofres de Finanças ou Infraestrutura sem relação com a sua função.

O Passbolt cifra cada segredo separadamente para cada destinatário utilizando OpenPGP, conforme descrito na sua documentação de segurança (Pro v5.4, agosto de 2025). Não existe uma chave de contentor partilhada. Os utilizadores só conseguem decifrar os segredos cifrados para si, embora adicionar destinatários exija mais trabalho.

O 1Password isola os dados por cofre, onde as permissões também são definidas. O Keeper utiliza chaves de registo e chaves de pasta partilhada, em vez de uma única chave ao nível da organização. Nenhum dos dois oferece uma base de dados de cofre autoalojada para este teste em particular.

O Passwork e o Passbolt limitam o que uma cópia da base de dados, associada às chaves de um membro, pode revelar. O Bitwarden simplifica a distribuição de chaves, mas transforma a chave da organização num limite criptográfico mais amplo. Os produtos apenas na nuvem evitam este cenário específico de acesso à base de dados, embora a respetiva arquitetura de chaves continue a ser relevante.

Experimentar o Passwork gratuitamente para testar de que forma a estrutura dos cofres limita o acesso após o comprometimento de uma conta.

Tipos de cofre: Governação acima dos cofres individuais

No Passwork, um tipo de cofre define quem pode criar cofres numa determinada classe e quais os administradores atribuídos automaticamente aos novos cofres desse tipo. Com a cifragem no lado do cliente ativada, esses administradores também recebem cópias envolvidas das novas chaves de cofre. O resultado é uma política repetível para departamentos e projetos.

Por exemplo, um tipo Finanças pode atribuir automaticamente o diretor financeiro a cada novo cofre financeiro. Um tipo DevOps pode manter os administradores de infraestrutura separados das vendas. Quando o responsável de um departamento sai, a empresa pode reatribuir o administrador do tipo e rever as concessões de acesso dentro dessa área, em vez de auditar uma função de administrador global dispersa. Isto torna-se útil à medida que o número de equipas e de cofres aumenta. Consulte as políticas de cofres do Passwork.

Dois tipos incorporados dispensam administradores da empresa. Um cofre pessoal pertence a um único utilizador. Um cofre privado partilhado permite que esse utilizador convide outras pessoas. Por predefinição, nem o Proprietário nem o Administrador da organização conseguem ler o respetivo conteúdo. Os administradores podem configurar quem tem permissão para criar estes tipos de cofre e partilhar informação a partir deles, incluindo desativar a criação não gerida de cofres pessoais.

Existem dois limites: atribuir um tipo não concede acesso retroativo a cofres já existentes, e os tipos só formam limites criptográficos quando a cifragem no lado do cliente está ativada. Caso contrário, permanecem apenas regras de governação.

Os concorrentes oferecem funcionalidades relacionadas, mas não a mesma camada de política. As políticas empresariais do Bitwarden regem aspetos como a autenticação, a recuperação e a pertença à organização, em vez de atribuírem automaticamente administradores por classe de cofre. O Passbolt não tem um contentor de cofre para classificar. O 1Password oferece isolamento ao nível do cofre e cofres pessoais, mas nenhuma regra equivalente à escala da classe para cofres recém-criados. As pastas partilhadas e as equipas do Keeper gerem o acesso sem políticas de criação de cofres por tipo.

Os tipos de cofre reduzem a probabilidade de os cofres departamentais recém-criados receberem uma administração inconsistente. Acrescentam uma decisão de política antecipada, mas reduzem a configuração manual repetida mais tarde.

Permissões de pasta: Herança ou modelos?

Uma árvore de pastas só é útil se as respetivas permissões se comportarem conforme os administradores esperam. Interfaces com um aspeto semelhante podem aplicar regras muito diferentes.

O Passwork oferece cinco níveis de permissão (leitura, escrita, gestão, administração e proibido) para utilizadores e grupos ao nível do cofre ou da pasta. O acesso ao cofre propaga-se para as pastas aninhadas, enquanto as regras de pasta podem restringir o acesso. Os direitos de administração e de proibição não podem ser substituídos em níveis inferiores. Quando se aplicam várias regras, prevalece o nível de prioridade mais alta. É importante notar que uma pasta não constitui um limite de cifragem distinto: o acesso ao seu conteúdo continua a depender da chave do cofre. Isto está alinhado com o modelo de controlo de acesso baseado em funções do Passwork.

O Bitwarden concede permissões através de coleções. As coleções aninhadas são etiquetas organizacionais; não herdam os itens nem os direitos da coleção principal. As pastas pessoais não têm permissões de partilha. As permissões individuais de um membro sobrepõem-se às permissões de grupo.

O Passbolt utiliza as pastas como modelos de permissões. Quando um item é criado, movido ou partilhado, aplicam-se as permissões da pasta, mas são as permissões próprias do item que determinam o acesso subsequente. Um criador pode tornar-se proprietário de uma palavra-passe e restringir o acesso mesmo quando outra pessoa é proprietária da pasta. Numa discussão da comunidade em julho de 2026 sobre a extensão v5.14.2, o Passbolt confirmou que este comportamento segue o seu modelo de permissões e referiu que estava planeada uma alteração na interface para impedir que não proprietários editassem permissões durante a criação.

O 1Password não tem pastas com permissões próprias dentro de um cofre; as etiquetas organizam os itens sem alterar o acesso. Por isso, partilhar permanentemente um subconjunto de itens exige outro cofre. Os grupos aninhados do fornecedor de identidade não são suportados para a pertença a cofres, de acordo com uma resposta da comunidade de setembro de 2026.

O Keeper suporta pastas partilhadas aninhadas e permissões ao nível do registo. As atribuições explícitas de registos sobrepõem-se aos direitos de pasta herdados. O seu modelo de pastas aninhadas tem um limite de profundidade de cinco níveis e esteve protegido por uma feature flag na versão 18.0.0 do cofre.

A árvore do Passwork suporta estruturas departamentais e exceções. O Bitwarden e o 1Password são mais simples de administrar, mas menos flexíveis para acessos profundamente aninhados. O comportamento de modelo do Passbolt exige atenção especial, porque as permissões de pasta e de item podem divergir.

Grupos: O que muda quando alguém se junta?

Com a cifragem no lado do cliente do Passwork, adicionar alguém a um grupo não lhe concede automaticamente todas as chaves de cofre associadas a esse grupo. É criado, antes, um pedido pendente para cada cofre relevante. Um detentor da chave tem de aprovar o pedido antes de o novo membro conseguir decifrar o respetivo conteúdo.

Isto separa o aprovisionamento de diretório do acesso criptográfico. A sincronização LDAP pode colocar um novo colaborador em grupos, mas o acesso a cofres sensíveis continua a exigir aprovação. Esta distinção é relevante durante a integração e a saída de colaboradores.

Para equipas que necessitam de menos aprovação manual, o Passwork oferece outro padrão: colocar os dados do departamento num único cofre e organizá-los em pastas. Aprova-se a chave de cofre do utilizador uma única vez; as permissões de pasta determinam depois o acesso dentro desse cofre à medida que a pertença aos grupos muda. A contrapartida é um limite criptográfico partilhado mais amplo do que vários cofres separados.

O Passbolt não pode utilizar este atalho. Como cada segredo é cifrado para cada destinatário, adicionar um membro ao grupo exige que alguém com acesso recifre os segredos relevantes para esse utilizador. A sincronização de diretório notifica um gestor de grupo e aguarda por este passo. O trabalho escala com o número de segredos, e não com o número de cofres.

O Bitwarden já distribui a chave da organização aos membros, pelo que as atribuições de coleções não exigem novas chaves de cifragem. No 1Password, as chaves de cofre atribuídas acompanham o acesso de grupo. O Keeper distribui o acesso através de pastas partilhadas atribuídas.

A escolha está entre pontos de aprovação mais rigorosos e um aprovisionamento mais fluido. O Passwork permite que as organizações escolham equilíbrios diferentes para departamentos diferentes; o Passbolt oferece um controlo de acesso granular por segredo, a um custo de partilha mais elevado.

O que o início de sessão por domínio realmente faz

Uma palavra-passe de domínio autentica um utilizador; não decifra os dados do cofre em nenhum destes produtos. As diferenças residem na forma como a autenticação e o aprovisionamento por diretório funcionam.

Passwork Self-hosted autentica-se diretamente junto do LDAP ou do Active Directory, incluindo ambientes com vários controladores de domínio. Os utilizadores iniciam sessão com credenciais de domínio; os grupos de diretório podem ser associados a grupos do Passwork. Com a cifragem no lado do cliente ativada, a palavra-passe de domínio autentica a sessão, enquanto chaves criptográficas distintas protegem o conteúdo dos cofres.

O Passwork Cloud ainda não oferecia LDAP à data desta comparação; estava previsto no roteiro, juntamente com o aprovisionamento SCIM. Ambas as implementações do Passwork suportam SSO SAML 2.0.

O Bitwarden Directory Connector sincroniza utilizadores e grupos, mas não os autentica junto do LDAP, conforme explica a sua documentação. O início de sessão baseado em domínio exige SSO Enterprise através de SAML ou OIDC. Em condições normais, os utilizadores continuam a desbloquear o cofre com uma palavra-passe mestra, a menos que estejam configurados dispositivos fidedignos ou o Key Connector.

O Passbolt também separa a sincronização LDAP do início de sessão. Os utilizadores autenticam-se com uma chave privada e uma frase-passe, ou através de SSO, e adicionar utilizadores sincronizados a grupos com segredos existentes exige recifragem.

O 1Password e o Keeper utilizam serviços de cofre baseados na nuvem, com integração SSO. O SSO Connect On-Prem do Keeper pode manter determinados componentes de identidade no hardware da empresa, mas o seu backend de cofre cifrado permanece na nuvem do Keeper. O Keeper lista os componentes locais suportados na sua documentação de implementação.

O início de sessão direto por LDAP do Passwork pode simplificar implementações autoalojadas sem um fornecedor de identidade separado. Os concorrentes orientados para a nuvem oferecem atualmente um aprovisionamento automatizado de identidade mais maduro; as funcionalidades previstas do Passwork não devem ser consideradas disponíveis atualmente.

Uma única API para palavras-passe e segredos de máquina

O Passwork gere as credenciais dos colaboradores e os segredos de máquina através da mesma instância, do mesmo modelo de permissões, do mesmo registo de auditoria e da mesma API REST. As equipas podem suportar fluxos de trabalho de CI/CD sem licenciar um produto de segredos separado.

Os seus clientes Web, de ambiente de trabalho, de navegador e móvel utilizam a mesma API em /api/v1. Uma CLI oficial e um conector Python de código aberto suportam fluxos de trabalho de DevOps. A CLI disponibiliza get e update para registos, api para chamadas diretas a endpoints, e exec para obter e decifrar um segredo, expor os valores como variáveis de ambiente e executar um comando. As contas de serviço são utilizadores com tokens de API criados por um administrador. Gerar um novo token pessoal revoga as sessões de API anteriores do utilizador.

Este modelo unificado tem limitações: a API é baseada em pull, sem webhooks de saída, e o /v1/batch suporta apenas agregação de leitura, até 25 subpedidos GET. As integrações orientadas por eventos têm de efetuar polling ou consumir exportações de syslog.

Os concorrentes seguem abordagens diferentes. O Bitwarden Secrets Manager é um add-on pago separado, com contas de máquina e acesso baseado em projetos, em vez de acesso através das coleções do Password Manager. O Keeper Secrets Manager é outra linha de produtos, com SDKs e uma gateway ligada à nuvem. As contas de serviço do 1Password funcionam com cofres e permissões definidos, mas o respetivo âmbito é fixado no momento da criação do token; alterá-lo exige um novo token. O Passbolt expõe uma API e ferramentas de automatização, mantendo o seu modelo de partilha por segredo.

O Passwork privilegia um único sistema operacional para pessoas e automatização. Os produtos especializados em segredos podem oferecer integrações dedicadas, mas introduzem superfícies adicionais de licenciamento e gestão.

Onde o cofre é executado

A implementação pode eliminar produtos de uma lista restrita ainda antes de qualquer comparação de funcionalidades. O Passwork, o Bitwarden e o Passbolt permitem que as organizações alojem o próprio cofre. O 1Password e o Keeper mantêm o backend do cofre nos respetivos serviços na nuvem.

O Passwork suporta implementação local (on-premise) em Linux, Windows Server ou Docker, dando às organizações controlo sobre a sua infraestrutura e cópias de segurança. A sua oferta de nuvem alojada na UE utiliza uma base de dados e um tenant separados para cada cliente, em vez de armazenar os registos de todos os clientes num único esquema partilhado. Estas opções são discutidas no guia de modelos de implementação do Passwork.

O Bitwarden também oferece autoalojamento genuíno, embora a sua licença Enterprise continue associada a uma subscrição ativa na nuvem. O Passbolt suporta tanto o autoalojamento como um serviço alojado. Os componentes de SSO e de integração do Keeper, passíveis de implementação local, não alteram a localização do respetivo backend de cofre.

O autoalojamento dá às organizações controlo sobre a localização dos dados, mas também a responsabilidade pelas atualizações, pelas cópias de segurança e pela disponibilidade. Os produtos apenas na nuvem reduzem essa carga de trabalho, desde que a política permita o alojamento externo.

Cifragem opcional no lado do cliente e metadados

O Passwork Cloud utiliza sempre a cifragem no lado do cliente. O Passwork Self-hosted permite que os administradores a desativem. Os outros quatro produtos desta comparação não oferecem um controlo equivalente.

A cifragem no lado do servidor pode ser adequada para uma equipa pequena, com administradores de confiança, que privilegie a concessão imediata de acesso e uma recuperação mais simples. Desativar a cifragem no lado do cliente elimina o isolamento criptográfico por cofre: os tipos de cofre continuam a controlar a criação e a administração, mas deixam de formar limites de cifragem distintos.

Mesmo com a cifragem no lado do cliente ativada, o servidor do Passwork consegue ler nomes de itens, logins, descrições e URLs, para suportar a pesquisa no lado do servidor. Os valores das palavras-passe permanecem cifrados no cliente e fora do índice de pesquisa. O Bitwarden e o Keeper também cifram estes campos de metadados, mantendo-os ocultos do servidor, ao custo de uma decifragem no lado do cliente para a pesquisa. O Passbolt v5 deixa os nomes de pasta e as etiquetas sem cifragem.

Trata-se de uma contrapartida real entre segurança e usabilidade. Os compradores devem avaliar tanto a confidencialidade das palavras-passe como a exposição de metadados, especialmente quando os registos contêm nomes de sistemas sensíveis ou identificadores de conta.

Quanto custa

Estes são os preços de tabela publicados por utilizador, por mês, com faturação anual, a partir de outubro de 2026. Os fornecedores utilizam moedas e pacotes diferentes, pelo que a comparação é apenas indicativa.

O Passwork Padrão custa 3 € e o Avançado 4,50 € por utilizador, por mês. O Avançado inclui gestão de segredos e funcionalidades de identidade empresarial. Os clientes autoalojados também podem optar por uma licença vitalícia paga uma única vez. O Bitwarden Teams custa 4 $ e o Enterprise 6 $, com o Secrets Manager cobrado separadamente a 6 $ e 12 $, respetivamente. O Keeper Business parte de 4 $ e o Enterprise de 6 $, enquanto o KeeperPAM é cobrado separadamente. O 1Password Business custa 8,99 $. O Passbolt Pro autoalojado custa 4,50 € com um mínimo de dez utilizadores.

O Bitwarden Secrets Manager custa 6 $ por utilizador, por mês, no Teams, ou 12 $ no Enterprise, cobrado separadamente do Password Manager. As organizações que utilizam ambos os produtos devem comparar os custos de licenciamento combinados com base no número de utilizadores em cada um. O Passwork Avançado inclui a gestão de palavras-passe e de segredos numa única subscrição. O modelo de cifragem por segredo do Passbolt acrescenta trabalho administrativo ao partilhar segredos ou ao adicionar membros a grupos, um custo que os preços de subscrição, por si só, não conseguem captar.

Onde os concorrentes levam vantagem

O Passbolt oferece partilha e revogação diretas por segredo. Cada destinatário recebe um texto cifrado com a respetiva chave pública. A revogação remove do serviço a cópia cifrada desse destinatário. Isto permite um controlo granular, mas cada destinatário adicional exige trabalho de cifragem e de armazenamento. Tal como noutros gestores de palavras-passe, a revogação não consegue apagar o texto não cifrado nem as cópias que um destinatário já tenha guardado.

O Passwork armazena um único texto cifrado partilhado e distribui chaves envolvidas, em vez de duplicar cada segredo para cada destinatário. Remover uma concessão permanente de cofre ou de pasta remove o acesso à chave correspondente. A sua caixa de entrada funciona de forma diferente: uma entrega direta entre utilizadores envolve a chave de um item para o destinatário, e um item aceite torna-se uma cópia no cofre do destinatário. A entrega por caixa de entrada de grupo utiliza um percurso sem cifragem no lado do cliente. A caixa de entrada é, portanto, uma transferência, e não uma concessão permanentemente revogável.

O Bitwarden e o Keeper protegem metadados que o Passwork expõe para a pesquisa no lado do servidor. O Keeper também oferece atalhos de registo e permissões diretas por registo em pastas partilhadas, além de uma plataforma mais ampla de acesso privilegiado. O 1Password tem menos regras de herança e exceções, o que facilita a configuração para equipas que não necessitam de permissões de pasta complexas. O Bitwarden combina um preço de entrada baixo, autoalojamento e clientes consolidados.

Estas são vantagens substanciais. A flexibilidade do Passwork ajuda organizações com estruturas de acesso complexas, mas também cria mais políticas para conceber e manter.

Como escolher: Comece pelo limite

Comece pelo cenário de falha, e não pelo algoritmo de cifragem. Se uma conta for comprometida, que registos conseguem as suas chaves decifrar? O que muda se o atacante também obtiver uma cópia de segurança da base de dados? Depois, verifique se o modelo de permissões reflete os limites departamentais e se a integração de colaboradores pode expandir o acesso por acidente.

O Passwork é adequado a organizações que necessitem de cofres departamentais separados, permissões de pasta herdadas, autenticação LDAP direta on-premise, e credenciais de colaboradores e de máquina num único sistema. O Passbolt favorece o controlo por segredo nos casos em que o custo administrativo da partilha é aceitável. O Bitwarden oferece uma distribuição de chaves simples, à escala da organização, e autoalojamento. O 1Password minimiza a complexidade de configuração num modelo centrado na nuvem. O Keeper combina controlos de pasta partilhada com uma oferta mais ampla de acesso privilegiado.

Se Finanças, Recursos Humanos e Infraestrutura forem unidades operacionais separadas, decida se também devem ter limites criptográficos separados. Essa decisão determina a potencial exposição de uma única chave comprometida de forma mais direta do que um rótulo AES-256.

Testar o Passwork na infraestrutura da organização e comparar o que uma conta comprometida poderia decifrar em cada sistema candidato.

Perguntas frequentes

Políticas de cofres do Passwork: um guia para CIOs sobre segurança empresarial

Os Tipos de Cofre do Passwork associam os direitos de administrador à própria política do cofre, e não a quem o criou, fechando uma lacuna que a maioria das empresas nem sequer sabe que existe. Este guia oferece a CIOs e CISOs um modelo de trabalho para a governação de cofres, alinhado com os requisitos da NIS2 e da ISO 27001.

PassworkPasswork Team

Passwork vs KeePass: Em que difere a arquitetura de cifragem

A criptografia do KeePass é genuinamente forte. A sua gestão de chaves para equipas não é. Aqui fica onde um ficheiro KDBX partilhado falha (ao guardar, na saída de colaboradores, na auditoria) e o que uma chave por cofre muda.

PassworkPasswork Team

Passwork vs Bitwarden: Em que difere a arquitetura de cifragem dos cofres

O Passwork cifra cada cofre com a sua própria chave. O Bitwarden cifra toda uma organização com uma única chave partilhada. Esta comparação analisa o que isso significa para o raio de impacto, o isolamento de equipas, a recuperação de contas e as respostas de auditoria quando uma credencial é exposta.

PassworkPasswork Team

Business-Passwortmanager werben häufig mit AES-256-Verschlüsselung und Servern, die niemals Passwörter im Klartext sehen. Doch die Stärke der Chiffre allein sagt nichts darüber aus, wie viele Daten ein kompromittierter Schlüssel oder eine falsch zugewiesene Gruppenmitgliedschaft offenlegen können.

Wie weit diese Offenlegung reicht, hängt von der Verschlüsselungsgrenze ab: ob ein Schlüssel eine Organisation, einen Tresor, einen gemeinsam genutzten Ordner oder ein einzelnes Secret entsperrt. Dieser Vergleich untersucht, wo Passwork, Bitwarden, Passbolt, 1Password und Keeper diese Grenze ziehen und was ihre Architektur für Berechtigungen, Verzeichnisanmeldung, Automatisierung und Bereitstellung bedeutet.

Die Frage, die die Verschlüsselungsgrenze offenlegt

Stellen Sie sich einen selbst gehosteten Passwortmanager vor. Ein für Backups zuständiger Systemadministrator besitzt einen Datenbank-Dump und tritt der Unternehmensorganisation bei, um auf ein gemeinsam genutztes Passwort zuzugreifen. Was könnte er mit den seinem Konto zur Verfügung stehenden Schlüsseln noch entschlüsseln?

Bitwarden verschlüsselt Unternehmenselemente laut seinem Security-Whitepaper mit Einzelschlüsseln pro Element, die von einem symmetrischen Organisationsschlüssel umschlossen werden. Organisationsmitglieder erhalten nutzbaren Zugriff auf diesen Schlüssel, während Collections den regulären, vom Server bereitgestellten Zugriff und die Berechtigungen steuern, anstatt eigene kryptografische Grenzen zu schaffen. In einem Bedrohungsmodell für selbst gehostete Instanzen könnte ein Angreifer, der an die relevanten Datenbank-Chiffretexte und den nutzbaren Organisationsschlüssel eines Mitglieds gelangt, Organisationselemente außerhalb der diesem Mitglied zugewiesenen Collections entschlüsseln.

Passwork verwendet bei aktivierter clientseitiger Verschlüsselung für jeden Tresor einen eigenen Schlüssel. Element-Schlüssel liegen unterhalb der Tresor-Schlüssel, und Benutzer erhalten einen umschlossenen Tresor-Schlüssel nur für Tresore, auf die sie zugreifen dürfen. In diesem Zero-Knowledge-Verschlüsselungsmodell kann derselbe Systemadministrator seine zugewiesenen Tresore entschlüsseln, nicht aber unzusammenhängende Finanz- oder Infrastruktur-Tresore.

Passbolt verschlüsselt laut seiner Sicherheitsdokumentation (Pro v5.4, August 2025) jedes Secret mit OpenPGP separat für jeden Empfänger. Es gibt keinen gemeinsamen Container-Schlüssel. Benutzer können nur Secrets entschlüsseln, die für sie verschlüsselt wurden, auch wenn das Hinzufügen von Empfängern mehr Aufwand bedeutet.

1Password isoliert Daten nach Tresor, wo auch die Berechtigungen festgelegt werden. Keeper verwendet Eintrags-Schlüssel und Schlüssel für gemeinsam genutzte Ordner anstelle eines einzigen organisationsweiten Schlüssels. Für diesen speziellen Test bietet keines der beiden Produkte eine selbst gehostete Tresor-Datenbank an.

Passwork und Passbolt begrenzen, was ein Datenbank-Dump zusammen mit den Schlüsseln eines einzelnen Mitglieds offenlegen kann. Bitwarden vereinfacht die Schlüsselverteilung, macht den Organisationsschlüssel aber zu einer breiteren kryptografischen Grenze. Die reinen Cloud-Produkte umgehen dieses spezielle Datenbankzugriffsszenario, auch wenn ihre Schlüsselarchitektur weiterhin relevant ist.

Kostenlose Passwork-Testversion starten, um zu testen, wie Ihre Tresorstruktur den Zugriff nach einer Konto-Kompromittierung einschränkt.

Tresortypen: Governance oberhalb einzelner Tresore

In Passwork legt ein Tresortyp fest, wer Tresore einer bestimmten Klasse erstellen darf und welche Administratoren neuen Tresoren dieses Typs automatisch zugewiesen werden. Bei aktivierter clientseitiger Verschlüsselung erhalten diese Administratoren zusätzlich umschlossene Kopien der neuen Tresor-Schlüssel. Das Ergebnis ist eine wiederholbare Richtlinie für Abteilungen und Projekte.

Zum Beispiel kann ein Finance-Typ den CFO automatisch jedem neuen Finanz-Tresor zuweisen. Ein DevOps-Typ kann Infrastruktur-Administratoren getrennt vom Vertrieb halten. Verlässt eine Abteilungsleitung das Unternehmen, kann das Unternehmen den Typ-Administrator neu zuweisen und die Berechtigungen in diesem Bereich überprüfen, anstatt eine unübersichtliche globale Administratorrolle zu prüfen. Das wird mit wachsender Team- und Tresoranzahl nützlich. Mehr zu den Tresor-Richtlinien von Passwork.

Zwei integrierte Typen kommen ohne Unternehmens-Administratoren aus. Ein persönlicher Tresor gehört einem einzelnen Benutzer. Ein privater gemeinsam genutzter Tresor erlaubt diesem Benutzer, andere einzuladen. Standardmäßig können selbst der Besitzer oder Admin der Organisation deren Inhalte nicht lesen. Administratoren können festlegen, wer diese Tresortypen erstellen und Informationen daraus freigeben darf, einschließlich der Möglichkeit, die unkontrollierte Erstellung persönlicher Tresore zu deaktivieren.

Es gibt zwei Einschränkungen: Das Zuweisen eines Typs gewährt keinen rückwirkenden Zugriff auf bestehende Tresore, und Typen bilden nur bei aktivierter clientseitiger Verschlüsselung kryptografische Grenzen. Andernfalls bleiben sie reine Governance-Regeln.

Die Wettbewerber bieten verwandte Funktionen, aber keine vergleichbare Richtlinienebene. Bitwardens Enterprise-Richtlinien regeln Aspekte wie Authentifizierung, Wiederherstellung und Organisationsmitgliedschaft, weisen aber keine Administratoren automatisch nach Tresortyp zu. Passbolt besitzt keinen Tresor-Container, der klassifiziert werden könnte. 1Password bietet Isolation auf Tresorebene und persönliche Tresore, aber keine vergleichbare typweite Regel für neu erstellte Tresore. Keepers gemeinsam genutzte Ordner und Teams verwalten den Zugriff ohne typisierte Richtlinien zur Tresorerstellung.

Tresortypen verringern das Risiko, dass neu erstellte Abteilungstresore uneinheitlich administriert werden. Sie erfordern eine Richtlinienentscheidung im Vorfeld, reduzieren aber spätere wiederholte manuelle Konfiguration.

Ordnerberechtigungen: Vererbung oder Vorlagen?

Eine Ordnerstruktur ist nur dann nützlich, wenn sich ihre Berechtigungen so verhalten, wie Administratoren es erwarten. Ähnlich aussehende Oberflächen können sehr unterschiedliche Regeln durchsetzen.

Passwork bietet für Benutzer und Gruppen auf Tresor- oder Ordnerebene fünf Berechtigungsstufen: Lesen, Schreiben, Verwalten, Admin und Verboten. Der Tresorzugriff vererbt sich auf verschachtelte Ordner, während Ordnerregeln den Zugriff einschränken können. Admin- und Verboten-Rechte können weiter unten nicht überschrieben werden. Gelten mehrere Regeln gleichzeitig, setzt sich die Stufe mit höherer Priorität durch. Wichtig: Ein Ordner bildet keine eigene Verschlüsselungsgrenze – der Zugriff auf seine Inhalte hängt weiterhin vom Tresor-Schlüssel ab. Dies ergänzt Passworks Modell der rollenbasierten Zugriffskontrolle.

Bitwarden vergibt Berechtigungen über Collections. Verschachtelte Collections sind organisatorische Kennzeichnungen; sie erben weder die Elemente noch die Rechte der übergeordneten Collection. Persönliche Ordner besitzen keine Freigabeberechtigungen. Individuelle Mitgliederberechtigungen überschreiben Gruppenberechtigungen.

Passbolt verwendet Ordner als Berechtigungsvorlagen. Wird ein Element erstellt, verschoben oder freigegeben, gelten zunächst die Berechtigungen des Ordners; anschließend bestimmen die eigenen Berechtigungen des Elements den weiteren Zugriff. Ein Ersteller kann Besitzer eines Passworts werden und den Zugriff einschränken, selbst wenn jemand anderes Besitzer des Ordners ist. In einer Community-Diskussion vom Juli 2026 zur Erweiterung v5.14.2 bestätigte Passbolt, dass dieses Verhalten seinem Berechtigungsmodell entspricht, und kündigte eine geplante UI-Änderung an, die verhindern soll, dass Nicht-Besitzer während der Erstellung Berechtigungen bearbeiten.

1Password besitzt innerhalb eines Tresors keine berechtigungstragenden Ordner; Tags organisieren Elemente, ohne den Zugriff zu verändern. Um eine Teilmenge von Elementen dauerhaft freizugeben, ist daher ein weiterer Tresor erforderlich. Laut einer Community-Antwort vom September 2026 werden verschachtelte Identity-Provider-Gruppen für die Tresormitgliedschaft nicht unterstützt.

Keeper unterstützt verschachtelte gemeinsam genutzte Ordner und Berechtigungen auf Eintragsebene. Explizite Eintragszuweisungen überschreiben vererbte Ordnerrechte. Sein Modell verschachtelter Ordner ist auf fünf Ebenen begrenzt und war in Tresor-Release 18.0.0 hinter einem Feature-Flag verborgen.

Passworks Struktur unterstützt Abteilungsgliederungen und Ausnahmen. Bitwarden und 1Password sind einfacher zu administrieren, aber weniger flexibel bei tief verschachteltem Zugriff. Passbolts Vorlagenverhalten erfordert besondere Aufmerksamkeit, da Ordner- und Elementberechtigungen voneinander abweichen können.

Gruppen: Was ändert sich, wenn jemand beitritt?

Bei aktivierter clientseitiger Verschlüsselung in Passwork erhält eine Person, die einer Gruppe hinzugefügt wird, nicht automatisch alle mit dieser Gruppe verknüpften Tresor-Schlüssel. Stattdessen entsteht für jeden betroffenen Tresor eine ausstehende Anfrage. Ein Schlüsselinhaber muss die Anfrage genehmigen, bevor das neue Mitglied die Inhalte entschlüsseln kann.

Damit werden Verzeichnis-Provisioning und kryptografischer Zugriff getrennt. Die LDAP-Synchronisierung kann einen neuen Mitarbeiter in Gruppen aufnehmen, doch der Zugriff auf sensible Tresore erfordert weiterhin eine Genehmigung. Diese Unterscheidung ist bei Onboarding und Offboarding relevant.

Für Teams, die weniger manuelle Genehmigungen benötigen, bietet Passwork ein weiteres Muster: Die Daten der Abteilung in einem Tresor ablegen und in Ordnern organisieren. Der Tresor-Schlüssel des Benutzers wird einmalig genehmigt; Ordnerberechtigungen bestimmen anschließend den Zugriff innerhalb dieses Tresors, wenn sich die Gruppenmitgliedschaft ändert. Der Kompromiss ist eine breitere gemeinsam genutzte kryptografische Grenze als bei mehreren getrennten Tresoren.

Passbolt kann diese Abkürzung nicht nutzen. Da jedes Secret für jeden Empfänger einzeln verschlüsselt wird, muss jemand mit Zugriff die betreffenden Secrets für das neue Mitglied neu verschlüsseln, wenn eine Gruppe erweitert wird. Die Verzeichnissynchronisierung benachrichtigt einen Gruppenverantwortlichen und wartet auf diesen Schritt. Der Aufwand skaliert mit der Anzahl der Secrets, nicht mit der Anzahl der Tresore.

Bitwarden verteilt den Organisationsschlüssel bereits an die Mitglieder, sodass Collection-Zuweisungen keine neuen Verschlüsselungsschlüssel erfordern. Bei 1Password folgen zugewiesene Tresor-Schlüssel dem Gruppenzugriff. Keeper verteilt den Zugriff über zugewiesene gemeinsam genutzte Ordner.

Die Wahl besteht zwischen strengeren Genehmigungsschritten und reibungsloserem Provisioning. Passwork erlaubt es Organisationen, für unterschiedliche Abteilungen unterschiedliche Gewichtungen zu wählen; Passbolt bietet feingranularen Zugriff pro Secret zu einem höheren Freigabeaufwand.

Was die Domänenanmeldung tatsächlich bewirkt

Ein Domänenpasswort authentifiziert einen Benutzer; es entschlüsselt in keinem dieser Produkte Tresordaten. Die Unterschiede liegen darin, wie Verzeichnisauthentifizierung und Provisioning funktionieren.

Passwork Self-hosted authentifiziert direkt gegen LDAP oder Active Directory, auch in Umgebungen mit mehreren Domänencontrollern. Benutzer melden sich mit ihren Domänen-Zugangsdaten an; Verzeichnisgruppen lassen sich auf Passwork-Gruppen abbilden. Bei aktivierter clientseitiger Verschlüsselung authentifiziert das Domänenpasswort die Sitzung, während separate kryptografische Schlüssel die Tresorinhalte schützen.

Passwork Cloud bot zum Zeitpunkt dieses Vergleichs noch kein LDAP an; es stand zusammen mit SCIM-Provisioning auf der Roadmap. Beide Passwork-Bereitstellungen unterstützen SAML-2.0-SSO.

Bitwarden Directory Connector synchronisiert Benutzer und Gruppen, authentifiziert sie laut Dokumentation jedoch nicht gegen LDAP. Eine domänenbasierte Anmeldung erfordert Enterprise-SSO über SAML oder OIDC. Benutzer entsperren ihren Tresor normalerweise weiterhin mit einem Masterpasswort, sofern nicht Trusted Devices oder Key Connector konfiguriert sind.

Passbolt trennt ebenfalls LDAP-Synchronisierung und Anmeldung. Benutzer authentifizieren sich mit einem privaten Schlüssel und einer Passphrase oder per SSO, und das Hinzufügen synchronisierter Benutzer zu Gruppen mit bestehenden Secrets erfordert eine Neuverschlüsselung.

1Password und Keeper nutzen cloudbasierte Tresordienste mit SSO-Integration. Keepers SSO Connect On-Prem kann bestimmte Identitätskomponenten auf unternehmenseigener Hardware belassen, doch das verschlüsselte Tresor-Backend verbleibt in Keepers Cloud. Keeper listet die unterstützten lokalen Komponenten in seiner Bereitstellungsdokumentation auf.

Passworks direkte LDAP-Anmeldung kann selbst gehostete Bereitstellungen ohne separaten Identity-Provider vereinfachen. Cloud-first ausgerichtete Wettbewerber bieten derzeit ein ausgereifteres automatisiertes Identity-Provisioning; geplante Passwork-Funktionen sollten nicht als bereits verfügbar betrachtet werden.

Eine API für Passwörter und Machine Secrets

Passwork verwaltet Mitarbeiter-Zugangsdaten und Machine Secrets über dieselbe Instanz, dasselbe Berechtigungsmodell, dasselbe Audit-Log und dieselbe REST-API. Teams können CI/CD-Workflows unterstützen, ohne ein separates Secrets-Produkt lizenzieren zu müssen.

Die Web-, Desktop-, Browser- und Mobil-Clients nutzen dieselbe API unter /api/v1. Eine offizielle CLI und ein Open-Source-Python-Connector unterstützen DevOps-Workflows. Die CLI bietet get und update für Einträge, api für direkte Endpunktaufrufe sowie exec, um ein Secret abzurufen und zu entschlüsseln, die Werte als Umgebungsvariablen bereitzustellen und einen Befehl auszuführen. Servicekonten sind Benutzer mit von einem Administrator erstellten API-Tokens. Das Erzeugen eines neuen persönlichen Tokens widerruft die vorherigen API-Sitzungen des Benutzers.

Dieses einheitliche Modell hat Grenzen: Die API ist pull-basiert, es gibt keine ausgehenden Webhooks, und /v1/batch unterstützt nur lesende Aggregation mit bis zu 25 GET-Teilanfragen. Ereignisgesteuerte Integrationen müssen pollen oder Syslog-Exporte konsumieren.

Die Wettbewerber verfolgen andere Ansätze. Bitwarden Secrets Manager ist ein separates kostenpflichtiges Add-on mit Machine Accounts und projektbasiertem Zugriff anstelle des Zugriffs über Password-Manager-Collections. Keeper Secrets Manager ist eine eigene Produktlinie mit SDKs und einem cloudverbundenen Gateway. Die Servicekonten von 1Password arbeiten mit festgelegten Tresoren und Berechtigungen, doch ihr Geltungsbereich wird bei der Erstellung eines Tokens fixiert; eine Änderung erfordert ein neues Token. Passbolt bietet eine API und Automatisierungswerkzeuge, behält dabei aber sein Freigabemodell pro Secret bei.

Passwork setzt auf ein einziges operatives System für Mitarbeiter und Automatisierung. Spezialisierte Secrets-Produkte können dedizierte Integrationen bieten, bringen aber zusätzliche Lizenzierungs- und Verwaltungsebenen mit sich.

Wo der Tresor läuft

Die Bereitstellungsart kann Produkte schon vor jedem Funktionsvergleich von einer Auswahlliste ausschließen. Passwork, Bitwarden und Passbolt erlauben Organisationen, den Tresor selbst zu hosten. 1Password und Keeper belassen das Tresor-Backend in ihren eigenen Cloud-Diensten.

Passwork unterstützt eine On-Premise-Bereitstellung auf Linux, Windows Server oder Docker und gibt Organisationen so die Kontrolle über Infrastruktur und Backups. Das in der EU gehostete Cloud-Angebot verwendet für jeden Kunden eine separate Datenbank und einen eigenen Tenant, anstatt alle Kundendaten in einem gemeinsamen Schema zu speichern. Diese Optionen werden im Leitfaden zu Bereitstellungsmodellen von Passwork erläutert.

Bitwarden bietet ebenfalls echtes Self-Hosting an, wobei die Enterprise-Lizenz weiterhin an ein aktives Cloud-Abonnement gebunden ist. Passbolt unterstützt sowohl Self-Hosting als auch einen gehosteten Dienst. Keepers lokal bereitstellbare SSO- und Integrationskomponenten ändern nichts am Standort des Tresor-Backends.

Self-Hosting gibt Organisationen die Kontrolle über den Datenstandort, überträgt ihnen aber auch die Verantwortung für Updates, Backups und Verfügbarkeit. Reine Cloud-Produkte reduzieren diesen Aufwand, sofern die eigenen Richtlinien ein externes Hosting zulassen.

Optionale clientseitige Verschlüsselung und Metadaten

Passwork Cloud verwendet stets clientseitige Verschlüsselung. Bei selbst gehostetem Passwork können Administratoren sie deaktivieren. Die übrigen vier Produkte dieses Vergleichs bieten keine vergleichbare Option.

Serverseitige Verschlüsselung kann sich für ein kleines Team mit vertrauenswürdigen Administratoren eignen, dem sofortige Zugriffsvergabe und eine einfachere Wiederherstellung wichtiger sind. Das Deaktivieren der clientseitigen Verschlüsselung hebt die kryptografische Isolation pro Tresor auf: Tresortypen steuern weiterhin Erstellung und Administration, bilden aber keine eigenen Verschlüsselungsgrenzen mehr.

Selbst bei aktivierter clientseitiger Verschlüsselung kann der Passwork-Server Elementnamen, Logins, Beschreibungen und URLs lesen, um die serverseitige Suche zu unterstützen. Passwortwerte bleiben clientseitig verschlüsselt und außerhalb des Suchindex. Bitwarden und Keeper verschlüsseln auch diese Metadatenfelder und halten sie so vor dem Server verborgen – auf Kosten einer clientseitigen Entschlüsselung für die Suche. Passbolt v5 lässt Ordnernamen und Tags unverschlüsselt.

Das ist ein echter Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit. Käufer sollten sowohl die Vertraulichkeit der Passwörter als auch die Offenlegung von Metadaten bewerten, besonders wenn Einträge sensible Systemnamen oder Kontokennungen enthalten.

Was es kostet

Dies sind veröffentlichte Listenpreise pro Benutzer und Monat bei jährlicher Abrechnung, Stand Oktober 2026. Die Anbieter verwenden unterschiedliche Währungen und Paketierungen, weshalb der Vergleich nur eine grobe Orientierung bietet.

Passwork Standard kostet 3 €, Advanced 4,50 € pro Benutzer und Monat. Advanced umfasst Secrets-Management und Enterprise-Identitätsfunktionen. Self-hosted-Kunden können außerdem eine einmalige Lifetime-Lizenz wählen. Bitwarden Teams kostet 4 $, Enterprise 6 $, wobei der Secrets Manager separat mit 6 $ beziehungsweise 12 $ berechnet wird. Keeper Business startet bei 4 $, Enterprise bei 6 $, während KeeperPAM separat berechnet wird. 1Password Business kostet 8,99 $. Passbolt Pro Self-hosted kostet 4,50 € bei einem Mindestumfang von zehn Benutzern.

Der Bitwarden Secrets Manager kostet 6 $ pro Benutzer und Monat im Tarif Teams beziehungsweise 12 $ im Tarif Enterprise und wird separat vom Password Manager abgerechnet. Organisationen, die beide Produkte nutzen, sollten die kombinierten Lizenzkosten anhand der jeweiligen Benutzerzahl vergleichen. Passwork Advanced vereint Passwort- und Secrets-Management in einem Abonnement. Passbolts Verschlüsselungsmodell pro Secret erzeugt zusätzlichen administrativen Aufwand beim Freigeben von Secrets oder beim Hinzufügen von Gruppenmitgliedern – ein Kostenfaktor, den die Abonnementpreise allein nicht abbilden.

Wo Wettbewerber im Vorteil sind

Passbolt ermöglicht direkte Freigabe und direkten Entzug pro Secret. Jeder Empfänger erhält einen mit seinem öffentlichen Schlüssel verschlüsselten Chiffretext. Ein Entzug entfernt die verschlüsselte Kopie dieses Empfängers aus dem Dienst. Das ermöglicht feingranulare Kontrolle, erfordert aber für jeden zusätzlichen Empfänger Verschlüsselungs- und Speicheraufwand. Wie bei anderen Passwortmanagern kann ein Entzug keinen Klartext oder zuvor vom Empfänger gespeicherte Kopien löschen.

Passwork speichert einen einzigen gemeinsam genutzten Chiffretext und verteilt umschlossene Schlüssel, anstatt jedes Secret für jeden Empfänger zu duplizieren. Das Entfernen einer dauerhaften Tresor- oder Ordnerfreigabe entzieht den entsprechenden Schlüsselzugriff. Der Posteingang funktioniert anders: Eine direkte Übergabe zwischen Benutzern umschließt den Schlüssel eines Elements für den Empfänger, und ein akzeptiertes Element wird zu einer Kopie im Tresor des Empfängers. Die Zustellung an einen Gruppen-Posteingang nutzt einen Pfad ohne clientseitige Verschlüsselung. Der Posteingang ist daher eine Übertragung und keine dauerhaft widerrufbare Freigabe.

Bitwarden und Keeper schützen Metadaten, die Passwork für die serverseitige Suche offenlegt. Keeper bietet außerdem Eintrags-Shortcuts und direkte Berechtigungen pro Eintrag in gemeinsam genutzten Ordnern sowie eine breitere Privileged-Access-Plattform. 1Password hat weniger Vererbungsregeln und Ausnahmen, wodurch es sich leichter für Teams konfigurieren lässt, die keine komplexen Ordnerberechtigungen benötigen. Bitwarden verbindet einen niedrigen Einstiegspreis, Self-Hosting und etablierte Clients.

Das sind handfeste Vorteile. Passworks Flexibilität hilft Organisationen mit komplexen Zugriffsstrukturen, schafft aber auch mehr Richtlinien, die entworfen und gepflegt werden müssen.

Die richtige Wahl: Bei der Grenze beginnen

Beginnen Sie mit dem Schadensszenario, nicht mit dem Verschlüsselungsalgorithmus. Welche Einträge können die Schlüssel eines kompromittierten Kontos entschlüsseln? Was ändert sich, wenn der Angreifer zusätzlich ein Datenbank-Backup erhält? Prüfen Sie anschließend, ob Ihr Berechtigungsmodell die Abteilungsgrenzen widerspiegelt und ob Onboarding den Zugriff unbeabsichtigt erweitern kann.

Passwork eignet sich für Organisationen, die separate Abteilungstresore, vererbte Ordnerberechtigungen, direkte LDAP-Authentifizierung vor Ort sowie Mitarbeiter- und Machine-Zugangsdaten in einem System benötigen. Passbolt bevorzugt Kontrolle pro Secret dort, wo der administrative Aufwand der Freigabe vertretbar ist. Bitwarden bietet unkomplizierte organisationsweite Schlüsselverteilung und Self-Hosting. 1Password minimiert die Konfigurationskomplexität in einem Cloud-first-Modell. Keeper verbindet Kontrollen für gemeinsam genutzte Ordner mit einem breiteren Privileged-Access-Angebot.

Wenn Finance, HR und Infrastruktur getrennte operative Einheiten sind, entscheiden Sie, ob sie auch getrennte kryptografische Grenzen haben sollten. Diese Entscheidung bestimmt die potenzielle Offenlegung durch einen kompromittierten Schlüssel direkter als ein AES-256-Label.

Passwork in Ihrer Infrastruktur testen und vergleichen, was ein kompromittiertes Konto in jedem der betrachteten Systeme entschlüsseln könnte.

Häufig gestellte Fragen

Passworks Tresor-Richtlinien: Ein Leitfaden für CIOs zur Unternehmenssicherheit

Passworks Tresortypen binden Administratorrechte an die Tresor-Richtlinie selbst statt an die Person, die den Tresor angelegt hat, und schließen damit eine Lücke, deren Existenz die meisten Unternehmen gar nicht kennen. Dieser Leitfaden bietet CIOs und CISOs ein praxistaugliches Modell für Tresor-Governance, abgestimmt auf die Anforderungen von NIS2 und ISO 27001.

PassworkPasswork Team

Passwork vs. KeePass: Wie sich die Verschlüsselungsarchitektur unterscheidet

Die Kryptografie von KeePass ist wirklich stark. Sein Schlüsselmanagement für Teams dagegen nicht. Hier zeigt sich, wo eine gemeinsam genutzte KDBX-Datei versagt – beim Speichern, beim Offboarding, beim Audit – und was ein Schlüssel pro Tresor daran ändert.

PassworkPasswork Team

Passwork vs. Bitwarden: Wie sich die Verschlüsselungsarchitektur der Tresore unterscheidet

Passwork verschlüsselt jeden Tresor mit einem eigenen Schlüssel. Bitwarden verschlüsselt eine gesamte Organisation mit einem einzigen gemeinsamen Schlüssel. Dieser Vergleich zeigt, was das für Blast Radius, Team-Isolation, Kontowiederherstellung und Audit-Antworten bedeutet, wenn Zugangsdaten durchsickern.

PassworkPasswork Team

Los gestores de contraseñas empresariales suelen destacar el cifrado AES-256 y servidores que nunca ven las contraseñas en texto claro. Pero la fortaleza del cifrado por sí sola no indica cuántos datos puede exponer una clave comprometida o una membresía de grupo incorrecta.

Esa exposición depende del límite de cifrado: si una clave desbloquea una organización, una bóveda, una carpeta compartida o un secreto individual. Esta comparación analiza dónde trazan ese límite Passwork, Bitwarden, Passbolt, 1Password y Keeper, y qué implican sus diseños para los permisos, el inicio de sesión mediante directorio, la automatización y la implementación.

La pregunta que revela el límite de cifrado

Imagine un gestor de contraseñas autoalojado. Un administrador de sistemas responsable de las copias de seguridad dispone de un volcado de la base de datos y se une a la organización corporativa para acceder a una contraseña compartida. ¿Qué más podría descifrar con las claves disponibles en su cuenta?

Bitwarden cifra los elementos corporativos con claves por elemento envueltas por una única clave simétrica de la organización, según su documento técnico de seguridad. Los miembros de la organización reciben acceso utilizable a esa clave, mientras que las colecciones controlan el acceso y los permisos habituales entregados por el servidor, en lugar de crear límites criptográficos independientes. En un modelo de amenazas autoalojado, un atacante que obtenga los textos cifrados pertinentes de la base de datos y la clave utilizable de la organización de un miembro podría descifrar elementos de la organización fuera de las colecciones asignadas a ese miembro.

Passwork, con el cifrado del lado del cliente activado, utiliza una clave independiente para cada bóveda. Las claves de los elementos se sitúan bajo las claves de bóveda, y los usuarios reciben una clave de bóveda envuelta únicamente para las bóvedas a las que tienen acceso. Con este modelo de cifrado de conocimiento cero, el mismo administrador de sistemas puede descifrar sus bóvedas asignadas, pero no las bóvedas de Finanzas o Infraestructura no relacionadas.

Passbolt cifra cada secreto por separado para cada destinatario mediante OpenPGP, tal como se describe en su documentación de seguridad (Pro v5.4, agosto de 2025). No existe una clave de contenedor compartida. Los usuarios solo pueden descifrar los secretos cifrados para ellos, aunque añadir destinatarios exige más trabajo.

1Password aísla los datos por bóveda, donde también se definen los permisos. Keeper utiliza claves de registro y claves de carpeta compartida en lugar de una única clave para toda la organización. Ninguno de los dos ofrece una base de datos de bóveda autoalojada para esta prueba en concreto.

Passwork y Passbolt limitan lo que un volcado de la base de datos más las claves de un miembro pueden revelar. Bitwarden simplifica la distribución de claves, pero convierte la clave de la organización en un límite criptográfico más amplio. Los productos exclusivamente en la nube evitan este escenario concreto de acceso a la base de datos, aunque su arquitectura de claves sigue siendo relevante.

Prueba gratuita de Passwork para comprobar cómo la estructura de su bóveda limita el acceso tras el compromiso de una cuenta.

Tipos de bóveda: gobernanza por encima de las bóvedas individuales

En Passwork, un tipo de bóveda define quién puede crear bóvedas de una clase y qué administradores se asignan automáticamente a las nuevas bóvedas de ese tipo. Con el cifrado del lado del cliente activado, esos administradores también reciben copias envueltas de las nuevas claves de bóveda. El resultado es una política repetible para departamentos y proyectos.

Por ejemplo, un tipo Finanzas puede asignar automáticamente al director financiero a cada nueva bóveda de finanzas. Un tipo DevOps puede mantener a los administradores de infraestructura separados de ventas. Cuando el responsable de un departamento se marcha, la empresa puede reasignar el administrador del tipo y revisar los permisos concedidos dentro de esa área, en lugar de auditar un rol de administrador global difícil de controlar. Esto resulta útil a medida que crecen los equipos y el número de bóvedas. Consulte las políticas de bóveda de Passwork.

Dos tipos integrados evitan la intervención de administradores corporativos. Una bóveda personal pertenece a un único usuario. Una bóveda compartida privada permite que ese usuario invite a otras personas. De forma predeterminada, ni siquiera el propietario o el administrador de la organización pueden leer su contenido. Los administradores pueden configurar quién puede crear estos tipos de bóveda y compartir información desde ellas, incluida la posibilidad de desactivar la creación no gestionada de bóvedas personales.

Existen dos límites: asignar un tipo no concede acceso retroactivo a las bóvedas existentes, y los tipos solo forman límites criptográficos cuando el cifrado del lado del cliente está activado. De lo contrario, siguen siendo reglas de gobernanza.

Los competidores ofrecen funciones relacionadas, pero no la misma capa de políticas. Las políticas empresariales de Bitwarden rigen aspectos como la autenticación, la recuperación y la pertenencia a la organización, en lugar de asignar automáticamente administradores por clase de bóveda. Passbolt no cuenta con un contenedor de bóveda que clasificar. 1Password ofrece aislamiento a nivel de bóveda y bóvedas personales, pero ninguna regla equivalente a nivel de clase para las bóvedas recién creadas. Las carpetas compartidas y los equipos de Keeper gestionan el acceso sin políticas de creación de bóvedas tipificadas.

Los tipos de bóveda reducen la probabilidad de que las bóvedas departamentales recién creadas reciban una administración incoherente. Añaden una decisión de política por adelantado, pero reducen la configuración manual repetida más adelante.

Permisos de carpetas: ¿Herencia o plantillas?

Un árbol de carpetas solo resulta útil si sus permisos se comportan como esperan los administradores. Interfaces con un aspecto similar pueden aplicar reglas muy distintas.

Passwork ofrece cinco niveles de permiso (lectura, escritura, gestión, administración y prohibido) para usuarios y grupos a nivel de bóveda o de carpeta. El acceso de la bóveda se propaga a las carpetas anidadas, mientras que las reglas de carpeta pueden restringirlo. Los derechos de administración y de prohibición no se pueden anular en niveles inferiores. Cuando se aplican varias reglas, prevalece el nivel de mayor prioridad. Es importante señalar que una carpeta no constituye un límite de cifrado independiente: el acceso a su contenido sigue dependiendo de la clave de la bóveda. Esto se suma al modelo de control de acceso basado en roles de Passwork.

Bitwarden concede permisos a través de colecciones. Las colecciones anidadas son etiquetas organizativas; no heredan los elementos ni los derechos de su colección superior. Las carpetas personales no tienen permisos de uso compartido. Los permisos individuales de un miembro prevalecen sobre los permisos de grupo.

Passbolt utiliza las carpetas como plantillas de permisos. Cuando se crea, se mueve o se comparte un elemento, se aplican los permisos de la carpeta, pero los permisos propios del elemento determinan el acceso posterior. Quien lo crea puede convertirse en propietario de una contraseña y restringir el acceso aunque la carpeta pertenezca a otra persona. En un debate comunitario de julio de 2026 sobre la extensión v5.14.2, Passbolt confirmó que este comportamiento se ajusta a su modelo de permisos y señaló que estaba previsto un cambio en la interfaz para impedir que los no propietarios editaran los permisos durante la creación.

1Password no dispone de carpetas con permisos propios dentro de una bóveda; las etiquetas organizan los elementos sin modificar el acceso. Por ello, compartir de forma permanente un subconjunto de elementos exige otra bóveda. Los grupos anidados de un proveedor de identidad no son compatibles con la pertenencia a bóvedas, según una respuesta de la comunidad de septiembre de 2026.

Keeper admite carpetas compartidas anidadas y permisos a nivel de registro. Las asignaciones explícitas de registros prevalecen sobre los derechos heredados de la carpeta. Su modelo de carpetas anidadas tiene un límite de profundidad de cinco niveles y estaba detrás de un feature flag en la versión 18.0.0 de la bóveda.

El árbol de Passwork admite estructuras departamentales y excepciones. Bitwarden y 1Password son más sencillos de administrar, pero menos flexibles para el acceso con anidamiento profundo. El comportamiento de plantillas de Passbolt exige especial atención, ya que los permisos de carpeta y de elemento pueden divergir.

Grupos: ¿qué cambia cuando alguien se incorpora?

Con el cifrado del lado del cliente de Passwork, añadir a alguien a un grupo no le otorga automáticamente todas las claves de bóveda asociadas a ese grupo. Se genera una solicitud pendiente para cada bóveda pertinente. Un titular de la clave debe aprobar la solicitud antes de que el nuevo miembro pueda descifrar su contenido.

Esto separa el aprovisionamiento de directorio del acceso criptográfico. La sincronización LDAP puede incorporar a un nuevo empleado a los grupos, pero el acceso a bóvedas sensibles sigue requiriendo aprobación. Esta distinción es importante durante la incorporación y la baja de empleados.

Para los equipos que necesitan menos aprobación manual, Passwork ofrece otro patrón: colocar los datos del departamento en una única bóveda y organizarlos en carpetas. Apruebe la clave de bóveda del usuario una sola vez; a partir de ahí, los permisos de carpeta determinan el acceso dentro de esa bóveda a medida que cambia la pertenencia a los grupos. La contrapartida es un límite criptográfico compartido más amplio que el de varias bóvedas independientes.

Passbolt no puede recurrir a este atajo. Dado que cada secreto se cifra para cada destinatario, añadir un miembro al grupo exige que alguien con acceso vuelva a cifrar los secretos pertinentes para ese usuario. La sincronización de directorio notifica a un gestor del grupo y espera a que se complete este paso. El trabajo escala con el número de secretos, no con el número de bóvedas.

Bitwarden ya distribuye la clave de la organización a los miembros, por lo que las asignaciones de colección no requieren nuevas claves de cifrado. En 1Password, las claves de bóveda asignadas siguen el acceso del grupo. Keeper distribuye el acceso mediante carpetas compartidas asignadas.

La disyuntiva está entre puntos de aprobación más estrictos y un aprovisionamiento más fluido. Passwork permite a las organizaciones elegir distintos equilibrios según el departamento; Passbolt ofrece un acceso granular por secreto a un coste de uso compartido más elevado.

Qué hace realmente el inicio de sesión de dominio

Una contraseña de dominio autentica a un usuario; no descifra los datos de la bóveda en ninguno de estos productos. Sus diferencias residen en cómo funcionan la autenticación y el aprovisionamiento mediante directorio.

Passwork autoalojado autentica directamente frente a LDAP o Active Directory, incluso en entornos con varios controladores de dominio. Los usuarios inician sesión con sus credenciales de dominio; los grupos de directorio pueden asignarse a grupos de Passwork. Con el cifrado del lado del cliente activado, la contraseña de dominio autentica la sesión, mientras que claves criptográficas independientes protegen el contenido de la bóveda.

En el momento de esta comparación, Passwork Cloud aún no ofrecía LDAP; estaba en la hoja de ruta, junto con el aprovisionamiento SCIM. Ambas implementaciones de Passwork admiten SSO mediante SAML 2.0.

Bitwarden Directory Connector sincroniza usuarios y grupos, pero no los autentica frente a LDAP, tal como explica su documentación. El inicio de sesión basado en dominio requiere SSO Enterprise mediante SAML u OIDC. Por lo general, los usuarios siguen desbloqueando su bóveda con una contraseña maestra, salvo que se configuren dispositivos de confianza o Key Connector.

Passbolt también separa la sincronización LDAP del inicio de sesión. Los usuarios se autentican mediante una clave privada y una frase de contraseña, o bien SSO, y añadir usuarios sincronizados a grupos con secretos existentes exige un nuevo cifrado.

1Password y Keeper utilizan servicios de bóveda basados en la nube con integración SSO. SSO Connect On-Prem de Keeper puede mantener ciertos componentes de identidad en el hardware de la empresa, pero su backend de bóveda cifrada permanece en la nube de Keeper. Keeper enumera los componentes locales compatibles en su documentación de implementación.

El inicio de sesión LDAP directo de Passwork puede simplificar las implementaciones autoalojadas sin necesidad de un proveedor de identidad independiente. Los competidores centrados en la nube ofrecen actualmente un aprovisionamiento de identidad automatizado más maduro; las funciones previstas de Passwork no deben considerarse disponibles en la actualidad.

Una sola API para contraseñas y secretos de máquina

Passwork gestiona las credenciales de los empleados y los secretos de máquina a través de la misma instancia, el mismo modelo de permisos, el mismo registro de auditoría y la misma API REST. Los equipos pueden respaldar flujos de trabajo de CI/CD sin necesidad de licenciar un producto de secretos independiente.

Sus clientes web, de escritorio, de navegador y móviles utilizan la misma API en /api/v1. Una CLI oficial y un conector de Python de código abierto respaldan los flujos de trabajo de DevOps. La CLI ofrece get y update para los registros, api para llamadas directas a los endpoints, y exec para recuperar y descifrar un secreto, exponer los valores como variables de entorno y ejecutar un comando. Las cuentas de servicio son usuarios con tokens de API creados por un administrador. Generar un nuevo token personal revoca las sesiones de API anteriores del usuario.

Este modelo unificado tiene limitaciones: la API funciona por sondeo (pull), sin webhooks salientes, y /v1/batch solo admite la agregación de lecturas, hasta 25 subsolicitudes GET. Las integraciones basadas en eventos deben sondear la API o consumir las exportaciones de syslog.

Los competidores adoptan enfoques distintos. Bitwarden Secrets Manager es un complemento de pago independiente con cuentas de máquina y acceso basado en proyectos, en lugar de acceso a través de las colecciones de Password Manager. Keeper Secrets Manager es otra línea de producto con SDK y una puerta de enlace conectada a la nube. Las cuentas de servicio de 1Password funcionan con bóvedas y permisos definidos, pero su alcance queda fijado al crear el token; para cambiarlo se necesita un nuevo token. Passbolt expone una API y herramientas de automatización, manteniendo su modelo de uso compartido por secreto.

Passwork favorece un único sistema operativo para personas y automatización. Los productos de secretos especializados pueden ofrecer integraciones específicas, pero añaden licencias y superficies de gestión adicionales.

Dónde se ejecuta la bóveda

La implementación puede descartar productos de una preselección antes de comparar cualquier función. Passwork, Bitwarden y Passbolt permiten a las organizaciones alojar la propia bóveda. 1Password y Keeper mantienen el backend de la bóveda en sus servicios en la nube.

Passwork admite la implementación local en Linux, Windows Server o Docker, lo que otorga a las organizaciones control sobre su infraestructura y sus copias de seguridad. Su oferta en la nube alojada en la UE utiliza una base de datos y un tenant independientes para cada cliente, en lugar de almacenar los registros de todos los clientes en un único esquema compartido. Estas opciones se analizan en la guía de modelos de implementación de Passwork.

Bitwarden también ofrece un autoalojamiento genuino, aunque su licencia Enterprise sigue vinculada a una suscripción activa en la nube. Passbolt admite tanto el autoalojamiento como un servicio alojado. Los componentes de SSO e integración de Keeper, implementables localmente, no cambian la ubicación de su backend de bóveda.

El autoalojamiento da a las organizaciones control sobre la ubicación de los datos, pero también la responsabilidad de las actualizaciones, las copias de seguridad y la disponibilidad. Los productos exclusivamente en la nube reducen esa carga allí donde la política permite el alojamiento externo.

Cifrado del lado del cliente opcional y metadatos

Passwork Cloud utiliza siempre el cifrado del lado del cliente. En la versión autoalojada, Passwork permite a los administradores desactivarlo. Los otros cuatro productos de esta comparación no ofrecen un interruptor equivalente.

El cifrado del lado del servidor puede resultar adecuado para un equipo pequeño con administradores de confianza que prioriza la concesión inmediata de acceso y una recuperación más sencilla. Desactivar el cifrado del lado del cliente elimina el aislamiento criptográfico por bóveda: los tipos de bóveda siguen controlando la creación y la administración, pero dejan de constituir límites de cifrado independientes.

Incluso con el cifrado del lado del cliente activado, el servidor de Passwork puede leer los nombres de los elementos, los inicios de sesión, las descripciones y las URL para habilitar la búsqueda en el servidor. Los valores de las contraseñas permanecen cifrados en el cliente y fuera del índice de búsqueda. Bitwarden y Keeper también cifran estos campos de metadatos, manteniéndolos ocultos para el servidor a costa de tener que descifrarlos en el cliente para poder buscar. Passbolt v5 deja sin cifrar los nombres de carpeta y las etiquetas.

Se trata de una contrapartida real entre seguridad y usabilidad. Los compradores deben evaluar tanto la confidencialidad de las contraseñas como la exposición de metadatos, especialmente cuando los registros contienen nombres de sistemas o identificadores de cuenta sensibles.

Qué cuesta

Estos son los precios de lista publicados por usuario y mes con facturación anual, a fecha de octubre de 2026. Los proveedores utilizan monedas y combinaciones de planes distintas, por lo que la comparación es orientativa.

Passwork Standard cuesta 3 € y Advanced, 4,50 € por usuario y mes. Advanced incluye gestión de secretos y funciones de identidad empresarial. Los clientes autoalojados también pueden optar por una licencia perpetua de pago único. Bitwarden Teams cuesta 4 $ y Enterprise, 6 $, con Secrets Manager con precio aparte de 6 $ y 12 $, respectivamente. Keeper Business parte de 4 $ y Enterprise de 6 $, mientras que KeeperPAM tiene un precio independiente. 1Password Business cuesta 8,99 $. Passbolt Pro autoalojado cuesta 4,50 € con un mínimo de diez usuarios.

Bitwarden Secrets Manager cuesta 6 $ por usuario y mes en Teams, o 12 $ en Enterprise, facturado por separado de Password Manager. Las organizaciones que utilicen ambos productos deben comparar los costes de licencia combinados en función del número de usuarios de cada uno. Passwork Advanced incluye la gestión de contraseñas y de secretos en una sola suscripción. El modelo de cifrado por secreto de Passbolt añade trabajo administrativo al compartir secretos o añadir miembros a un grupo, un coste que los precios de suscripción por sí solos no reflejan.

Dónde tienen ventaja los competidores

Passbolt ofrece uso compartido y revocación directos por secreto. Cada destinatario recibe un texto cifrado con su clave pública. La revocación elimina del servicio la copia cifrada de ese destinatario. Esto permite un control granular, pero cada destinatario adicional exige trabajo de cifrado y almacenamiento. Como ocurre con otros gestores de contraseñas, la revocación no puede borrar el texto en claro ni las copias que un destinatario haya guardado previamente.

Passwork almacena un único texto cifrado compartido y distribuye claves envueltas, en lugar de duplicar cada secreto para cada destinatario. Al eliminar una concesión permanente de bóveda o carpeta se elimina el acceso a la clave correspondiente. Su bandeja de entrada funciona de otro modo: una entrega directa entre usuarios envuelve la clave de un elemento para el destinatario, y un elemento aceptado se convierte en una copia dentro de la bóveda del destinatario. La entrega a la bandeja de entrada de un grupo utiliza una vía sin cifrado del lado del cliente. Por lo tanto, la bandeja de entrada es una transferencia, no una concesión revocable de forma permanente.

Bitwarden y Keeper protegen metadatos que Passwork expone para la búsqueda en el servidor. Keeper también ofrece accesos directos a registros y permisos directos por registro en carpetas compartidas, además de una plataforma más amplia de acceso privilegiado. 1Password tiene menos reglas de herencia y excepciones, lo que facilita su configuración para equipos que no necesitan permisos de carpeta complejos. Bitwarden combina un precio de entrada bajo, autoalojamiento y clientes consolidados.

Se trata de ventajas sustanciales. La flexibilidad de Passwork ayuda a las organizaciones con estructuras de acceso complejas, pero también genera más políticas que diseñar y mantener.

Cómo elegir: Empiece por el límite

Comience por el escenario de fallo, no por el algoritmo de cifrado. Si se compromete una cuenta, ¿qué registros pueden descifrar sus claves? ¿Qué cambia si el atacante también obtiene una copia de seguridad de la base de datos? A continuación, compruebe si su modelo de permisos refleja los límites departamentales y si la incorporación de nuevos usuarios puede ampliar el acceso de forma involuntaria.

Passwork es adecuado para organizaciones que necesitan bóvedas departamentales independientes, permisos de carpeta heredados, autenticación LDAP directa en local, y credenciales de empleados y de máquina en un solo sistema. Passbolt favorece el control por secreto cuando el coste administrativo del uso compartido resulta aceptable. Bitwarden ofrece una distribución de claves sencilla para toda la organización y autoalojamiento. 1Password minimiza la complejidad de configuración en un modelo centrado en la nube. Keeper combina controles de carpeta compartida con una oferta más amplia de acceso privilegiado.

Si Finanzas, Recursos Humanos e Infraestructura son unidades operativas independientes, decida si también deben tener límites criptográficos independientes. Esa decisión determina la exposición potencial de una clave comprometida de forma más directa que una simple etiqueta AES-256.

Probar Passwork en su infraestructura y comparar lo que una cuenta comprometida podría descifrar en cada sistema candidato.

Preguntas frecuentes

Las políticas de bóveda de Passwork: una guía para CIO sobre seguridad empresarial

Los tipos de bóveda de Passwork vinculan los derechos de administración a la propia política de la bóveda, no a quien la creó, cerrando así una brecha que la mayoría de las empresas ni siquiera sabe que existe. Esta guía ofrece a los CIO y CISO un modelo práctico de gobernanza de bóvedas, vinculado a los requisitos de NIS2 e ISO 27001.

PassworkPasswork Team

Passwork frente a KeePass: en qué difiere la arquitectura de cifrado

La criptografía de KeePass es realmente sólida. Su gestión de claves para equipos no lo es. Aquí es donde falla un archivo KDBX compartido —al guardar, al dar de baja a un empleado, al auditar— y lo que cambia una clave por bóveda.

PassworkPasswork Team

Passwork frente a Bitwarden: en qué difiere la arquitectura de cifrado de la bóveda

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

PassworkPasswork Team

Business password managers often advertise AES-256 encryption and servers that never see plaintext passwords. But cipher strength alone does not tell you how much data one compromised key or misplaced group membership can expose.

That exposure depends on the encryption boundary: whether a key unlocks an organization, a vault, a shared folder, or an individual secret. This comparison examines where Passwork, Bitwarden, Passbolt, 1Password, and Keeper draw that boundary, and what their designs mean for permissions, directory login, automation, and deployment.

The question that reveals the encryption boundary

Imagine a self-hosted password manager. A sysadmin responsible for backups has a database dump and joins the corporate organization to access one shared password. What else could they decrypt using the keys available to their account?

Bitwarden encrypts corporate items with per-item keys wrapped by one organization symmetric key, according to its security white paper. Organization members receive usable access to that key, while collections control normal server-delivered access and permissions rather than creating separate cryptographic boundaries. In a self-hosted threat model, an attacker who obtains the relevant database ciphertexts and a member’s usable organization key could decrypt organization items outside that member’s assigned collections.

Passwork, with client-side encryption enabled, uses a separate key for each vault. Item keys sit under vault keys, and users receive a wrapped vault key only for vaults they can access. Under this zero-knowledge encryption model, the same sysadmin can decrypt their assigned vaults, but not unrelated Finance or Infrastructure vaults.

Passbolt encrypts each secret separately for each recipient using OpenPGP, as described in its security documentation (Pro v5.4, August 2025). There is no shared container key. Users can decrypt only secrets encrypted for them, although adding recipients requires more work.

1Password isolates data by vault, where permissions are also defined. Keeper uses record keys and shared-folder keys rather than one organization-wide key. Neither offers a self-hosted vault database for this particular test.

Passwork and Passbolt limit what a database dump plus one member's keys can reveal. Bitwarden simplifies key distribution but makes the organization key a broader cryptographic boundary. The cloud-only products avoid this specific database-access scenario, though their key architecture still matters.

Start a free Passwork trial to test how your vault structure limits access after an account compromise.

Vault types: governance above individual vaults

In Passwork, a vault type defines who may create vaults in a class and which administrators are automatically assigned to new vaults of that type. With client-side encryption enabled, those administrators also receive wrapped copies of the new vault keys. The result is a repeatable policy for departments and projects.

For example, a Finance type can automatically assign the CFO to each new finance vault. A DevOps type can keep infrastructure administrators separate from sales. When a department head leaves, the company can reassign the type administrator and review grants within that area instead of auditing a sprawling global admin role. This becomes useful as teams and vault counts grow. See Passwork's vault policies.

Two built-in types avoid corporate administrators. A personal vault belongs to one user. A private shared vault lets that user invite others. By default, even the organization's Owner or Admin cannot read their contents. Administrators can configure who is allowed to create these vault types and share information from them, including disabling unmanaged personal vault creation.

There are two limits: assigning a type does not retroactively grant access to existing vaults, and types form cryptographic boundaries only when client-side encryption is enabled. Otherwise they remain governance rules.

The competitors offer related features, but not the same policy layer. Bitwarden enterprise policies govern matters such as authentication, recovery, and organization membership rather than automatically assigning administrators by vault class. Passbolt has no vault container to classify. 1Password provides vault-level isolation and personal vaults, but no equivalent class-wide rule for newly created vaults. Keeper's shared folders and teams manage access without typed vault creation policies.

Vault types reduce the chance that newly created departmental vaults receive inconsistent administration. They add a policy decision upfront, but reduce repeated manual configuration later.

Folder permissions: Inheritance or templates?

A folder tree is useful only if its permissions behave as administrators expect. Similar-looking interfaces can enforce very different rules.

Passwork offers five permission levels—read, write, manage, admin, and forbidden—for users and groups at vault or folder level. Vault access flows into nested folders, while folder rules can narrow access. Admin and forbidden rights cannot be overridden further down. When multiple rules apply, the higher-priority level wins. Importantly, a folder is not a separate encryption boundary: access to its contents still relies on the vault key. This sits alongside Passwork's role-based access control model.

Bitwarden grants permissions through collections. Nested collections are organizational labels; they do not inherit their parent's items or rights. Personal folders have no sharing permissions. Individual member permissions override group permissions.

Passbolt uses folders as permission templates. When an item is created, moved, or shared, the folder's permissions are applied, but the item's own permissions determine subsequent access. A creator can become the owner of a password and restrict access even when someone else owns the folder. In a July 2026 community discussion about extension v5.14.2, Passbolt confirmed this behavior follows its permission model and said a UI change was planned to prevent non-owners editing permissions during creation.

1Password has no permission-bearing folders inside a vault; tags organize items without changing access. Sharing a subset of items permanently therefore requires another vault. Nested identity-provider groups are not supported for vault membership, according to a September 2026 community response.

Keeper supports nested shared folders and record-level permissions. Explicit record assignments override inherited folder rights. Its nested-folder model has a five-level depth limit and was behind a feature flag in vault release 18.0.0.

Passwork's tree supports departmental structures and exceptions. Bitwarden and 1Password are simpler to administer but less flexible for deeply nested access. Passbolt's template behavior requires special attention because folder and item permissions can diverge.

Groups: what changes when someone joins?

With Passwork client-side encryption, adding someone to a group does not automatically give them every vault key associated with that group. It creates a pending request for each relevant vault. A key holder must approve the request before the new member can decrypt its contents.

This separates directory provisioning from cryptographic access. LDAP synchronization can place a new employee into groups, but access to sensitive vaults still requires approval. The distinction matters during onboarding and offboarding.

For teams that need less manual approval, Passwork offers another pattern: put the department's data in one vault and organize it into folders. Approve the user's vault key once; folder permissions then determine access within that vault as group membership changes. The trade-off is a wider shared cryptographic boundary than several separate vaults.

Passbolt cannot use this shortcut. Because each secret is encrypted for each recipient, adding a group member requires someone with access to re-encrypt the relevant secrets for that user. Directory synchronization notifies a group manager and waits for this step. The work scales with the number of secrets rather than the number of vaults.

Bitwarden already distributes the organization key to members, so collection assignments do not require new encryption keys. In 1Password, assigned vault keys follow group access. Keeper distributes access through assigned shared folders.

The choice is between tighter approval checkpoints and smoother provisioning. Passwork lets organizations choose different balances for different departments; Passbolt provides fine-grained per-secret access at a higher sharing cost.

What domain login actually does

A domain password authenticates a user; it does not decrypt vault data in any of these products. Their differences lie in how directory authentication and provisioning work.

Passwork self-hosted authenticates directly against LDAP or Active Directory, including environments with multiple domain controllers. Users sign in with domain credentials; directory groups can map to Passwork groups. With client-side encryption enabled, the domain password authenticates the session while separate cryptographic keys protect vault contents.

Passwork Cloud did not yet offer LDAP at the time of this comparison; it was on the roadmap, along with SCIM provisioning. Both Passwork deployments support SAML 2.0 SSO.

Bitwarden Directory Connector synchronizes users and groups but does not authenticate them against LDAP, as its documentation explains. Domain-based sign-in requires Enterprise SSO through SAML or OIDC. Users ordinarily still unlock their vault with a master password, unless trusted devices or Key Connector are configured.

Passbolt also separates LDAP synchronization from login. Users authenticate using a private key and passphrase or SSO, and adding synced users to groups with existing secrets requires re-encryption.

1Password and Keeper use cloud-based vault services with SSO integration. Keeper's SSO Connect On-Prem can keep certain identity components on company hardware, but its encrypted vault backend remains in Keeper's cloud. Keeper lists supported local components in its deployment documentation.

Passwork's direct LDAP login can simplify self-hosted deployments without a separate identity provider. Cloud-first competitors currently offer more mature automated identity provisioning; planned Passwork features should not be treated as available today.

One API for passwords and machine secrets

Passwork manages employee credentials and machine secrets through the same instance, permission model, audit log, and REST API. Teams can support CI/CD workflows without licensing a separate secrets product.

Its web, desktop, browser, and mobile clients use the same API at /api/v1. An official CLI and open-source Python connector support DevOps workflows. The CLI provides get and update for records, api for direct endpoint calls, and exec to retrieve and decrypt a secret, expose values as environment variables, and run a command. Service accounts are users with API tokens created by an administrator. Generating a new personal token revokes the user's previous API sessions.

This unified model has limitations: the API is pull-based, with no outbound webhooks, and /v1/batch supports read aggregation only, up to 25 GET subrequests. Event-driven integrations must poll or consume syslog exports.

Competitors take different approaches. Bitwarden Secrets Manager is a separate paid add-on with machine accounts and project-based access, rather than access through Password Manager collections. Keeper Secrets Manager is another product line with SDKs and a cloud-connected gateway. 1Password service accounts work with defined vaults and permissions, but their scope is fixed when a token is created; changing it requires a new token. Passbolt exposes an API and automation tooling while retaining its per-secret sharing model.

Passwork favors a single operational system for people and automation. Specialized secrets products can offer dedicated integrations, but introduce additional licensing and management surfaces.

Where the vault runs

Deployment can eliminate products from a shortlist before any feature comparison. Passwork, Bitwarden, and Passbolt allow organizations to host the vault itself. 1Password and Keeper keep the vault backend in their cloud services.

Passwork supports on-premise deployment on Linux, Windows Server, or Docker, giving organizations control over their infrastructure and backups. Its EU-hosted cloud offering uses a separate database and tenant for each customer, rather than storing all customers' records in one shared schema. These options are discussed in Passwork's deployment models guide.

Bitwarden also offers genuine self-hosting, although its Enterprise license remains tied to an active cloud subscription. Passbolt supports self-hosting and a hosted service. Keeper's locally deployable SSO and integration components do not change the location of its vault backend.

Self-hosting gives organizations control over data location but also responsibility for updates, backups, and availability. Cloud-only products reduce that workload where policy permits external hosting.

Optional client-side encryption and metadata

Passwork Cloud always uses client-side encryption. Self-hosted Passwork lets administrators disable it. The other four products in this comparison do not offer an equivalent switch.

Server-side encryption can suit a small team with trusted administrators that prioritizes immediate access grants and simpler recovery. Disabling client-side encryption removes per-vault cryptographic isolation: vault types still control creation and administration, but no longer form separate encryption boundaries.

Even when client-side encryption is enabled, Passwork's server can read item names, logins, descriptions, and URLs to support server-side search. Password values remain encrypted on the client and outside the search index. Bitwarden and Keeper encrypt these metadata fields too, keeping them hidden from the server at the cost of client-side decryption for search. Passbolt v5 leaves folder names and tags unencrypted.

This is a real security and usability trade-off. Buyers should evaluate both password confidentiality and metadata exposure, especially when records contain sensitive system names or account identifiers.

What it costs

These are published list prices per user per month on annual billing, as of October 2026. Vendors use different currencies and packaging, so the comparison is directional.

Passwork Standard costs €3 and Advanced €4.50 per user per month. Advanced includes secrets management and enterprise identity features. Self-hosted customers can also choose a one-time lifetime license. Bitwarden Teams costs $4 and Enterprise $6, with Secrets Manager priced separately at $6 and $12, respectively. Keeper Business starts at $4 and Enterprise at $6, while KeeperPAM is priced separately. 1Password Business costs $8.99. Passbolt Pro self-hosted costs €4.50 with a ten-user minimum.

Bitwarden Secrets Manager costs $6 per user per month on Teams or $12 on Enterprise, billed separately from Password Manager. Organizations using both products should compare combined licensing costs based on the number of users in each. Passwork Advanced includes password and secrets management in one subscription. Passbolt's per-secret encryption model adds administrative work when sharing secrets or adding group members, a cost that subscription prices alone cannot capture.

Where competitors have the advantage

Passbolt provides direct per-secret sharing and revocation. Each recipient gets a ciphertext encrypted with their public key. Revocation removes that recipient's encrypted copy from the service. This supports fine-grained control, but every additional recipient requires encryption and storage work. As with other password managers, revocation cannot erase plaintext or copies a recipient previously saved.

Passwork stores one shared ciphertext and distributes wrapped keys rather than duplicating every secret for each recipient. Removing a permanent vault or folder grant removes the relevant key access. Its inbox works differently: a direct user handoff wraps an item's key for the recipient, and an accepted item becomes a copy in the recipient's vault. Group inbox delivery uses a non-client-side-encryption path. Inbox is therefore a transfer, not a permanently revocable grant.

Bitwarden and Keeper protect metadata that Passwork exposes for server-side search. Keeper also offers record shortcuts and direct per-record permissions in shared folders, plus a broader privileged-access platform. 1Password has fewer inheritance rules and exceptions, making it easier to configure for teams that do not need complex folder permissions. Bitwarden combines low entry pricing, self-hosting, and established clients.

These are substantive advantages. Passwork's flexibility helps organizations with complex access structures, but also creates more policies to design and maintain.

How to choose: Start with the boundary

Begin with the failure scenario, not the encryption algorithm. If an account is compromised, what records can its keys decrypt? What changes if the attacker also obtains a database backup? Then check whether your permission model mirrors departmental boundaries and whether onboarding can accidentally expand access.

Passwork is suited to organizations that need separate departmental vaults, inherited folder permissions, direct LDAP authentication on-premise, and employee and machine credentials in one system. Passbolt favors per-secret control where the administrative cost of sharing is acceptable. Bitwarden offers straightforward organization-wide key distribution and self-hosting. 1Password minimizes configuration complexity in a cloud-first model. Keeper combines shared-folder controls with a wider privileged-access offering.

If Finance, HR, and Infrastructure are separate operational units, decide whether they should also have separate cryptographic boundaries. That decision determines the potential exposure of one compromised key more directly than an AES-256 label.

Test Passwork in your infrastructure and compare what one compromised account could decrypt in each candidate system.

Frequently asked questions

Passwork’s vault policies: a CIO’s guide to enterprise security

Passwork’s Vault Types bind admin rights to the vault policy itself, not to whoever created it, closing a gap most enterprises don’t even know exists. This guide gives CIOs and CISOs a working model for vault governance, mapped to NIS2 and ISO 27001 requirements.

PassworkPasswork Team

Passwork vs KeePass: How encryption architecture differs

KeePass’s cryptography is genuinely strong. Its key management for teams is not. Here’s where a shared KDBX file breaks down — at the save, at the offboarding, at the audit — and what a per-vault key changes.

PassworkPasswork Team

Passwork vs Bitwarden: How vault encryption architecture differs

Passwork encrypts every vault with its own key. Bitwarden encrypts an entire organization with one shared key. This comparison breaks down what that means for blast radius, team isolation, account recovery, and audit answers when a credential leaks.

PassworkPasswork Team

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.

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.

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

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

Gestão de palavras-passe e de acessos para PMEs: O KeePass é suficiente?

Todos os administradores de TI que usam o KeePass numa equipa contam a mesma história. Começa com um único ficheiro .kdbx partilhado numa unidade de rede. Depois, alguém não consegue abri-lo porque um colega o tem bloqueado. Depois, um administrador de sistemas júnior guarda por cima de uma alteração que outra pessoa fez uma hora antes. Depois, um colaborador sai e ninguém sabe bem a que palavras-passe tinha acesso. O KeePass é uma ferramenta genuinamente excelente: para uma só pessoa. A partir do momento em que é colocado à frente de uma equipa, já não se está a gerir palavras-passe.

PassworkAlex Muntyan

O que é a cifragem zero-knowledge? Como funciona em 5 minutos

A cifragem zero-knowledge significa que o servidor nunca possui as chaves de decifragem, apenas texto cifrado. Como funciona a cadeia de chaves, contra o que protege, contra o que não protege e como verificar a alegação de um fornecedor.

PassworkPasswork Team

Passwork vs Bitwarden: como difere a arquitetura de cifragem dos cofres

O Passwork cifra cada cofre com a sua própria chave. O Bitwarden cifra uma organização inteira com uma única chave partilhada. Esta comparação analisa o que isso significa em termos de raio de impacto, isolamento entre equipas, recuperação de contas e respostas de auditoria quando uma credencial é divulgada.

PassworkPasswork Team

KeePass hat bessere kryptografische Primitive als viele kommerzielle Passwortmanager, und genau dort beginnt dieser Vergleich. Das Format KDBX 4 unterstützt eine memory-hard Schlüsselableitungsfunktion, authentifiziert seinen Geheimtext, bevor überhaupt etwas entschlüsselt wird, und verschlüsselt die gesamte Datenbank statt nur der Passwortfelder.

Was KDBX nicht hat, ist eine Schlüsselverwaltung für mehr als eine Person. Es gibt einen Schlüssel, er gehört zu einer Datei und nicht zu einem Menschen, und er öffnet alles. Jede Mehrbenutzer-Eigenschaft, die ein Team irgendwann braucht – einer Person den Zugriff entziehen, wissen, wer welche Zugangsdaten gelesen hat, begrenzen, was ein einzelner abgeflossener Schlüssel offenlegt –, muss außerhalb des Formats entstehen, meist aus Dateisystemrechten und guten Absichten.

Das ist die eigentliche Trennlinie, und sie zeigt sich in drei Momenten: wenn zwei Personen die gemeinsame Datenbank gleichzeitig speichern, wenn jemand das Unternehmen verlässt und wenn ein Auditor fragt, wer im letzten Quartal welche Zugangsdaten geöffnet hat.

Was KDBX 4 tatsächlich leistet

Eine KDBX-4-Datei wird mit AES-256 im CBC-Modus mit PKCS#7-Padding oder mit ChaCha20 verschlüsselt, so die Formatspezifikation. Der Schlüssel entsteht, indem die Komponenten des Masterschlüssels zu einem 256-Bit-Wert gehasht werden, dieser Wert durch eine Schlüsselableitungsfunktion läuft und das Ergebnis anschließend mit einem bei jedem Speichern neuen Seed gehasht wird. Drei Ableitungsfunktionen sind ohne Plugins enthalten: AES-KDF, Argon2d und Argon2id.

Bei der Integrität hat KDBX 4 den Vorsprung gegenüber dem Vorgänger gewonnen. Die Datei speichert einen SHA-256-Hash des Headers, sodass Beschädigungen ohne den Masterschlüssel erkennbar sind, anschließend einen HMAC-SHA-256 des Headers, und die Nutzdaten werden in 1-MB-Blöcke aufgeteilt, die jeweils ihren eigenen HMAC tragen. Die Spezifikation nennt das „ein Encrypt-then-MAC-Schema“, das heißt, die Authentizität wird geprüft, bevor überhaupt etwas entschlüsselt wird. KDBX 3.1 hashte stattdessen den Klartext, und die Anmerkung des Autors zu dieser Änderung ist wegen ihrer Zurückhaltung ein Zitat wert:

Obwohl das Encrypt-then-MAC-Schema (KDBX 4) allgemein als sicherer gilt als ein MAC-then-Encrypt-Schema (KDBX 3.1), glauben wir nicht, dass KDBX-3.1-Dateien unsicher waren.

Für ein Team sind zwei Einschränkungen wichtig. KDBX 3.1 ist in KeePassXC weiterhin ein natives Format, deshalb gilt „KeePass bedeutet Argon2 und HMAC“ erst, sobald jemand die Datenbank tatsächlich migriert hat – ein manueller Schritt in den Verschlüsselungseinstellungen. Und der Speicherparameter von Argon2 ist durch das schwächste Gerät begrenzt, das die Datei öffnet: KeePass empfiehlt die Hälfte des Arbeitsspeichers des kleinsten Geräts und warnt, dass ein großer Speicherparameter unter iOS AutoFill beeinträchtigen kann; dort werden 64 MB oder weniger empfohlen. Eine KDF ist nur so stark wie die Parameter, die Ihr Telefon verkraftet.

Der Umfang der Verschlüsselung ist tatsächlich besser als bei mehreren gehosteten Wettbewerbern: „KeePass verschlüsselt die gesamte Datenbank, das heißt nicht nur Ihre Passwörter, sondern auch Ihre Benutzernamen, URLs, Notizen und so weiter.“ Eine gestohlene KDBX-Datei verrät nichts über ihren Inhalt, nicht einmal die Titel der Einträge.

Eine Sache sieht wie eine zweite Schicht aus, ist es aber nicht. KDBX wendet auf geschützte Felder innerhalb des XML zusätzlich Salsa20 oder ChaCha20 an, und die Spezifikation begegnet dem Missverständnis direkt:

Wir betonen, dass der einzige Zweck der inneren Verschlüsselung darin besteht, den Schutz des Prozessspeichers zu unterstützen. Die innere Verschlüsselung hat keinen Einfluss auf die kryptografische Sicherheit des KDBX-Dateiformats.

Ihr Schlüssel liegt im inneren Header und hängt nicht vom Masterschlüssel ab.

Wo der Schlüssel liegt – und warum das alles andere entscheidet

Der Masterschlüssel von KeePass ist zusammengesetzt: ein Masterpasswort, eine Schlüsseldatei und ein über DPAPI an das aktuelle Windows-Konto gebundener Schlüssel, in beliebiger Kombination. Alle gewählten Komponenten sind erforderlich, und die Dokumentation zum Masterschlüssel wird dabei deutlich:

Wenn Sie eine der Komponenten des Masterschlüssels vergessen oder verlieren (oder die Zusammensetzung vergessen), sind alle in der Datenbank gespeicherten Daten verloren. Es gibt keine Backdoor und keinen Universalschlüssel, der Ihre Datenbank öffnen kann.

Beachten Sie, was diese Komponenten gemeinsam haben. Ein Passwort ist Wissen, eine Schlüsseldatei ist Besitz, ein DPAPI-Schlüssel ist ein Maschinenkonto. Keine davon ist eine Identität, die die Datenbank erkennt und später von einer anderen unterscheiden kann. Der Schlüssel ist eine Eigenschaft der Datei.

Passwork setzt bei der Person an und folgt demselben Prinzip der Zero-Knowledge-Architektur (der Server verarbeitet ausschließlich Geheimtext), aufgebaut um die individuelle Identität statt um ein einzelnes Dateigeheimnis. Jeder Benutzer hat ein eigenes RSA-Schlüsselpaar, das clientseitig erzeugt wird; der private Teil wird mit einem Schlüssel verschlüsselt, der aus dem Masterpasswort abgeleitet ist. Ein Tresor erhält bei der Erstellung einen eigenen AES-256-Schlüssel, und jeder Benutzer mit Zugriff hält eine separate Kopie dieses Tresorschlüssels, verschlüsselt mit seinem eigenen öffentlichen Schlüssel (Schlüsselhierarchie). Der Server verarbeitet immer nur Geheimtext (Überblick zur Kryptografie).

Die gemeinsame Nutzung folgt aus dieser Struktur. Eine Zugriffsvergabe verschlüsselt den Tresorschlüssel neu für den öffentlichen Schlüssel des Empfängers, statt die Daten neu zu verschlüsseln (Mechanik der Freigabe). Ein Entzug löscht die verschlüsselte Kopie dieser Person. Alle anderen arbeiten mit demselben Tresorschlüssel weiter, und nichts wird neu verschlüsselt.

Wo die Kryptografie von KeePass für Einzelnutzer stärker ist

Bei der Schlüsselableitung zeigt sich das. Argon2 ist memory-hard, und genau diese Eigenschaft macht das Knacken mit GPUs und ASICs teuer; KeePass erklärt, warum in diesem Zusammenhang Argon2d bevorzugt wird: „ein besserer Schutz gegen eine tatsächlich bestehende Bedrohung (das Knacken von Passwörtern mit GPUs/ASICs ist Stand der Technik) ist wichtiger als ein Schutz gegen bestimmte Seitenkanalangriffe, die auf Client-Geräten in Zukunft zu einem Problem werden können oder auch nicht.“ Passwork leitet den Masterschlüssel mit PBKDF2 über 300.000 Iterationen auf SHA-256 ab – eine vertretbare, von NIST anerkannte Einstellung, aber nicht memory-hard, und gegenüber spezialisierter Cracking-Hardware macht dieser Unterschied etwas aus.

An der Schlussfolgerung für ein Team, das Zugangsdaten über mehr als eine Person hinweg nutzt, ändert das nichts: dort entscheidet die Schlüsselverwaltung, nicht die Stärke des Verschlüsselungsverfahrens, und um diese Frage geht es im weiteren Vergleich. Für einen einzelnen Benutzer mit einem Laptop und einer Datei, der nichts mit anderen teilt, ist das die Eigenschaft, die gegen Offline-Knackversuche am meisten zählt.

Was passiert, wenn ein Team die Datei gemeinsam nutzt

Hier zeigt sich das Entwurfsziel. Die KeePass-Dokumentation zu mehreren Benutzern formuliert es ohne Einschränkung:

Alle Benutzer verwenden dasselbe Masterpasswort und/oder dieselbe Schlüsseldatei, um die Datenbank zu öffnen. Es gibt keine Zugriffskontrolllisten (ACLs) pro Gruppe oder pro Eintrag. Um den Schreibzugriff auf die Datenbankdatei einzuschränken (das heißt, nur eine ausgewählte Gruppe von Benutzern darf die gespeicherten Daten ändern), verwenden Sie Dateisystem-Zugriffsrechte.

Zugriffskontrolle gibt es, aber sie liegt in NTFS oder in Ihrer SMB-Freigabe, nicht im Produkt und nicht in der Kryptografie. Lesezugriff ist konstruktionsbedingt alles oder nichts, denn Lesen setzt den einen Schlüssel voraus, der alles entschlüsselt.

KeePass 2.x erkennt Konflikte. Beim Speichern „prüft es zunächst, ob die Datei auf der Festplatte seit dem Laden geändert wurde“, und bietet dann an, zu synchronisieren statt zu überschreiben. Das Zusammenführen erfolgt auf Eintragsebene, und die unterlegene Version eines konfliktbehafteten Eintrags wird in der Historie dieses Eintrags aufbewahrt, nicht verworfen.

Konflikte werden über den Vergleich der Zeitstempel der letzten Änderung gelöst; entscheidend ist damit die Systemuhr jedes Benutzers und nicht eine Form von Autorität. Die Abfrage erscheint nur beim Speichern: „Die Synchronisierungsabfrage wird nur durch den Befehl ‚Speichern‘ ausgelöst, nicht durch den Befehl ‚Speichern unter‘. Wird der Befehl ‚Speichern unter‘ ausgeführt und eine Datei manuell ausgewählt, wird diese Datei immer überschrieben.“ Historieneinträge überdauern ein Zusammenführen, „können aber von der automatischen Historienpflege gelöscht werden“ – diese richtet sich nach der Größe. Und KeePass 1.x hat überhaupt keine Synchronisierung, sodass ein Speichern dort tatsächlich überschreibt, was sich darunter geändert hat.

KeePassXC unterscheidet sich in einem Punkt, der wichtig ist, wenn es Ihr Client ist. Es hat eine Funktion zum Zusammenführen in der Oberfläche und als keepassxc-cli merge, die Einträge über UUID und Änderungszeit vergleicht. Eine integrierte Cloud-Synchronisierung fehlt aber absichtlich, und die FAQ nennt den Grund: Die Datenbank soll in einem gemeinsamen Cloud-Ordner liegen und der Synchronisierungsdienst soll sich darum kümmern, was „die Komplexität unseres Codes niedrig hält“. Vertretbare Technik mit einer konkreten betrieblichen Folge. Dropbox, Nextcloud und OneDrive wissen nichts über KDBX, deshalb entstehen bei gleichzeitigen Änderungen Konfliktkopien der Datei, und sie wieder zusammenzuführen ist Handarbeit, an die jemand denken muss.

Das von KeePass selbst empfohlene Muster für gemeinsam genutzte Dateien ist ein Trigger: eine lokale Kopie behalten und mit der Hauptdatei synchronisieren – ein Verfahren, das die Dokumentation damit beschreibt, es verhindere „Datenverlust, wenn Datenbankdateien von anderen Anwendungen überschrieben werden (zum Beispiel von Software für Cloud-Speicherdienste)“. Es funktioniert. Es bedeutet aber auch, dass Ihr Zugriffsmodell nun von einem Trigger abhängt, der in einer Konfigurationsdatei liegt, die laut Trigger-Seite unverschlüsselt ist und „für alle Benutzer dieser KeePass-Installation gilt“.

Zugriff zurücknehmen

Fragen Sie das in jeder Evaluierung zuerst. Ein dateibasiertes Modell hat darauf keine gute Antwort, und die Antwort, die es hat, überrascht die meisten.

Ein ausscheidender Mitarbeiter hatte den Masterschlüssel. Möglicherweise hat er außerdem eine Kopie der KDBX-Datei auf einem Laptop, in einem Backup, in einem Synchronisierungsordner oder in einer Konfliktkopie, die niemand aufgeräumt hat. Ein Wechsel des Masterschlüssels verschlüsselt die Datenbank für die Zukunft neu und ändert nichts an bereits bestehenden Kopien. Diese bleiben mit dem Schlüssel entschlüsselbar, unter dem sie gespeichert wurden – unbegrenzt. Die Eintragshistorie verschärft das: Wird ein Passwort in der Datenbank rotiert, bleibt der vorherige Wert in der Historie dieses Eintrags, sodass eine veraltete Kopie sowohl das alte als auch das neue Geheimnis enthält.

Der einzige echte Entzug besteht darin, alle Zugangsdaten zu rotieren, die diese Person erreichen konnte – in einem Einzeldateimodell also alle. Der Aufwand richtet sich nach der Größe Ihrer Datenbank und nicht nach dem Aufgabenbereich dieser Person.

In Passwork ist dasselbe Ereignis begrenzt. Der Entzug des Zugriffs löscht die verschlüsselte Kopie des Tresorschlüssels dieses Benutzers, und die übrigen Mitglieder arbeiten mit dem unveränderten Schlüssel weiter. Eine Rotation nach dem Offboarding bleibt die richtige Maßnahme für alles, was die Person tatsächlich gelesen hat, und kein Produkt kann Zugangsdaten zurückholen, die sich jemand gemerkt hat. Der Unterschied ist, dass der Schaden auf einen Tresor begrenzt bleibt statt auf alles und dass der Entzug eine einzelne Operation ist und kein Projekt.

Wo die LDAP-/Active-Directory-Integration von Passwork konfiguriert ist, muss dieser Vorgang gar nicht manuell erfolgen: Wird das Konto in AD deaktiviert, entzieht Passwork den Zugriff automatisch entsprechend dem Verzeichniszustand, sodass ein Offboarding im Verzeichnis ein Offboarding im Tresor ist. Und das Sicherheits-Dashboard überlässt die Nachbereitung nicht dem Gedächtnis – es markiert Zugangsdaten, die ein Benutzer nach dem Entzug seines Zugriffs weiterhin erreichen könnte, als Kompromittierungsrisiko und macht aus dem, was diese Person erreichen konnte, eine sichtbare Arbeitsliste statt etwas, das von Hand rekonstruiert werden muss.

Wer hat was gelesen

KeePass ist eine Desktop-Anwendung ohne Serverkomponente – ein Punkt, den die eigenen Hinweise machen, während sie einen Bericht über einen Timing-Angriff zurückweisen: KeePass „verfügt über keine Serverfunktionen (insbesondere kann das automatische Öffnen einer Datenbank nicht extern ausgelöst werden)“.

Das hat Folgen für das Audit. KDBX erfasst Änderungszeitstempel und Eintragshistorie, also ein Protokoll der Änderungen an der Datei, nicht ein Protokoll der Zugriffe. Nichts hält fest, dass jemand die Datenbank geöffnet und Zugangsdaten gelesen hat, denn das Lesen findet vollständig im Client statt. Bei einem gemeinsamen Masterschlüssel kann selbst ein Änderungseintrag nicht zuverlässig sagen, welcher Mensch ihn verursacht hat.

Passwork protokolliert Aktionen serverseitig und kann sie im CEF-Format an syslog oder das Windows-Ereignisprotokoll für ein SIEM weiterleiten (Aktivitätsprotokoll, Ereignisliste). Vergaben, Änderungen und Entzüge werden einzeln erfasst und einem Konto zugeordnet.

Einer Datei vertrauen, die alle bearbeiten

Das schärfste Argument gegen das Muster der gemeinsamen Datenbank kommt aus der Dokumentation von KeePass selbst.

KeePass unterstützt Platzhalter in Einträgen. {CMD:...} führt eine Befehlszeile aus, und Feldreferenzen können Daten aus anderen Einträgen holen, sodass eine präparierte URL andere Zugangsdaten abfließen lassen kann. Die Sicherheitsseite nennt das Beispiel selbst: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. Der darauf folgende Hinweis ist eindeutig:

Wenn Sie eine Datenbank öffnen, die von jemand anderem erstellt oder geändert wurde, sollten Sie alle Daten, die Sie verwenden möchten, sorgfältig prüfen. Wenn Sie dem Ersteller der Datenbank nicht vollständig vertrauen, öffnen Sie keine an Einträge angehängten Dateien.

Lesen Sie das vor dem Hintergrund einer Bereitstellung auf einem Netzlaufwerk. Eine Team-Datenbank wird per Definition von anderen Personen erstellt und geändert, und jeder mit Schreibzugriff kann Einträge hinzufügen, die die anderen anklicken werden. Das von KeePass dokumentierte Vertrauensmodell setzt voraus, dass eine Datenbank einen Besitzer hat, der für ihren Inhalt bürgt – und genau das ist eine gemeinsam genutzte Team-Datei nicht.

Dokumentierte Schwachstellen

CVE-2023-32784 (CVSS 7,5) erlaubte es, das Masterpasswort im Klartext aus einem Speicherabbild in KeePass 2.x vor 2.54 zu rekonstruieren, auch aus einer Auslagerungs- oder Ruhezustandsdatei und selbst nach dem Beenden des Prozesses; nur das erste Zeichen blieb nicht rekonstruierbar. Ursache war ein eigenes Textfeld, das pro Zeichen Reste im .NET-Speicher hinterließ. Der Fehler wurde in 2.54 behoben, und der Forscher bescheinigte eine schnelle Reaktion.

CVE-2023-24055 (CVSS 5,5) ist von MITRE als umstritten markiert. Ein Angreifer mit Schreibzugriff auf die XML-Konfigurationsdatei konnte einen Export-Trigger hinzufügen und Passwörter im Klartext abgreifen. Der NVD-Eintrag hält die Position des Herstellers fest: „Die Passwortdatenbank soll nicht gegen einen Angreifer sicher sein, der diese Zugriffsebene auf dem lokalen PC hat.“ Diese Position ist konsistent, und die Security-Issues-Seite begründet sie allgemein: Wer Ihre Konfigurationsdatei schreiben kann, kann meist auch die ausführbare Datei ersetzen.

Zur Einordnung: KeePassXC hat ein externes Audit durchlaufen, abgeschlossen im Januar 2023, und sagt offen, dass ein Audit „nur für eine ‚Momentaufnahme‘ des Codes gilt“.

Vergleichstabelle

Migration – und worauf dabei zu achten ist

Passwork importiert KeePass-XML, daneben JSON und CSV. Die verschlüsselte KDBX-Binärdatei wird nicht gelesen, und das Parsen findet im Client statt und nicht auf dem Server – die einzige Anordnung, die dazu passt, dass der Server nie Klartext sieht.

Die Folge sollte ausgesprochen und nicht übergangen werden. Ein Export aus KeePass nach XML erzeugt eine unverschlüsselte Datei mit allen Zugangsdaten, und sie liegt so lange auf der Festplatte, wie die Migration dauert. Führen Sie ihn auf einem Rechner aus, den Sie kontrollieren, auf lokalem Speicher statt in einem synchronisierten Ordner, und löschen Sie die Datei mit einem Werkzeug, das überschreibt und nicht nur den Verweis entfernt. Es ist der eine Schritt einer Migration, in dem ein unachtsamer Nachmittag die Kryptografie beider Produkte gleichzeitig aushebelt.

Wann KeePass die richtige Wahl ist

Wenn Sie konkret abwägen, ob KeePass für ein kleines Team ausreicht, behandelt Passwort- und Zugriffsverwaltung für KMU: Reicht KeePass aus? genau diese Frage. Dieser Artikel bleibt enger gefasst, allein auf der Achse der Verschlüsselungsarchitektur, für Teams jeder Größe.

Wenn Sie eine Person sind oder zwei Personen, die ohnehin alles gemeinsam nutzen, ist KeePass mit einer KDBX-4-Datenbank und vernünftigen Argon2-Parametern eine ausgezeichnete Wahl – und kostenlos. Die Kryptografie ist stark, das Format ist öffentlich dokumentiert, und ohne Server gibt es keinen Dienst, in den eingebrochen werden kann.

Das Modell passt nicht mehr, sobald Sie Antworten brauchen, die eine Datei nicht geben kann. Wer genau hat hierauf Zugriff. Was genau ist verloren gegangen, als dieser Laptop verschwand. Was bricht, wenn diese Person am Freitag geht. Belegen Sie, dass der externe Dienstleister nie Produktions-Zugangsdaten gesehen hat.

Ein nützlicher Test vor der Entscheidung: Zählen Sie, wie viele Personen heute den Masterschlüssel zu Ihrer gemeinsamen Datenbank besitzen, und fragen Sie dann, was Sie rotieren müssten, wenn eine von ihnen morgen ginge. Lautet die Antwort „alles“, ist das kein Konfigurationsproblem, das sich wegstellen lässt. Es ist das Dateimodell, das genau wie vorgesehen funktioniert. Die Referenz zur Schlüsselhierarchie zeigt, wie die alternative Grenze aussieht.

Eine Datei hat einen Schlüssel für alle. Ein Tresor hat einen Schlüssel pro Tresor, verschlüsselt pro Person. Dieser Abstand wird nicht kleiner, wenn ein Team wächst; er wird größer. Wenn KeePass nicht die einzige Alternative auf Ihrer Auswahlliste ist, geht der Vergleich der Tresor-Verschlüsselungsarchitektur von Passwork und Bitwarden dieselben drei Momente (gleichzeitiges Speichern, Offboarding, Audit) für einen cloud-nativen Wettbewerber anstelle eines Dateiformats durch.

Führen Sie den Masterschlüssel-Test in Ihrem eigenen Team durch und sehen Sie sich dann die Alternative an. Kostenlose Passwork-Testversion starten.

Häufig gestellte Fragen

Passwort- und Zugriffsverwaltung für KMU: Reicht KeePass aus?

Jeder IT-Administrator, der KeePass für ein Team betreibt, erzählt dieselbe Geschichte. Es beginnt mit einer gemeinsam genutzten .kdbx-Datei auf einem Netzlaufwerk. Dann kann jemand sie nicht öffnen, weil ein Kollege sie gesperrt hat. Dann überschreibt ein junger Systemadministrator eine Änderung, die jemand anderes eine Stunde zuvor gemacht hat. Dann verlässt ein Mitarbeiter das Unternehmen, und niemand weiß genau, auf welche Passwörter er Zugriff hatte. KeePass ist ein wirklich ausgezeichnetes Werkzeug – für eine Person. Sobald Sie es einem Team vorsetzen, verwalten Sie keine Passwörter mehr. Sie verwalten ein

PassworkAlex Muntyan

Was ist Zero-Knowledge-Verschlüsselung? So funktioniert sie in 5 Minuten

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server nie Ihre Entschlüsselungsschlüssel hält, sondern nur Geheimtext. Erfahren Sie, wie die Schlüsselkette funktioniert, wogegen sie schützt, wogegen nicht und wie sich die Aussage eines Anbieters überprüfen lässt.

PassworkPasswork Team

Passwork vs Bitwarden: Tresor-Verschlüsselungsarchitektur im Vergleich

Passwork verschlüsselt jeden Tresor mit einem eigenen Schlüssel. Bitwarden verschlüsselt eine ganze Organisation mit einem gemeinsamen Schlüssel. Dieser Vergleich zeigt, was das für den Schadensumfang, die Isolation von Teams, die Kontowiederherstellung und die Audit-Antworten bedeutet, wenn Zugangsdaten abfließen.

PassworkPasswork Team

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

KeePass has better cryptographic primitives than plenty of password managers you can buy, and that's where this comparison starts. The KDBX 4 format supports a memory-hard key derivation function, authenticates its ciphertext before decrypting anything, and encrypts the whole database rather than just the password fields.

What KDBX does not have is key management for more than one person. There is one key, it belongs to a file rather than to a human, and it opens everything. Every multi-user property a team eventually needs — revoking one person's access, knowing who read a credential, bounding what a single leaked key exposes — has to be built outside the format, usually out of file system permissions and good intentions.

That is the real axis here, and it shows up in three moments: when two people save the shared database at once, when someone leaves the company, and when an auditor asks who opened a credential last quarter.

What KDBX 4 actually does

A KDBX 4 file is encrypted with AES-256 in CBC mode with PKCS#7 padding, or with ChaCha20, per the format specification. The key comes from hashing the master key components into a 256-bit value, running that through a key derivation function, then hashing the result with a fresh per-save seed. Three derivation functions ship without plugins: AES-KDF, Argon2d and Argon2id.

Integrity is where KDBX 4 pulled ahead of its predecessor. The file stores a SHA-256 hash of the header, so corruption is detectable without the master key, then an HMAC-SHA-256 of the header, and the payload is split into 1 MB blocks that each carry their own HMAC. The specification calls this "an Encrypt-then-MAC scheme," meaning authenticity is verified before anything is decrypted. KDBX 3.1 hashed the plaintext instead, and the author's note on the change is worth quoting for its restraint:

Although the Encrypt-then-MAC scheme (KDBX 4) in general is considered to be more secure than a MAC-then-Encrypt scheme (KDBX 3.1), we do not believe that KDBX 3.1 files were insecure.

Two caveats matter for a team. KDBX 3.1 is still a native format in KeePassXC, so "KeePass means Argon2 and HMAC" holds only once someone has actually migrated the database, which is a manual step in the encryption settings. And the Argon2 memory parameter is bounded by the weakest device that opens the file: KeePass suggests half the RAM of your smallest device, and warns that on iOS a large memory parameter can break AutoFill, recommending 64 MB or less there. A KDF is only as strong as the parameters your phone survives.

The scope of encryption is genuinely better than several hosted competitors: "KeePass encrypts the whole database, i.e. not only your passwords, but also your user names, URLs, notes, etc." A stolen KDBX leaks nothing about its contents, not even entry titles.

One thing looks like a second layer but is not. KDBX also applies Salsa20 or ChaCha20 to protected fields inside the XML, and the specification heads off the misreading directly:

We emphasize that the only purpose of the inner encryption is to support the process memory protection. The inner encryption has no effect on the cryptographic security of the KDBX file format.

Its key lives in the inner header and does not depend on the master key.

Where the key lives, and why that decides everything else

The KeePass master key is composite: a master password, a key file, and a key tied to the current Windows account through DPAPI, in any combination. All chosen components are required, and the Master Key documentation is blunt about it:

If you forget/lose any of the master key components (or forget the composition), all data stored in the database is lost. There is no backdoor and no universal key that can open your database.

Notice what those components share. A password is knowledge, a key file is possession, a DPAPI key is a machine account. None is an identity the database recognizes and can later distinguish from another. The key is a property of the file.

Passwork starts from the person, using the same zero-knowledge architecture principle (the server never handles anything but ciphertext) built around individual identity rather than a single file secret. Each user has their own RSA key pair generated client-side, with the private half encrypted under a key derived from their master password. A vault gets its own AES-256 key at creation, and every user with access holds a separate copy of that vault key, wrapped with their own public key (key hierarchy). The server only ever handles ciphertext (cryptography overview).

Sharing follows from that shape. Granting access re-wraps the vault key for the recipient's public key rather than re-encrypting data (sharing mechanics). Revoking it deletes that person's wrapped copy. Everyone else continues on the same vault key, and nothing is re-encrypted.

Where KeePass's cryptography is stronger for a single user

Key derivation is where it shows. Argon2 is memory-hard, which is exactly the property that makes GPU and ASIC cracking expensive, and KeePass explains why it prefers Argon2d in this setting: "a better protection against a really existing threat (password cracking using GPUs/ASICs is state of the art) is more important than a protection against certain side-channel attacks that may or may not become a problem on client devices in the future." Passwork derives the master key with PBKDF2 at 300,000 iterations over SHA-256 — a defensible, NIST-recognized setting, but not memory-hard, and against dedicated cracking hardware that distinction matters.

That doesn't change the conclusion for a team sharing credentials across more than one person: that comes down to key management, not cipher strength, and it's the question the rest of this comparison focuses on. For a single user with one laptop and one file, sharing nothing with anyone, that's the property that matters most against offline cracking attempts.

What happens when a team shares the file

Here the design goal shows. KeePass documentation on multiple users does not hedge:

All users use the same master password and/or key file to open the database. There are no per-group or per-entry access control lists (ACLs). In order to restrict write access to the database file (i.e. only a select set of users may change the stored data), use file system access rights.

Access control exists, but it lives in NTFS or your SMB share, not in the product and not in the cryptography. Read access is all-or-nothing by construction, because reading requires the one key that decrypts everything.

KeePass 2.x does detect conflicts. On Save it "first checks whether the file on disk has been modified since it was loaded," and if so offers to synchronize instead of overwriting. Merging happens at entry level, and the losing version of a conflicting entry is kept in that entry's history rather than discarded.

Conflicts resolve by comparing last modification timestamps, so the arbiter is each user's system clock rather than any notion of authority. The prompt fires only on Save: "the synchronize prompt is only triggered by the 'Save' command, not by the 'Save As' command. When executing the 'Save As' command and manually selecting a file, this file will always be overwritten." History entries survive a merge but "may be deleted by the automatic history maintenance," which is size-based. And KeePass 1.x has no synchronization at all, so a save there really does overwrite what changed underneath you.

KeePassXC differs in a way that matters if it is your client. It has a merge function in the GUI and as keepassxc-cli merge, comparing entries by UUID and modification time. But it has no built-in cloud synchronization on purpose, and the FAQ gives the reasoning: put the database in a shared cloud folder and let the sync service handle it, which "keeps the complexity of our code low." Defensible engineering, with a specific operational consequence. Dropbox, Nextcloud and OneDrive know nothing about KDBX, so simultaneous edits produce conflict copies of the file, and reconciling them is a manual merge somebody has to remember to run.

KeePass's own recommended pattern for shared files is a trigger: keep a local copy and synchronize with the master file, a scheme its documentation describes as preventing "data loss when database files are overwritten by other applications (e.g. cloud storage service software)." It works. It also means your access model now depends on a trigger stored in a configuration file that, as the Triggers page notes, is unencrypted and "applies to all users who use this KeePass installation."

Taking access back

Ask this first in any evaluation. A file-based model has no good answer to it, and the answer it does have tends to surprise people.

A departing employee had the master key. They may also have a copy of the KDBX on a laptop, in a backup, in a sync folder, or in a conflict copy nobody cleaned up. Changing the master key re-encrypts the database going forward and does nothing to copies that already exist. Those stay decryptable with the key they were saved under, indefinitely. Entry history compounds it: rotating a password inside the database keeps the previous value in that entry's history, so a stale copy carries both the old secret and the new one.

The only real revocation is rotating every credential that person could reach, which in a single-file model means all of them. The work scales with the size of your database rather than the scope of that person's job.

In Passwork the same event is bounded. Removing the user's access deletes their wrapped copy of the vault key, and remaining members continue on the unchanged key. Rotation after offboarding is still the right control for anything they actually read, and no product can un-leak a credential someone memorized. What differs is that the blast radius is a vault rather than everything, and revocation is one operation rather than a project.

Where Passwork's LDAP/Active Directory integration is configured, that operation doesn't have to be manual at all: disabling the account in AD revokes Passwork access automatically, in line with directory state, so offboarding in the directory is offboarding in the vault. And the security dashboard doesn't leave the aftermath to memory — it flags credentials still reachable by a user whose access was revoked as a compromise risk, turning what that person could reach into a visible worklist rather than something to reconstruct by hand.

Who read what

KeePass is a desktop application with no server component, a point its own notes make while dismissing a timing attack report: KeePass "does not feature any server capabilities (especially, no automatic database opening can be triggered externally)."

That has an audit consequence. KDBX records modification timestamps and entry history, which is a log of changes to the file, not a log of access. Nothing records that someone opened the database and read a credential, because the read happens entirely on the client. With one shared master key, even a change record cannot reliably tell you which human made it.

Passwork logs actions server-side and can forward them in CEF to syslog or the Windows event log for a SIEM (activity log, event list). Grants, changes and revocations are recorded individually and attributed to an account.

Trusting a file that everyone edits

The sharpest argument against the shared-database pattern comes from KeePass's own documentation.

KeePass supports placeholders inside entries. {CMD:...} runs a command line, and field references can pull data from other entries, so a crafted URL can exfiltrate a different credential. The Security page gives the example itself: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. The guidance that follows is unambiguous:

When opening a database that has been created/modified by someone else, you should carefully check all data that you want to use. If you do not fully trust the creator of the database, do not open any files attached to entries.

Read that against a shared-drive deployment. A team database is by definition created and modified by other people, and everyone with write access can add entries the others will click. The trust model KeePass documents assumes a database has one owner who vouches for its contents, which is precisely what a shared team file is not.

Documented vulnerabilities

CVE-2023-32784 (CVSS 7.5) allowed recovering the cleartext master password from a memory dump in KeePass 2.x before 2.54, including from a swap or hibernation file and even after the process exited, with only the first character unrecoverable. The cause was a custom text box leaving per-character remnants in .NET memory. It was fixed in 2.54, and the researcher credited a fast response.

CVE-2023-24055 (CVSS 5.5) is tagged disputed by MITRE. An attacker with write access to the XML configuration file could add an export trigger and harvest cleartext passwords. The NVD entry records the vendor's position: "the password database is not intended to be secure against an attacker who has that level of access to the local PC." That position is consistent, and the Security Issues page argues it generally: someone who can write your configuration file can usually replace the executable instead.

For balance, KeePassXC has had an external audit, completed January 2023, and says openly that an audit "is valid only for a 'snapshot' of the code."

Comparison table

Migrating, and what to watch during it

Passwork imports KeePass XML, alongside JSON and CSV. It does not read the encrypted KDBX binary, and parsing happens in the client rather than on the server, which is the only arrangement consistent with the server never seeing plaintext.

The consequence deserves stating rather than glossing. Exporting from KeePass to XML produces an unencrypted file containing every credential, and it sits on disk for as long as the migration takes. Do it on a machine you control, on local storage rather than a synced folder, and delete it with a tool that overwrites rather than unlinks. It is the one step in a migration where a careless afternoon undoes both products' cryptography at once.

When KeePass is the right answer

If you are specifically weighing whether KeePass is enough for a small team, Password and access management for SMBs: Is KeePass enough? covers that question directly. This article stays narrower, on the encryption-architecture axis alone, for teams of any size.

If you are one person, or two people who genuinely share everything anyway, KeePass with a KDBX 4 database and sensible Argon2 parameters is an excellent choice, and it is free. The cryptography is strong, the format is publicly documented, and with no server there is no service to breach.

The model stops fitting when you need answers a file cannot give. Who has access to this, specifically. What exactly got lost when that laptop went missing. What breaks when this person leaves on Friday. Prove the contractor never saw production credentials.

A useful test before deciding: count how many people hold the master key to your shared database today, then ask what you would have to rotate if any one of them left tomorrow. If the answer is "everything," that is not a configuration problem you can tune away. It is the file model working as designed. The key hierarchy reference shows what the alternative boundary looks like.

A file has one key for everyone. A vault has one key per vault, wrapped per person. That gap does not shrink as a team grows; it compounds. If KeePass is not the only alternative on your shortlist, the comparison of Passwork's and Bitwarden's vault encryption architecture walks through the same three moments (concurrent saves, offboarding, audit) for a cloud-native competitor instead of a file format.

Run the master-key test on your own team, then see the alternative. Start a free trial of Passwork.

Frequently asked questions

Password and access management for SMBs: Is KeePass enough?

Every IT admin who runs KeePass for a team tells the same story. It starts with one shared .kdbx file on a network drive. Then someone can’t open it because a colleague has it locked. Then a junior sysadmin saves over a change someone else made an hour ago. Then an employee leaves, and nobody’s quite sure which passwords they had access to. KeePass is a genuinely excellent tool — for one person. The moment you put it in front of a team, you’re not managing passwords anymore. You’re managing a s

PassworkAlex Muntyan

What is zero-knowledge encryption? How it works in 5 minutes

Zero-knowledge encryption means the server never holds your decryption keys, only ciphertext. Learn how the key chain works, what it protects against, what it doesn’t, and how to verify a vendor’s claim.

PassworkPasswork Team

Passwork vs Bitwarden: How vault encryption architecture differs

Passwork encrypts every vault with its own key. Bitwarden encrypts an entire organization with one shared key. This comparison breaks down what that means for blast radius, team isolation, account recovery, and audit answers when a credential leaks.

PassworkPasswork Team

Nos próximos tempos, os computadores quânticos não conseguirão quebrar por força bruta uma palavra-passe de 16 caracteres devidamente protegida por hash. O algoritmo de Grover apenas reduz para metade o expoente de uma pesquisa de hash, e não o problema inteiro. O que um computador quântico suficientemente potente quebra é a troca de chaves RSA e de curva elíptica que transporta essa palavra-passe até ao servidor, e o NIST já fixou o prazo de 2030 para a sua substituição.

Dois problemas distintos são reduzidos a uma única manchete: «os computadores quânticos vão quebrar as palavras-passe». Este guia mantém-nos separados e propõe depois às equipas de TI e de segurança um fluxo de trabalho para verificar qual dos dois se aplica realmente ao respetivo conjunto de palavras-passe e quais as partes desse conjunto que podem esperar.

Os dois algoritmos quânticos que importam (Shor vs Grover)

Dois algoritmos quânticos são relevantes para a segurança das palavras-passe, e desempenham funções diferentes. O algoritmo de Shor proporciona uma aceleração exponencial contra a matemática subjacente ao RSA e à criptografia de curva elíptica, o que quebra a troca de chaves assim que existir um computador quântico suficientemente potente. O algoritmo de Grover proporciona apenas uma aceleração quadrática contra a pesquisa simétrica, reduzindo a resistência efetiva para metade, e não para zero.

A diferença entre exponencial e quadrático explica tudo. Uma aceleração quadrática contra um hash de 128 bits deixa ainda cerca de 2⁶⁴ operações por tentar, o que é computacionalmente enorme hoje, e uma função com uso intensivo de memória (memory-hard), como o Argon2id, multiplica esse custo ainda mais. Uma aceleração exponencial contra o RSA-2048 não deixa uma margem comparável.

Para uma análise mais aprofundada dos mecanismos dos esquemas pós-quânticos baseados em reticulados e de outros tipos, consulte o artigo explicativo sobre o que é a criptografia quântica; este guia centra-se no que muda especificamente para a infraestrutura de palavras-passe.

Porque é que o hash da palavra-passe não é o verdadeiro alvo

Uma palavra-passe com um hash adequado continua a ser dispendiosa de quebrar mesmo com o algoritmo de Grover, porque o custo da função de hash se aplica a cada tentativa individual que um computador quântico faz. O Argon2id e o bcrypt são memory-hard por conceção, pelo que reduzir o expoente para metade continua a obrigar o atacante a pagar um preço elevado por tentativa.

Considere uma palavra-passe aleatória de 16 caracteres, retirados do conjunto completo de 95 caracteres imprimíveis: cerca de 105 bits de entropia antes de o hash ser aplicado. A aceleração quadrática de Grover reduz esse expoente para cerca de metade, o que deixa o atacante com cerca de 2⁵² operações efetivas. Esse número continua fora do alcance de qualquer computador quântico em discussão séria atualmente, e o custo memory-hard do Argon2id multiplica ainda o preço de cada tentativa.

Nem todas as funções de hash oferecem esta proteção de forma igual. O PBKDF2 é limitado pela CPU e é mais barato de paralelizar em hardware personalizado. O Argon2id e o bcrypt obrigam o atacante a pagar em memória, além de tempo, o que pesa cada vez mais à medida que melhoram as técnicas de quebra com GPU e ASIC, quânticas ou não. O uso de salt continua a ser obrigatório, independentemente do algoritmo: impede ataques com rainbow tables pré-calculadas e obriga a que cada tentativa seja executada individualmente contra um único hash.

O guia sobre hash e salting de palavras-passe explica em maior detalhe o funcionamento de cada função, incluindo a razão pela qual um mínimo de 16 caracteres se tornou o patamar prático.

A camada que realmente quebra: Troca de chaves

O RSA-2048 e a troca de chaves ECDH são aqui o verdadeiro alvo. O algoritmo de Shor torna tratável a decomposição em fatores em que assenta o RSA e o cálculo dos logaritmos discretos em que assenta a ECC, o que quebra handshakes TLS, sessões SSH, túneis VPN e qualquer encapsulamento de chaves privadas baseado nas mesmas primitivas.

A criptografia de chave pública transporta esse risco para a infraestrutura quotidiana em mais locais do que a maioria das equipas contabiliza:

• Handshakes TLS 1.3: troca de chaves RSA ou ECDHE, certificados ECDSA
• Troca de chaves SSH de host e de utilizador
• Negociação de túneis VPN
• Encapsulamento de chaves privadas na hierarquia de chaves de um gestor de palavras-passe
• Certificados de assinatura de código e de documentos

O fundamento matemático deste risco não é hipotético. A Google Quantum AI publicou em maio de 2025 um preprint que demonstra que o RSA de 2048 bits poderia, em teoria, ser decomposto em fatores por um computador quântico com correção de erros suficientemente grande. A máquina ainda não existe. A matemática que o quebraria já existe.

Um gestor de palavras-passe encontra-se nesta mesma lista. Partilhar um cofre com um novo membro da equipa, sincronizar um registo entre dispositivos ou desencapsular uma chave privada no início de sessão dependem, em algum ponto da cadeia, de uma operação assimétrica. A auditoria da pilha criptográfica do gestor de palavras-passe deve constar do mesmo inventário que os endpoints TLS e os concentradores VPN.

Harvest now, decrypt later: A ameaça que já existe hoje

O harvest now, decrypt later (recolher agora, decifrar depois) descreve um atacante que grava hoje tráfego cifrado e o decifra quando existir um computador quântico capaz. Reformula o argumento de que «a computação quântica está a dez anos de distância» como «a recolha já começou», o que é relevante para qualquer dado cuja confidencialidade tenha de se manter durante uma década ou mais.

O 2026 Quantum & AI Threat Report da Thales inquiriu 3120 profissionais de segurança e de TI em 20 países e concluiu que o harvest-now-decrypt-later é a sua principal preocupação quântica, citada por 61 % dos inquiridos, à frente da descontinuação de algoritmos ou dos prazos de conformidade. Os adversários com paciência para esperar anos por um retorno, tipicamente atores estatais, são quem realiza esta recolha atualmente.

A exposição concentra-se nos dados que têm de permanecer confidenciais durante anos: registos médicos, documentos jurídicos, propriedade intelectual, comunicações governamentais. Uma chave de sessão TLS descartada no momento em que a ligação é fechada é um alvo pouco interessante. Um arquivo de 2024 protegido por encapsulamento RSA e ainda guardado numa banda magnética de cópia de segurança em 2034 é exatamente o alvo desta ameaça, tal como uma exportação cifrada de um cofre guardada numa cópia de segurança desativada que ninguém se lembrou de eliminar.

O que o NIST realmente decidiu e os prazos vinculativos

O NIST finalizou as suas três primeiras normas de criptografia pós-quântica em agosto de 2024: a FIPS 203 (ML-KEM) para troca de chaves, e a FIPS 204 (ML-DSA) e a FIPS 205 (SLH-DSA) para assinaturas digitais. O documento NIST IR 8547 definiu depois o calendário de conformidade, descontinuando o RSA, o ECDSA e o EdDSA após 2030 e proibindo-os após 2035.

A criptografia simétrica com segurança de 128 bits ou superior não é afetada por nada disto. O AES-256 não exige qualquer alteração de algoritmo. Os prazos visam especificamente a camada assimétrica: RSA, ECDSA e EdDSA, substituídos por ML-KEM e ML-DSA. A Commercial National Security Algorithm Suite 2.0 reflete este calendário para os sistemas de segurança nacional dos EUA, um sinal da seriedade com que as equipas de aquisição devem encarar o assunto.

O NIST IR 8547 apresenta a migração pós-quântica como um esforço de engenharia plurianual, da ordem de uma década para integrar em produtos e infraestruturas, o que constitui o verdadeiro argumento para iniciar um inventário agora em vez de esperar até 2029. O roteiro quântico público da IBM fixa como objetivo um sistema com mais de 100 000 qubits até 2033. É o objetivo declarado pelo próprio fornecedor, e não uma projeção independente, mas dá uma data aproximada para o momento em que «suficientemente grande» deixa de ser teórico.

Integrar desde já a agilidade criptográfica (crypto agility) nas aquisições, isto é, a capacidade de substituir um algoritmo sem reestruturar um produto, é o que transforma isto numa migração planeada e não numa correria.

A Auditoria de Exposição Quântica em 3 Camadas

A execução desta auditoria demora uma tarde, e não um projeto de consultoria. Classifique o conjunto de palavras-passe em três camadas, e cada uma recebe o seu próprio veredicto: seguro, vigiar ou agir já.

A camada 1 é aquela com que as equipas mais se preocupam e com que menos precisam de se preocupar. Se os hashes das palavras-passe de início de sessão e das palavras-passe mestras do gestor de palavras-passe já utilizarem Argon2id, PBKDF2 ou bcrypt com um fator de trabalho razoável, o algoritmo de Grover não altera o cálculo de risco. A única lacuna real que vale a pena resolver: um sistema legado que ainda use MD5 ou SHA-1 sem salt já estava comprometido antes de a computação quântica entrar na conversa.

A camada 2 é onde um administrador costuma encontrar a lacuna real: um concentrador VPN ainda preso ao RSA-2048, uma infraestrutura de chave pública (PKI) interna que emite certificados ECDSA sem plano de renovação, uma API legada que nunca passou do TLS 1.2. Inventarie todos os pontos em que o RSA, o ECDH ou o ECDSA realizam uma troca de chaves e comece pelo que protege o tráfego de maior longevidade.

A camada 3 diz respeito ao que já foi recolhido, e não ao que será cifrado amanhã. Importa perguntar que dados a organização protege hoje que ainda precisarão de confidencialidade em 2035: retenções por motivos legais, tabelas de capitalização, código-fonte, tudo o que esteja abrangido por um acordo de confidencialidade plurianual. Depois, há que verificar se essa confidencialidade depende de uma troca de chaves assimétrica realizada há anos.

Execute a auditoria uma vez e integre-a depois na cadência que a equipa já utiliza para o inventário criptográfico. Anualmente é razoável. Com maior frequência, se este ano estiver prevista a emissão de uma nova PKI ou a renegociação de um contrato de VPN.

Como ler a documentação criptográfica de um gestor de palavras-passe

A documentação criptográfica de um gestor de palavras-passe deve indicar exatamente o que protege o cofre em cada camada. Uma referência vaga a «cifragem de nível militar» não conta. Procure algoritmos identificados pelo nome, tamanhos de chave declarados, uma função de derivação de chaves identificada e uma posição pública sobre a migração pós-quântica.

O que publica um fornecedor atento à ameaça quântica:

• A cifra simétrica exata e o tamanho de chave que protegem os dados do cofre (AES-128 e AES-256 não oferecem a mesma margem, pelo que «AES» por si só não basta)
• O algoritmo assimétrico exato utilizado para a troca de chaves e o encapsulamento de chaves privadas
• A função de derivação de chaves e o número de iterações que transformam uma palavra-passe mestra numa chave de cifragem
• Se a cifragem ocorre no lado do cliente, no modelo de zero-knowledge, ou apenas em repouso no servidor

A documentação do próprio Passwork é um exemplo razoável do aspeto que essa transparência tem na prática. A sua cifragem do lado do cliente aplica AES-256 aos dados de cofres e de registos, com uma camada AES-256 separada a proteger a base de dados em repouso. A partir de uma palavra-passe mestra, o PBKDF2 (HMAC-SHA-256) deriva uma chave mestra de 512 bits, que desencapsula uma chave privada RSA-2048 que, por sua vez, desencapsula as chaves de cada cofre e de cada registo, uma hierarquia documentada na visão geral da criptografia.

Se esta pilha for submetida à Auditoria de 3 Camadas, a resposta honesta é simples. A camada de dados AES-256 mantém-se resistente a ataques quânticos com os tamanhos de chave atuais; a camada de troca de chaves RSA-2048 é o componente a vigiar à medida que as normas pós-quânticas amadurecem em todo o setor. É a mesma resposta que qualquer fornecedor que encapsule chaves com RSA deve dar hoje: uma camada AES-256 documentada que não precisa de mudar e uma camada assimétrica com um caminho de migração reconhecido, e não a afirmação de que tudo já está à prova de ataques quânticos. O artigo explicativo sobre o AES-256 aborda a razão pela qual a margem do tamanho da chave importa por si só.

Se a equipa estiver a iniciar o seu próprio inventário criptográfico, o Passwork publica exatamente este tipo de pilha AES-256/RSA-2048 documentada, com registos de auditoria exportáveis para alimentar diretamente a revisão da camada 2. Iniciar um teste gratuito

O que fazer hoje (e o que pode esperar)

Comece pelo que protege hoje a troca de chaves TLS, SSH e VPN, uma vez que é a camada com um prazo real, em 2030. A adoção de passkeys, os testes de troca de chaves híbrida e um inventário criptográfico documentado podem decorrer em paralelo. Renovar as chaves de implementações AES-256 ou preocupar-se com a resistência dos hashes de palavras-passe pode esperar.

Fazer agora:

1. Inventariar todos os pontos em que o RSA, o ECDH ou o ECDSA realizam uma troca de chaves: endpoints TLS, hosts SSH, concentradores VPN, PKI interna.
2. Confirmar que o gestor de palavras-passe e o fornecedor de identidade publicam a sua pilha criptográfica real, em vez de uma referência vaga a «cifragem de nível bancário». Se um fornecedor não indicar, a pedido, os seus algoritmos e tamanhos de chave, essa é a resposta.
3. Ativar a autenticação multifator (MFA) em todos os sistemas onde ainda não seja obrigatória. Não toca diretamente na questão quântica, mas reduz a exposição enquanto a migração decorre.

Planear este ano:

4. Incluir a troca de chaves híbrida (clássica mais ML-KEM) nas conversas sobre o roteiro com os fornecedores, sobretudo para tudo o que enfrente um prazo em 2030.
5. Dar prioridade à adoção de passkeys na autenticação dirigida aos utilizadores. A agilidade algorítmica do FIDO2 significa que o caminho de migração já existe, embora as passkeys atuais ainda utilizem ECDSA, e a própria adoção reduz a parte do conjunto de palavras-passe que ainda depende de um hash de palavra-passe.
6. Eliminar os endpoints TLS 1.2 que ainda subsistam. A atualização para TLS 1.3 é um pré-requisito para a troca de chaves pós-quântica, e não um projeto separado.

Vigiar:

7. Os roteiros de hardware quântico da IBM e da Google. Um salto para além dos marcos do calendário do NIST acima indicado anteciparia os prazos, em vez de simplesmente os confirmar.
8. As orientações do NIST sobre modos híbridos e puramente pós-quânticos, à medida que as implementações das FIPS 203, 204 e 205 amadurecem nas bibliotecas TLS e SSH de uso generalizado.

Nada disto exige a substituição de um gestor de palavras-passe existente. Se este já publicar uma pilha AES-256/RSA-2048 como a descrita acima, a plataforma está a fazer a sua parte; o trabalho de inventário acima descrito cabe à organização.

Conclusão

Os computadores quânticos não vêm atrás do hash da palavra-passe. Vêm atrás da troca de chaves RSA e ECC que a transporta, e o NIST já marcou datas no calendário: 2030 para descontinuar, 2035 para proibir. A Auditoria de Exposição Quântica em 3 Camadas transforma esse risco abstrato em três verificações concretas que uma equipa pode executar neste trimestre, uma das quais provavelmente pode ficar concluída ainda esta tarde.

Comece pela camada 2. Reúna a lista de todos os locais onde o RSA, o ECDH ou o ECDSA tratam de um handshake no ambiente e saberá, num dia, que fornecedores exigem uma conversa sobre migração e quais já a iniciaram.

Se a equipa estiver a elaborar esse inventário, o Passwork disponibiliza um cofre AES-256/RSA-2048 documentado, com registos de auditoria exportáveis para alimentar diretamente esse trabalho. Iniciar um teste gratuito

Perguntas frequentes

O que é a cifragem zero-knowledge? Como funciona em 5 minutos

A cifragem zero-knowledge significa que o servidor nunca detém as chaves de decifragem, apenas o texto cifrado. Saiba como funciona a cadeia de chaves, contra o que protege, contra o que não protege e como verificar a afirmação de um fornecedor.

PassworkPasswork Team

Gestão de acessos para PME: A primeira camada de cibersegurança

A gestão de acessos deve estar no topo da lista de verificação de cibersegurança das PME. Saiba como configurar identidade, autenticação, autorização e revogação como um sistema que resiste ao dia a dia.

PassworkPasswork Team

O que é a PKI? Infraestrutura de chave pública explicada para 2026

Até 2029, os certificados passarão a expirar a cada 47 dias. Eis o que é realmente a PKI, como funciona e as credenciais humanas que mantêm a CA em funcionamento, e que a própria PKI não protege.

PassworkPasswork Team

Quantencomputer werden ein korrekt gehashtes 16-stelliges Passwort auf absehbare Zeit nicht per Brute Force knacken. Grovers Algorithmus halbiert lediglich den Exponenten einer Hash-Suche, nicht das ganze Problem. Was ein ausreichend großer Quantencomputer tatsächlich bricht, ist der RSA- und Elliptic-Curve-Schlüsselaustausch, der dieses Passwort zu Ihrem Server transportiert – und für dessen Ersatz hat NIST bereits eine Frist bis 2030 gesetzt.

Zwei getrennte Probleme werden zu einer Schlagzeile verdichtet: „Quantencomputer werden Ihre Passwörter brechen.“ Dieser Leitfaden hält sie auseinander und gibt IT- und Sicherheitsteams anschließend einen Arbeitsablauf an die Hand, mit dem sie prüfen können, welches der beiden tatsächlich auf ihren eigenen Passwortbestand zutrifft und welche Teile dieses Bestands warten können.

Die zwei relevanten Quantenalgorithmen (Shor vs. Grover)

Für die Passwortsicherheit sind zwei Quantenalgorithmen relevant, und sie leisten Unterschiedliches. Shors Algorithmus liefert eine exponentielle Beschleunigung gegen die Mathematik hinter RSA und Elliptic-Curve-Kryptografie und bricht damit den Schlüsselaustausch, sobald ein ausreichend großer Quantencomputer existiert. Grovers Algorithmus liefert lediglich eine quadratische Beschleunigung gegen symmetrische Suche und halbiert die effektive Stärke, statt sie auf null zu senken.

Der Unterschied zwischen exponentiell und quadratisch ist die ganze Geschichte. Eine quadratische Beschleunigung gegen einen 128-Bit-Hash lässt immer noch rund 2⁶⁴ Operationen übrig, was heute rechnerisch enorm ist, und eine Memory-hard-Funktion wie Argon2id vervielfacht diese Kosten weiter. Eine exponentielle Beschleunigung gegen RSA-2048 lässt keinen vergleichbaren Spielraum.

Die tiefere Mechanik gitterbasierter und anderer Post-Quanten-Verfahren erläutert unser Beitrag dazu, was Quantenkryptografie ist; dieser Leitfaden bleibt darauf fokussiert, was sich speziell für die Passwortinfrastruktur ändert.

Warum Ihr Passwort-Hash nicht das eigentliche Ziel ist

Ein korrekt gehashtes Passwort bleibt auch unter Grovers Algorithmus teuer zu knacken, weil die Kosten der Hash-Funktion bei jedem einzelnen Rateversuch eines Quantencomputers anfallen. Argon2id und bcrypt sind konstruktionsbedingt memory-hard, sodass eine Halbierung des Exponenten einem Angreifer immer noch einen hohen Preis pro Versuch abverlangt.

Nehmen Sie ein 16-stelliges Zufallspasswort aus dem vollständigen Zeichensatz von 95 druckbaren Zeichen: rund 105 Bit Entropie, bevor das Hashing greift. Grovers quadratische Beschleunigung halbiert diesen Exponenten in etwa, womit ein Angreifer bei rund 2⁵² effektiven Operationen landet. Diese Zahl bleibt für jeden Quantencomputer, der heute ernsthaft diskutiert wird, unerreichbar, und der Memory-hard-Aufwand von Argon2id vervielfacht den Preis jedes Rateversuchs obendrein.

Nicht jede Hash-Funktion bietet diesen Schutz im gleichen Maß. PBKDF2 ist CPU-gebunden und lässt sich auf spezialisierter Hardware günstiger parallelisieren. Argon2id und bcrypt zwingen einen Angreifer, nicht nur mit Zeit, sondern auch mit Speicher zu bezahlen, was mit besserem GPU- und ASIC-Cracking immer stärker ins Gewicht fällt, quantenbasiert oder nicht. Salting bleibt unabhängig vom Algorithmus verpflichtend: Es verhindert vorberechnete Rainbow-Table-Angriffe und zwingt jeden Rateversuch, einzeln gegen einen einzelnen Hash zu laufen.

Unser Leitfaden zu Passwort-Hashing und Salting behandelt die Mechanik jeder Funktion ausführlicher, einschließlich der Frage, warum ein Minimum von 16 Zeichen zur praktischen Untergrenze geworden ist.

Die Schicht, die wirklich bricht: Schlüsselaustausch

RSA-2048 und der ECDH-Schlüsselaustausch sind hier das eigentliche Ziel. Shors Algorithmus macht die Faktorisierung der Mathematik hinter RSA und die Berechnung der diskreten Logarithmen hinter ECC praktisch lösbar, was TLS-Handshakes, SSH-Sitzungen, VPN-Tunnel und jedes Wrapping privater Schlüssel bricht, das auf denselben Primitiven aufbaut.

Public-Key-Kryptografie trägt dieses Risiko an mehr Stellen in die alltägliche Infrastruktur, als die meisten Teams erfassen:

• TLS-1.3-Handshakes: RSA- oder ECDHE-Schlüsselaustausch, ECDSA-Zertifikate
• SSH-Schlüsselaustausch für Hosts und Benutzer
• Aushandlung von VPN-Tunneln
• Wrapping privater Schlüssel innerhalb der Schlüsselhierarchie eines Passwortmanagers
• Zertifikate für Code- und Dokumentsignierung

Die Mathematik hinter diesem Risiko ist nicht hypothetisch. Google Quantum AI hat im Mai 2025 ein Preprint veröffentlicht, das zeigt, dass RSA mit 2048 Bit theoretisch von einem ausreichend großen fehlerkorrigierten Quantencomputer faktorisiert werden könnte. Die Maschine existiert noch nicht. Die Mathematik, die es brechen würde, existiert bereits.

Ein Passwortmanager steht auf derselben Liste. Einen Tresor mit einem neuen Teammitglied teilen, einen Datensatz zwischen Geräten synchronisieren oder beim Login einen privaten Schlüssel entpacken – alles hängt irgendwo in der Kette von einer asymmetrischen Operation ab. Das Audit des Krypto-Stacks Ihres Passwortmanagers gehört in dasselbe Inventar wie Ihre TLS-Endpunkte und VPN-Konzentratoren.

Harvest now, decrypt later: Die Bedrohung, die heute existiert

Harvest now, decrypt later beschreibt einen Angreifer, der heute verschlüsselten Datenverkehr aufzeichnet und ihn entschlüsselt, sobald ein leistungsfähiger Quantencomputer existiert. Damit wird aus „Quanten sind zehn Jahre entfernt“ ein „die Sammlung hat längst begonnen“, was für alle Daten zählt, deren Vertraulichkeit ein Jahrzehnt oder länger überdauern muss.

Thales hat in 20 Ländern 3.120 Sicherheits- und IT-Experten für den Quantum & AI Threat Report 2026 befragt und dabei festgestellt, dass Harvest-now-decrypt-later deren größte quantenbezogene Sorge ist, genannt von 61 % der Befragten und damit vor Algorithmus-Abkündigung oder Compliance-Fristen. Angreifer mit der Geduld, jahrelang auf einen Ertrag zu warten, typischerweise staatliche Akteure, sind diejenigen, die diese Sammlung heute betreiben.

Die Exposition konzentriert sich auf Daten, die jahrelang vertraulich bleiben müssen: Krankenakten, Gerichtsakten, geistiges Eigentum, Behördenkommunikation. Ein TLS-Sitzungsschlüssel, der mit dem Schließen der Verbindung verworfen wird, ist ein schlechtes Ziel. Ein RSA-umschlossenes Archiv aus dem Jahr 2024, das 2034 noch auf einem Backup-Band liegt, ist genau das, worauf diese Bedrohung zielt – und ebenso ein verschlüsselter Tresor-Export in einem außer Betrieb genommenen Backup, an dessen Löschung niemand gedacht hat.

Was NIST tatsächlich entschieden hat und welche Fristen gelten

NIST hat im August 2024 seine ersten drei Standards für Post-Quanten-Kryptografie finalisiert: FIPS 203 (ML-KEM) für den Schlüsselaustausch, FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) für digitale Signaturen. NIST IR 8547 hat anschließend die Compliance-Uhr gestellt: RSA, ECDSA und EdDSA werden nach 2030 abgekündigt und nach 2035 nicht mehr zugelassen.

Symmetrische Kryptografie mit 128 Bit Sicherheit oder mehr ist davon nicht betroffen. AES-256 braucht keinen Algorithmuswechsel. Die Fristen zielen speziell auf die asymmetrische Schicht: RSA, ECDSA und EdDSA, ersetzt durch ML-KEM und ML-DSA. Die Commercial National Security Algorithm Suite 2.0 spiegelt diesen Zeitplan für US-amerikanische Systeme der nationalen Sicherheit, ein Signal dafür, wie ernst Beschaffungsteams ihn nehmen sollen.

NIST IR 8547 stellt die Post-Quanten-Migration als mehrjährige Entwicklungsaufgabe dar, in der Größenordnung eines Jahrzehnts, um sie über Produkte und Infrastruktur hinweg zu integrieren – das ist das eigentliche Argument dafür, jetzt mit einem Inventar zu beginnen und nicht bis 2029 zu warten. IBM verfolgt mit seiner öffentlichen Quanten-Roadmap bis 2033 ein System mit mehr als 100.000 Qubits. Das ist das erklärte Ziel des Anbieters selbst, keine unabhängige Prognose, aber es setzt ein ungefähres Datum dafür, ab wann „groß genug“ nicht mehr theoretisch ist.

Kryptoagilität jetzt in die Beschaffung einzubauen, also die Fähigkeit, einen Algorithmus zu tauschen, ohne die Architektur eines Produkts neu aufzusetzen, macht daraus statt einer Hauruckaktion eine planmäßige Migration.

Das 3-Schichten-Audit der Quantenexposition

Dieses Audit dauert einen Nachmittag, kein Beratungsprojekt. Sortieren Sie Ihren Passwortbestand in drei Schichten, und jede erhält ihre eigene Bewertung: sicher, beobachten oder jetzt handeln.

Schicht 1 ist die Schicht, um die Teams sich am meisten sorgen und um die sie sich am wenigsten sorgen müssen. Wenn Ihre Hashes für Login und Masterpasswort des Passwortmanagers bereits Argon2id, PBKDF2 oder bcrypt mit einem angemessenen Kostenfaktor verwenden, ändert Grovers Algorithmus Ihre Risikorechnung nicht. Die eine echte Lücke, die es zu verfolgen lohnt: Ein Altsystem, auf dem noch MD5 oder ungesalzenes SHA-1 läuft, war schon gebrochen, bevor Quanten in die Diskussion kamen.

Schicht 2 ist die Stelle, an der ein Administrator üblicherweise die tatsächliche Lücke findet: ein VPN-Konzentrator, der noch auf RSA-2048 festgelegt ist, eine interne PKI, die ECDSA-Zertifikate ohne Erneuerungsplan ausstellt, eine alte API, die nie über TLS 1.2 hinausgekommen ist. Inventarisieren Sie jede Stelle, an der RSA, ECDH oder ECDSA einen Schlüsselaustausch durchführt, und beginnen Sie mit dem, was Ihren langlebigsten Datenverkehr schützt.

Schicht 3 dreht sich um das, was bereits gesammelt wurde, nicht um das, was morgen verschlüsselt wird. Fragen Sie, welche Daten Ihre Organisation heute schützt, die 2035 noch vertraulich sein müssen: Legal Holds, Cap-Tables, Quellcode, alles unter einem mehrjährigen NDA. Prüfen Sie dann, ob diese Vertraulichkeit von einem asymmetrischen Schlüsselaustausch abhängt, der vor Jahren durchgeführt wurde.

Führen Sie das Audit einmal durch und binden Sie es dann in den Rhythmus ein, den Ihr Team ohnehin für ein Krypto-Inventar nutzt. Jährlich ist angemessen. Häufiger, wenn Sie in diesem Jahr eine neue PKI ausrollen oder einen VPN-Vertrag neu verhandeln.

Die Krypto-Dokumentation eines Passwortmanagers lesen

Die Krypto-Dokumentation eines Passwortmanagers sollte genau benennen, was Ihren Tresor auf jeder Schicht schützt. Eine vage Behauptung von „Verschlüsselung auf Militärniveau“ zählt nicht. Achten Sie auf benannte Algorithmen, angegebene Schlüssellängen, eine benannte Schlüsselableitungsfunktion und eine öffentliche Position zur Post-Quanten-Migration.

Was ein quantenbewusster Anbieter veröffentlicht:

• Die genaue symmetrische Chiffre und Schlüssellänge, die Tresordaten schützt (AES-128 und AES-256 bieten nicht denselben Spielraum, „AES“ allein genügt also nicht)
• Den genauen asymmetrischen Algorithmus für Schlüsselaustausch und das Wrapping privater Schlüssel
• Die Schlüsselableitungsfunktion und die Iterationszahl, die aus einem Masterpasswort einen Verschlüsselungsschlüssel machen
• Ob die Verschlüsselung clientseitig erfolgt, nach dem Zero-Knowledge-Modell, oder nur im Ruhezustand auf dem Server

Passwork liefert mit seiner eigenen Dokumentation ein vernünftiges Beispiel dafür, wie diese Transparenz in der Praxis aussieht. Die clientseitige Verschlüsselung wendet AES-256 auf Tresor- und Datensatzdaten an, mit einer separaten AES-256-Schicht, die die Datenbank im Ruhezustand schützt. Aus einem Masterpasswort wird über PBKDF2 (HMAC-SHA-256) ein 512-Bit-Masterschlüssel abgeleitet, der einen privaten RSA-2048-Schlüssel entpackt, und dieser entpackt wiederum die Schlüssel pro Tresor und pro Datensatz – diese Hierarchie dokumentiert die Kryptografie-Übersicht.

Lässt man diesen Stack durch das 3-Schichten-Audit laufen, ist die ehrliche Antwort eindeutig. Die AES-256-Datenschicht bleibt bei den aktuellen Schlüssellängen quantenresistent; die RSA-2048-Schicht für den Schlüsselaustausch ist die Komponente, die zu beobachten ist, während die Post-Quanten-Standards branchenweit reifen. Das ist dieselbe Antwort, die Ihnen heute jeder Anbieter geben sollte, der Schlüssel mit RSA umschließt: eine dokumentierte AES-256-Schicht, die sich nicht ändern muss, und eine asymmetrische Schicht mit einem eingeräumten Migrationspfad, nicht die Behauptung, alles sei bereits quantensicher. Unser Beitrag zu AES-256 erklärt, warum der Spielraum bei der Schlüssellänge für sich genommen zählt.

Wenn Ihr Team sein eigenes Krypto-Inventar beginnt, liefert Passwork genau einen solchen dokumentierten AES-256/RSA-2048-Stack, mit exportierbaren Audit-Logs, die direkt in Ihre Prüfung von Schicht 2 einfließen. Kostenlose Testversion starten

Was heute zu tun ist (und was warten kann)

Beginnen Sie mit dem, was heute den Schlüsselaustausch von TLS, SSH und VPN schützt, denn das ist die Schicht mit einer tatsächlichen Frist bis 2030. Passkey-Rollout, Tests für hybriden Schlüsselaustausch und ein dokumentiertes Krypto-Inventar können parallel laufen. Das Neuverschlüsseln von AES-256-Installationen oder die Sorge um die Stärke von Passwort-Hashes kann warten.

Jetzt erledigen:

1. Inventarisieren Sie jede Stelle, an der RSA, ECDH oder ECDSA einen Schlüsselaustausch durchführt: TLS-Endpunkte, SSH-Hosts, VPN-Konzentratoren, interne PKI.
2. Vergewissern Sie sich, dass Ihr Passwortmanager und Ihr Identity-Provider ihren tatsächlichen Krypto-Stack veröffentlichen statt einer vagen Behauptung von „Verschlüsselung auf Bankenniveau“. Wenn ein Anbieter seine Algorithmen und Schlüssellängen auf Anfrage nicht benennt, behandeln Sie das als die Antwort.
3. Aktivieren Sie MFA überall dort, wo sie nicht bereits verpflichtend ist. Das berührt die Quantenfrage nicht direkt, schließt aber Lücken, während die Migration läuft.

In diesem Jahr planen:

4. Bringen Sie hybriden Schlüsselaustausch (klassisch plus ML-KEM) in die Roadmap-Gespräche mit Ihren Anbietern, insbesondere für alles, was einer Frist bis 2030 unterliegt.
5. Priorisieren Sie den Passkey-Rollout für die Authentifizierung von Endbenutzern. Die Algorithmusagilität von FIDO2 bedeutet, dass der Migrationspfad bereits existiert, auch wenn heutige Passkeys noch ECDSA verwenden, und der Rollout selbst verringert, wie viel Ihres Bestands überhaupt noch von einem Passwort-Hash abhängt.
6. Beseitigen Sie verbliebene TLS-1.2-Endpunkte. Das Update auf TLS 1.3 ist eine Voraussetzung für Post-Quanten-Schlüsselaustausch, kein separates Projekt.

Beobachten:

7. Die Quanten-Hardware-Roadmaps von IBM und Google. Ein Sprung über die Meilensteine im NIST-Zeitplan oben hinaus würde Fristen nach vorn verschieben, statt sie lediglich zu bestätigen.
8. NIST-Leitlinien zu hybriden und reinen Post-Quanten-Modi, während Implementierungen von FIPS 203, 204 und 205 in gängigen TLS- und SSH-Bibliotheken reifen.

Nichts davon erfordert den Austausch eines bestehenden Passwortmanagers. Wenn er bereits einen AES-256/RSA-2048-Stack wie den oben beschriebenen veröffentlicht, tut die Plattform ihren Teil; die Inventararbeit oben ist Ihre.

Fazit

Quantencomputer kommen nicht für Ihren Passwort-Hash. Sie kommen für den RSA- und ECC-Schlüsselaustausch, der ihn transportiert, und NIST hat die Daten bereits in den Kalender geschrieben: 2030 für die Abkündigung, 2035 für das Verbot. Das 3-Schichten-Audit der Quantenexposition verwandelt dieses abstrakte Risiko in drei konkrete Prüfungen, die ein Team in diesem Quartal durchführen kann – eine davon lässt sich wahrscheinlich noch an diesem Nachmittag abschließen.

Beginnen Sie mit Schicht 2. Ziehen Sie die Liste aller Stellen, an denen RSA, ECDH oder ECDSA in Ihrer Umgebung einen Handshake abwickeln, und Sie wissen innerhalb eines Tages, mit welchen Anbietern ein Migrationsgespräch nötig ist und welche eines bereits begonnen haben.

Wenn Ihr Team dieses Inventar aufbaut, gibt Passwork Ihnen einen dokumentierten AES-256/RSA-2048-Tresor mit exportierbaren Audit-Logs, die direkt einfließen. Kostenlose Testversion starten

Häufig gestellte Fragen

Was ist Zero-Knowledge-Verschlüsselung? Funktionsweise in 5 Minuten

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server nie Ihre Entschlüsselungsschlüssel hält, nur Chiffrat. Erfahren Sie, wie die Schlüsselkette funktioniert, wovor sie schützt, wovor nicht und wie sich die Behauptung eines Anbieters überprüfen lässt.

PassworkPasswork Team

Zugriffsverwaltung für KMU: Die erste Cybersicherheitsschicht

Zugriffsverwaltung gehört ganz oben auf die Cybersicherheits-Checkliste eines KMU. Erfahren Sie, wie sich Identität, Authentifizierung, Autorisierung und Entzug als System einrichten lassen, das im Alltag hält.

PassworkPasswork Team

Was ist PKI? Public-Key-Infrastruktur erklärt für 2026

Zertifikate laufen bis 2029 alle 47 Tage ab. Hier steht, was PKI tatsächlich ist, wie sie funktioniert und welche menschlichen Zugangsdaten Ihre CA am Laufen halten, die PKI selbst nicht schützt.

PassworkPasswork Team

La computación cuántica no va a romper por fuerza bruta una contraseña de 16 caracteres bien protegida con hash en un futuro próximo. El algoritmo de Grover solo reduce a la mitad el exponente de una búsqueda de hash, no el problema completo. Lo que sí rompe una máquina cuántica lo bastante grande es el intercambio de claves RSA y de curva elíptica que transporta esa contraseña hasta el servidor, y NIST ya ha fijado 2030 como plazo para sustituirlo.

Dos problemas distintos se condensan en un mismo titular: «la computación cuántica romperá sus contraseñas». Esta guía los mantiene separados y después ofrece a los equipos de TI y de seguridad un método para comprobar cuál de ellos se aplica realmente a su propia infraestructura de contraseñas y qué partes de esa infraestructura pueden esperar.

Los dos algoritmos cuánticos que importan (Shor frente a Grover)

Dos algoritmos cuánticos importan para la seguridad de las contraseñas, y hacen trabajos distintos. El algoritmo de Shor ofrece una aceleración exponencial frente a las matemáticas que sustentan RSA y la criptografía de curva elíptica, lo que rompe el intercambio de claves en cuanto exista una máquina cuántica lo bastante grande. El algoritmo de Grover ofrece solo una aceleración cuadrática frente a la búsqueda simétrica, y reduce la fuerza efectiva a la mitad en lugar de a cero.

La diferencia entre exponencial y cuadrática lo explica todo. Una aceleración cuadrática frente a un hash de 128 bits deja todavía unas 2⁶⁴ operaciones por probar, una cifra computacionalmente enorme hoy, y una función memory-hard (de uso intensivo de memoria) como Argon2id multiplica aún más ese coste. Una aceleración exponencial frente a RSA-2048 no deja un margen comparable.

Para conocer en profundidad la mecánica de los esquemas basados en retículos y de otros esquemas poscuánticos, consulte nuestro artículo explicativo sobre qué es la criptografía cuántica; esta guía se centra en lo que cambia específicamente para la infraestructura de contraseñas.

Por qué el hash de su contraseña no es el objetivo real

Romper una contraseña bien protegida con hash sigue siendo caro incluso con el algoritmo de Grover, porque el coste de la función de hash se aplica a cada uno de los intentos que hace una máquina cuántica. Argon2id y bcrypt son memory-hard por diseño, así que reducir el exponente a la mitad deja al atacante pagando un precio alto por intento.

Tome una contraseña aleatoria de 16 caracteres extraída del conjunto imprimible completo de 95 caracteres: unos 105 bits de entropía antes de que el hash intervenga. La aceleración cuadrática de Grover reduce aproximadamente a la mitad ese exponente y sitúa al atacante en torno a 2⁵² operaciones efectivas. Esa cifra queda fuera del alcance de cualquier máquina cuántica que se plantee hoy en serio, y el coste memory-hard de Argon2id multiplica además el precio de cada intento.

No todas las funciones de hash ofrecen esa protección por igual. PBKDF2 está limitada por CPU y resulta más barata de paralelizar en hardware específico. Argon2id y bcrypt obligan al atacante a pagar en memoria además de en tiempo, lo que importa más a medida que mejora el descifrado con GPU y ASIC, cuántico o no. El salting sigue siendo obligatorio con cualquier algoritmo: impide los ataques con tablas rainbow precomputadas y obliga a que cada intento se ejecute individualmente contra un único hash.

Nuestra guía sobre hashing y salting de contraseñas explica con más detalle la mecánica de cada función, incluido por qué un mínimo de 16 caracteres se ha convertido en el suelo práctico.

La capa que de verdad se rompe: El intercambio de claves

El intercambio de claves RSA-2048 y ECDH es el verdadero objetivo. El algoritmo de Shor hace tratables la factorización en la que se basa RSA y el cálculo de los logaritmos discretos en los que se basa ECC, lo que rompe los handshakes de TLS, las sesiones SSH, los túneles VPN y cualquier envoltura de clave privada construida sobre las mismas primitivas.

La criptografía de clave pública lleva ese riesgo a la infraestructura cotidiana en más lugares de los que controla la mayoría de los equipos:

• Handshakes de TLS 1.3: intercambio de claves RSA o ECDHE, certificados ECDSA
• Intercambio de claves de host y de usuario en SSH
• Negociación de túneles VPN
• Envoltura de claves privadas dentro de la jerarquía de claves de un gestor de contraseñas
• Certificados de firma de código y de firma de documentos

Las matemáticas que hay detrás de ese riesgo no son hipotéticas. Google Quantum AI publicó en mayo de 2025 un preprint que muestra que RSA de 2048 bits podría factorizarse teóricamente con una máquina cuántica con corrección de errores lo bastante grande. La máquina todavía no existe. Las matemáticas que la romperían, sí.

Un gestor de contraseñas forma parte de esa misma lista. Compartir una bóveda con un nuevo miembro del equipo, sincronizar un registro entre dispositivos o desenvolver una clave privada al iniciar sesión dependen todos de una operación asimétrica en algún punto de la cadena. Auditar el stack criptográfico del gestor de contraseñas pertenece al mismo inventario que los endpoints TLS y los concentradores VPN.

Harvest now, decrypt later: La amenaza que ya existe hoy

Harvest now, decrypt later describe a un atacante que registra hoy tráfico cifrado y lo descifra en cuanto exista una máquina cuántica capaz de hacerlo. Reformula «lo cuántico está a diez años» como «la recolección ya ha empezado», lo que importa para cualquier dato cuya confidencialidad deba sobrevivir una década o más.

Thales encuestó en su 2026 Quantum & AI Threat Report a 3120 profesionales de seguridad y de TI de 20 países y concluyó que harvest now, decrypt later es su principal preocupación cuántica, citada por el 61 % de los encuestados, por delante de la obsolescencia de algoritmos o de los plazos de cumplimiento. Los adversarios con la paciencia de esperar años para obtener un beneficio, normalmente actores estatales, son los que llevan a cabo esa recolección hoy.

La exposición se concentra en los datos que deben seguir siendo confidenciales durante años: historiales médicos, escritos judiciales, propiedad intelectual, comunicaciones gubernamentales. Una clave de sesión TLS que se descarta en el momento en que se cierra la conexión es un objetivo pobre. Un archivo envuelto con RSA de 2024 que en 2034 siga en una cinta de copia de seguridad es exactamente lo que busca esta amenaza, igual que una exportación cifrada de una bóveda guardada en una copia de seguridad retirada que nadie se acordó de purgar.

Qué decidió realmente NIST y los plazos que le obligan

NIST finalizó sus tres primeras normas de criptografía poscuántica en agosto de 2024: FIPS 203 (ML-KEM) para el intercambio de claves, FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) para las firmas digitales. NIST IR 8547 puso después en marcha el reloj del cumplimiento: declara obsoletos RSA, ECDSA y EdDSA después de 2030 y los prohíbe después de 2035.

La criptografía simétrica con seguridad de 128 bits o más no se ve afectada por nada de esto. AES-256 no necesita ningún cambio de algoritmo. Los plazos apuntan específicamente a la capa asimétrica: RSA, ECDSA y EdDSA, sustituidos por ML-KEM y ML-DSA. El Commercial National Security Algorithm Suite 2.0 refleja este mismo calendario para los sistemas de seguridad nacional de EE. UU., una señal de la seriedad con la que se espera que los equipos de compras se lo tomen.

NIST IR 8547 plantea la migración poscuántica como un esfuerzo de ingeniería de varios años, del orden de una década para integrarla en productos e infraestructura, que es el verdadero argumento para empezar un inventario ahora en lugar de esperar a 2029. La hoja de ruta cuántica pública de IBM apunta a un sistema de más de 100 000 cúbits para 2033. Es el objetivo declarado por el propio proveedor, no una proyección independiente, pero pone una fecha aproximada a partir de la cual «lo bastante grande» deja de ser teórico.

Incorporar ya la agilidad criptográfica a las compras, es decir, la capacidad de cambiar un algoritmo sin rediseñar un producto, es lo que convierte esto en una migración planificada en lugar de una carrera a contrarreloj.

La auditoría de exposición cuántica en 3 capas

Realizar esta auditoría lleva una tarde, no un proyecto de consultoría. Clasifique la infraestructura de contraseñas en tres capas, y cada una recibe su propio veredicto: seguro, vigilar o actuar ahora.

La capa 1 es la que más preocupa a los equipos y la que menos debería preocuparles. Si los hashes de inicio de sesión y de la contraseña maestra del gestor de contraseñas ya usan Argon2id, PBKDF2 o bcrypt con un factor de trabajo razonable, el algoritmo de Grover no cambia su cálculo de riesgo. La única carencia real que merece perseguirse: un sistema heredado que todavía ejecute MD5 o SHA-1 sin sal ya estaba roto antes de que lo cuántico entrara en la conversación.

La capa 2 es donde un administrador suele encontrar la carencia real: un concentrador VPN todavía anclado a RSA-2048, una PKI interna que emite certificados ECDSA sin plan de renovación, una API heredada que nunca pasó de TLS 1.2. Inventaríe todos los lugares donde RSA, ECDH o ECDSA realizan un intercambio de claves y empiece por lo que protege el tráfico de vida más larga.

La capa 3 trata de lo que ya se ha recolectado, no de lo que se cifra mañana. Pregúntese qué datos protege hoy la organización que todavía necesitarán confidencialidad en 2035: retenciones legales, tablas de capitalización, código fuente, cualquier cosa sujeta a un NDA de varios años. Después compruebe si esa confidencialidad depende de un intercambio de claves asimétrico realizado años atrás.

Realice la auditoría una vez y luego incorpórela a la periodicidad que el equipo ya use para el inventario criptográfico. Una vez al año es razonable. Con más frecuencia si este año va a emitir una nueva PKI o renegociar un contrato de VPN.

Cómo leer la documentación criptográfica de un gestor de contraseñas

La documentación criptográfica de un gestor de contraseñas debería indicar exactamente qué protege la bóveda en cada capa. Una afirmación vaga de «cifrado de grado militar» no cuenta. Busque algoritmos con nombre, tamaños de clave declarados, una función de derivación de claves concreta y una posición pública sobre la migración poscuántica.

Qué publica un proveedor consciente de lo cuántico:

• El cifrado simétrico exacto y el tamaño de clave que protegen los datos de la bóveda (AES-128 y AES-256 no ofrecen el mismo margen, así que «AES» por sí solo no basta)
• El algoritmo asimétrico exacto que se usa para el intercambio de claves y la envoltura de claves privadas
• La función de derivación de claves y el número de iteraciones que convierten una contraseña maestra en una clave de cifrado
• Si el cifrado se realiza en el lado del cliente, el modelo de conocimiento cero o solo en reposo en el servidor

La documentación de Passwork es un ejemplo razonable de lo que significa esa transparencia en la práctica. Su cifrado del lado del cliente aplica AES-256 a los datos de bóvedas y registros, con una capa AES-256 independiente que protege la base de datos en reposo. Una contraseña maestra deriva una clave maestra de 512 bits mediante PBKDF2 (HMAC-SHA-256), que desenvuelve una clave privada RSA-2048 que, a su vez, desenvuelve las claves de cada bóveda y de cada registro, una jerarquía documentada en la visión general de la criptografía.

Pase ese stack por la auditoría de 3 capas y la respuesta honesta es sencilla. La capa de datos AES-256 sigue siendo resistente a la computación cuántica con los tamaños de clave actuales; la capa de intercambio de claves RSA-2048 es el componente que hay que vigilar a medida que maduren las normas poscuánticas en todo el sector. Esa es la misma respuesta que debería darle hoy cualquier proveedor que envuelva claves con RSA: una capa AES-256 documentada que no necesita cambiar y una capa asimétrica con una vía de migración reconocida, no la afirmación de que todo es ya a prueba de lo cuántico. Nuestro artículo explicativo sobre AES-256 explica por qué el margen del tamaño de clave importa por sí solo.

Si su equipo está empezando su propio inventario criptográfico, Passwork publica exactamente este tipo de stack AES-256/RSA-2048 documentado, con registros de auditoría exportables para incorporarlos directamente a la revisión de la capa 2. Iniciar una prueba gratuita

Qué hacer hoy (y qué puede esperar)

Empiece por lo que protege hoy el intercambio de claves de TLS, SSH y VPN, ya que es la capa con un plazo real en 2030. El despliegue de passkeys, las pruebas de intercambio de claves híbrido y un inventario criptográfico documentado pueden avanzar en paralelo. Volver a generar claves en los despliegues de AES-256 o preocuparse por la fuerza del hash de contraseñas puede esperar.

Hacer ahora:

1. Inventaríe todos los lugares donde RSA, ECDH o ECDSA realizan un intercambio de claves: endpoints TLS, hosts SSH, concentradores VPN, PKI interna.
2. Confirme que su gestor de contraseñas y su proveedor de identidad publican su stack criptográfico real en lugar de una afirmación vaga de «cifrado de nivel bancario». Si un proveedor no quiere indicar sus algoritmos y tamaños de clave cuando se le pregunta, considere que esa es la respuesta.
3. Active la MFA en todos los lugares donde aún no sea obligatoria. No afecta directamente a la cuestión cuántica, pero cierra exposición mientras avanza la migración.

Planificar este año:

4. Lleve el intercambio de claves híbrido (clásico más ML-KEM) a las conversaciones sobre la hoja de ruta de sus proveedores, especialmente para todo lo que tenga un plazo en 2030.
5. Priorice el despliegue de passkeys para la autenticación de cara al usuario. La agilidad de algoritmos de FIDO2 implica que la vía de migración ya existe, aunque las passkeys actuales sigan usando ECDSA, y el propio despliegue reduce la parte de la infraestructura que todavía depende de un hash de contraseña.
6. Cierre los endpoints que sigan en TLS 1.2. Actualizar a TLS 1.3 es un requisito previo para el intercambio de claves poscuántico, no un proyecto aparte.

Vigilar:

7. Las hojas de ruta de hardware cuántico de IBM y Google. Un salto que supere los hitos del calendario de NIST anterior adelantaría los plazos en lugar de limitarse a confirmarlos.
8. Las directrices de NIST sobre los modos híbridos y puramente poscuánticos a medida que maduren las implementaciones de FIPS 203, 204 y 205 en las principales bibliotecas de TLS y SSH.

Nada de esto exige sustituir un gestor de contraseñas ya en uso. Si ya publica un stack AES-256/RSA-2048 como el anterior, la plataforma cumple su parte; el trabajo de inventario descrito arriba le corresponde a usted.

Conclusión

La computación cuántica no va a por el hash de su contraseña. Va a por el intercambio de claves RSA y ECC que lo transporta, y NIST ya ha puesto fechas en el calendario: 2030 para declararlos obsoletos y 2035 para prohibirlos. La auditoría de exposición cuántica en 3 capas convierte ese riesgo abstracto en tres comprobaciones concretas que un equipo puede realizar este trimestre, una de las cuales probablemente pueda cerrarse esta misma tarde.

Empiece por la capa 2. Saque la lista de todos los lugares de su entorno donde RSA, ECDH o ECDSA gestionan un handshake y sabrá en un día qué proveedores necesitan una conversación sobre migración y cuáles ya la tienen iniciada.

Si su equipo está elaborando ese inventario, Passwork le ofrece una bóveda AES-256/RSA-2048 documentada con registros de auditoría exportables para incorporarlos directamente a él. Iniciar una prueba gratuita

Preguntas frecuentes

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

El cifrado de conocimiento cero significa que el servidor nunca guarda sus claves de descifrado, solo el 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

Gestión de accesos para pymes: La primera capa de ciberseguridad

La gestión de accesos debe encabezar la lista de verificación de ciberseguridad de una pyme. Descubra cómo configurar la identidad, la autenticación, la autorización y la revocación como un sistema que aguante en el día a día.

PassworkPasswork Team

¿Qué es la PKI? La infraestructura de clave pública explicada para 2026

Para 2029, los certificados caducarán cada 47 días. Esto es lo que es realmente la PKI, cómo funciona y las credenciales humanas que mantienen en marcha la CA, algo que la propia PKI no protege.

PassworkPasswork Team

Quantum computers will not brute-force a properly hashed 16-character password anytime soon. Grover's algorithm only halves the exponent of a hash search, not the whole problem. What a large enough quantum computer does break is the RSA and elliptic-curve key exchange that carries that password to your server, and NIST has already put a 2030 deadline on replacing it.

Two separate problems get collapsed into one headline: "quantum computers will break your passwords." This guide keeps them apart, then hands IT and security teams a workflow for checking which one actually applies to their own password estate, and which parts of that estate can wait.

The two quantum algorithms that matter (Shor vs Grover)

Two quantum algorithms matter for password security, and they do different jobs. Shor's algorithm delivers an exponential speedup against the math behind RSA and elliptic-curve cryptography, which breaks key exchange once a large enough quantum computer exists. Grover's algorithm delivers only a quadratic speedup against symmetric search, cutting effective strength in half rather than to zero.

The gap between exponential and quadratic is the whole story. A quadratic speedup against a 128-bit hash still leaves roughly 2⁶⁴ operations to try, which is computationally enormous today, and a memory-hard function like Argon2id multiplies that cost further. An exponential speedup against RSA-2048 doesn't leave a comparable margin.

For the deeper mechanics of lattice-based and other post-quantum schemes, see our explainer on what is quantum cryptography; this guide stays focused on what changes for password infrastructure specifically.

Why your password hash is not the real target

A properly hashed password stays expensive to crack even under Grover's algorithm, because the hashing function's cost applies to every single guess a quantum computer makes. Argon2id and bcrypt are memory-hard by design, so halving the exponent still leaves an attacker paying a steep price per attempt.

Take a 16-character random password drawn from the full 95-character printable set: roughly 105 bits of entropy before hashing touches it. Grover's quadratic speedup roughly halves that exponent, landing an attacker around 2⁵² effective operations. That number stays out of reach for any quantum computer under serious discussion today, and Argon2id's memory-hard cost multiplies the price of each guess on top of it.

Not every hashing function offers that protection equally. PBKDF2 is CPU-bound and cheaper to parallelize on custom hardware. Argon2id and bcrypt force an attacker to pay in memory as well as time, which matters more as GPU and ASIC cracking improves, quantum or not. Salting stays mandatory regardless of algorithm: it stops precomputed rainbow-table attacks and forces every guess to run individually against a single hash.

Our guide to password hashing and salting covers the mechanics of each function in more depth, including why a 16-character minimum has become the practical floor.

The layer that actually breaks: Key exchange

RSA-2048 and ECDH key exchange are the actual target here. Shor's algorithm makes factoring the math behind RSA and computing the discrete logs behind ECC tractable, which breaks TLS handshakes, SSH sessions, VPN tunnels, and any private-key wrap built on the same primitives.

Public-key cryptography carries that risk into everyday infrastructure in more places than most teams track:

• TLS 1.3 handshakes: RSA or ECDHE key exchange, ECDSA certificates
• SSH host and user key exchange
• VPN tunnel negotiation
• Private-key wrapping inside a password manager's key hierarchy
• Code-signing and document-signing certificates

The math behind that risk isn't hypothetical. Google Quantum AI published a May 2025 preprint showing that 2048-bit RSA could theoretically be factored by a sufficiently large error-corrected quantum computer. The machine doesn't exist yet. The mathematics that would break it does.

A password manager sits inside this same list. Sharing a vault with a new team member, syncing a record between devices, or unwrapping a private key at login all depend on an asymmetric operation somewhere in the chain. Auditing your password manager's crypto stack belongs in the same inventory as your TLS endpoints and VPN concentrators.

Harvest now, decrypt later: The threat that exists today

Harvest now, decrypt later describes an attacker recording encrypted traffic today and decrypting it once a capable quantum computer exists. It reframes "quantum is ten years away" into "the collection already started," which matters for any data whose confidentiality needs to survive a decade or more.

Thales's 2026 Quantum & AI Threat Report surveyed 3,120 security and IT professionals across 20 countries and found harvest-now-decrypt-later is their top quantum concern, cited by 61% of respondents, ahead of algorithm deprecation or compliance deadlines. Adversaries with the patience to wait years for a payoff, typically nation-state actors, are the ones running this collection today.

The exposure concentrates in data that needs to stay confidential for years: medical records, legal filings, intellectual property, government communications. A TLS session key discarded the moment a connection closes is a poor target. An RSA-wrapped archive from 2024 still sitting on a backup tape in 2034 is exactly what this threat targets, and so is an encrypted vault export sitting in a decommissioned backup that nobody remembered to purge.

What NIST actually decided, and the deadlines that bind you

NIST finalized its first three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM) for key exchange, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. NIST IR 8547 then set the compliance clock, deprecating RSA, ECDSA, and EdDSA after 2030 and disallowing them after 2035.

Symmetric cryptography at 128-bit security or higher is unaffected by any of this. AES-256 needs no algorithm change. The deadlines target the asymmetric layer specifically: RSA, ECDSA, and EdDSA, replaced by ML-KEM and ML-DSA. The Commercial National Security Algorithm Suite 2.0 mirrors this timeline for U.S. national security systems, one signal of how seriously procurement teams are meant to take it.

NIST IR 8547 frames post-quantum migration as a multi-year engineering effort, on the order of a decade to integrate across products and infrastructure, which is the real argument for starting an inventory now rather than waiting until 2029. IBM's public quantum roadmap targets a system of 100,000-plus qubits by 2033. That's the vendor's own stated goal, not an independent projection, but it puts a rough date on when "large enough" stops being theoretical.

Building crypto agility into procurement now, meaning the ability to swap an algorithm without rearchitecting a product, is what turns this from a scramble into a scheduled migration.

The 3-Layer Quantum Exposure Audit

Running this audit takes an afternoon, not a consulting engagement. Sort your password estate into three layers, and each one gets its own verdict: safe, watch, or act now.

Layer 1 is the one teams worry about most and need to worry about least. If your login and password-manager master-password hashes already use Argon2id, PBKDF2 or bcrypt with a reasonable work factor, Grover's algorithm doesn't change your risk calculus. The one real gap worth chasing: a legacy system still running MD5 or unsalted SHA-1 was already broken before quantum entered the conversation.

Layer 2 is where an admin usually finds the actual gap: a VPN concentrator still pinned to RSA-2048, an internal PKI issuing ECDSA certificates with no renewal plan, a legacy API that never moved past TLS 1.2. Inventory every place RSA, ECDH, or ECDSA performs a key exchange, and start with whatever protects your longest-lived traffic.

Layer 3 is about what's already been collected, not what gets encrypted tomorrow. Ask what data your organization protects today that still needs confidentiality in 2035: legal holds, cap tables, source code, anything under a multi-year NDA. Then check whether that confidentiality depends on an asymmetric key exchange performed years ago.

Run the audit once, then fold it into whatever cadence your team already uses for a crypto inventory. Annually is reasonable. Faster if you're issuing new PKI or renegotiating a VPN contract this year.

How to read a password manager's crypto documentation

A password manager's crypto documentation should name exactly what protects your vault at each layer. A vague "military-grade encryption" claim doesn't count. Look for named algorithms, stated key sizes, a named key-derivation function, and a public position on post-quantum migration.

What a quantum-aware vendor publishes:

• The exact symmetric cipher and key size protecting vault data (AES-128 and AES-256 are not the same margin, so "AES" alone isn't enough)
• The exact asymmetric algorithm used for key exchange and private-key wrapping
• The key derivation function and iteration count turning a master password into an encryption key
• Whether encryption happens client-side, the zero-knowledge model, or only at rest on the server

Passwork's own documentation is a reasonable example of what that transparency looks like in practice. Its client-side encryption applies AES-256 to vault and record data, with a separate AES-256 layer protecting the database at rest. A master password derives a 512-bit master key through PBKDF2 (HMAC-SHA-256), which unwraps an RSA-2048 private key that in turn unwraps per-vault and per-record keys, a hierarchy documented in the cryptography overview.

Run that stack through the 3-Layer Audit and the honest answer is straightforward. The AES-256 data layer stays quantum-resistant at current key sizes; the RSA-2048 key-exchange layer is the component to watch as post-quantum standards mature across the industry. That's the same answer any vendor wrapping keys with RSA should be giving you today: a documented AES-256 layer that doesn't need to change, and an asymmetric layer with an acknowledged migration path, not a claim that everything is already quantum-proof. Our AES-256 explainer covers why the key size margin matters on its own.

If your team is starting its own crypto inventory, Passwork publishes exactly this kind of documented AES-256/RSA-2048 stack, with exportable audit logs to feed straight into your Layer 2 review. Start a free trial

What to do today (and what can wait)

Start with what protects TLS, SSH, and VPN key exchange today, since that's the layer with an actual 2030 deadline. Passkey rollout, hybrid key exchange testing, and a documented crypto inventory can run in parallel. Re-keying AES-256 deployments or worrying about password hash strength can wait.

Do now:

1. Inventory every place RSA, ECDH, or ECDSA performs key exchange: TLS endpoints, SSH hosts, VPN concentrators, internal PKI.
2. Confirm your password manager and identity provider publish their actual crypto stack instead of a vague "bank-level encryption" claim. If a vendor won't name its algorithms and key sizes on request, treat that as the answer.
3. Turn on MFA everywhere it isn't already mandatory. It doesn't touch the quantum question directly, but it closes exposure while migration runs.

Plan this year:

4. Get hybrid key exchange (classical plus ML-KEM) onto your vendor roadmap conversations, especially for anything facing a 2030 deadline.
5. Prioritize passkey rollout for user-facing authentication. FIDO2's algorithm agility means the migration path already exists, even though today's passkeys still use ECDSA, and rollout itself reduces how much of your estate still depends on a password hash at all.
6. Close out any lingering TLS 1.2 endpoints. Update TLS 1.3 is a prerequisite for post-quantum key exchange, not a separate project.

Watch:

7. IBM's and Google's quantum hardware roadmaps. A jump past the milestones in the NIST timeline above would move deadlines up rather than simply confirm them.
8. NIST guidance on hybrid and pure post-quantum modes as FIPS 203, 204, and 205 implementations mature in mainstream TLS and SSH libraries.

None of this requires replacing an existing password manager. If it already publishes an AES-256/RSA-2048 stack like the one above, the platform is doing its part; the inventory work above is yours.

Conclusion

Quantum computers are not coming for your password hash. They're coming for the RSA and ECC key exchange that carries it, and NIST has already put dates on the calendar: 2030 to deprecate, 2035 to disallow. The 3-Layer Quantum Exposure Audit turns that abstract risk into three concrete checks a team can run this quarter, one of which is probably closeable this afternoon.

Start with Layer 2. Pull the list of everywhere RSA, ECDH, or ECDSA handles a handshake in your environment, and you'll know within a day which vendors need a migration conversation and which ones already have one started.

If your team is building that inventory, Passwork gives you a documented AES-256/RSA-2048 vault with exportable audit logs to feed straight into it. Start a free trial

Frequently asked questions

What is zero-knowledge encryption? How it works in 5 minutes

Zero-knowledge encryption means the server never holds your decryption keys, only ciphertext. Learn how the key chain works, what it protects against, what it doesn’t, and how to verify a vendor’s claim.

PassworkPasswork Team

Access management for SMBs: The first cybersecurity layer

Access management belongs at the top of your SMB cybersecurity checklist. Learn how to set up identity, authentication, authorization, and revocation as a system that holds up day to day.

PassworkPasswork Team

What is PKI? Public key infrastructure explained for 2026

Certificates now expire every 47 days by 2029. Here is what PKI actually is, how it works, and the human credentials that keep your CA running, which PKI itself does not protect.

PassworkPasswork Team

Os algoritmos simétricos cifram e decifram dados com uma única chave partilhada. É essa conceção de chave única que os torna suficientemente rápidos para proteger uma base de dados em tempo real e suficientemente duradouros para que as orientações pós-quânticas da NSA não exijam qualquer alteração de algoritmo para continuar a confiar neles. O que falha à escala empresarial não é a matemática subjacente: é fazer chegar essa chave a todos os que dela precisam e retirá-la de forma limpa a todos os que já não precisam.

Esse compromisso, velocidade e simplicidade em troca da distribuição de chaves, resume toda a criptografia simétrica. Tudo o resto (cifras de blocos versus cifras de fluxo, AES contra ChaCha20, o que muda quando a computação quântica se tornar real) são pormenores que assentam nessa base.

Pontos principais

• A cifragem simétrica utiliza uma única chave para cifrar e decifrar, razão pela qual é suficientemente rápida para grandes volumes de dados e tráfego em tempo real.
• Os seus dois pontos fortes reais são a velocidade bruta e a durabilidade face à computação quântica. O AES-256 não precisa de qualquer alteração algorítmica para se manter seguro perante um adversário quântico.
• As suas duas limitações reais são o problema da distribuição de chaves e a ausência de não repúdio, uma vez que ambas as partes detêm uma chave idêntica.
• Segundo as orientações CNSA 2.0 da NSA, o AES-256 mantém-se tal como está. A migração obrigatória de 2027-2035 visa o RSA e a ECC, e não as cifras simétricas.
• As empresas resolvem o problema da distribuição com cifragem híbrida e hierarquias de chaves estruturadas, e não abandonando os algoritmos simétricos.

O que é a cifragem simétrica?

A cifragem simétrica utiliza uma chave secreta para transformar dados em texto cifrado e para os repor em texto em claro. O remetente e cada destinatário autorizado detêm uma cópia idêntica dessa chave. Quem a tem consegue ler os dados. Quem não a tem não consegue, independentemente da quantidade de texto cifrado que intercete.

Os algoritmos simétricos dividem-se em duas famílias. Uma cifra de blocos, como o AES, cifra os dados em blocos de tamanho fixo (128 bits de cada vez, no caso do AES), aplicando preenchimento ou encadeando blocos para tudo o que for maior. Uma cifra de fluxo, como o ChaCha20 ou o já retirado RC4, cifra um fluxo contínuo de dados um bit ou um byte de cada vez, o que se adequa melhor a contextos de baixa latência ou com recursos limitados do que preencher dados em blocos.

É o comprimento da chave que define a margem de segurança real. O AES admite chaves de 128, 192 e 256 bits, e a de 256 bits tornou-se a predefinição prática para tudo o que é sensível, uma vez que a diferença de custo em desempenho é pequena e a margem de segurança é maior.

A cifragem assimétrica resolve o problema da partilha de chaves de outra forma: uma chave pública cifra, uma chave privada matematicamente associada decifra, e as duas nunca precisam de se encontrar no mesmo lugar. Os algoritmos simétricos dispensam totalmente essa matemática. O custo é que ambas as partes precisam do mesmo segredo antes de poderem comunicar, e é aí que reside o verdadeiro compromisso.

As vantagens dos algoritmos simétricos

Velocidade e eficiência

Para o mesmo volume de dados, os algoritmos simétricos são várias ordens de grandeza mais rápidos do que os assimétricos. O AES-256-GCM consegue cifrar uma base de dados completa, um volume de disco ou uma sessão TLS ativa sem a sobrecarga computacional que a matemática de chave pública implica a essa escala. É por isso que todos os principais protocolos utilizam cifras simétricas para a transferência de dados propriamente dita e reservam a criptografia assimétrica para o handshake. Essa diferença explica também porque o TLS 1.3 executa uma troca assimétrica exatamente uma vez por sessão e entrega depois tudo o resto ao AES ou ao ChaCha20.

Concebidos para grandes volumes de dados

Cifrar gigabytes de registos, ficheiros de log ou cópias de segurança com um algoritmo assimétrico torna-se impraticável muito antes de se tornar apenas lento. As cifras simétricas escalam de forma linear com o volume de dados e, em hardware moderno, funcionam a uma velocidade próxima da do barramento de memória. É esta propriedade que torna viáveis em produção ferramentas de cifragem integral de disco como o BitLocker e o LUKS, bem como a cifragem por registo dentro das aplicações, em vez de as relegar para uma tarefa em lote que alguém executa durante a noite.

Simples de implementar e auditar

Uma chave, um algoritmo, nenhum par de chaves para gerar, trocar ou validar. Menos componentes móveis significam menos pontos onde uma implementação pode correr mal, e isso explica em grande parte porque o AES resistiu a mais de duas décadas de criptanálise pública como norma do NIST sem uma quebra prática. As implementações do AES são também amplamente validadas no âmbito do Cryptographic Algorithm Validation Program do NIST, pelo que uma equipa que o adote não depende de uma biblioteca desenvolvida internamente ou não auditada.

Durabilidade face à computação quântica

Os algoritmos simétricos são a única parte da pilha criptográfica que não precisa de mudar para a era pós-quântica. O algoritmo de Grover dá a um computador quântico uma aceleração quadrática teórica na pesquisa de chaves por força bruta, mas uma aceleração quadrática contra um espaço de chaves de 2²⁵⁶ apenas reduz para metade a resistência quântica do AES-256, deixando uma margem efetiva de 128 bits, cuja quebra continua computacionalmente inviável com qualquer hardware previsto num roteiro realista. A secção sobre computação quântica, mais abaixo, explica o que a CNSA 2.0 diz realmente sobre este ponto e porque a pressão de migração recai inteiramente sobre os algoritmos assimétricos.

As desvantagens dos algoritmos simétricos

O problema da distribuição de chaves

Todos os esquemas simétricos esbarram no mesmo obstáculo: como fazer chegar a chave secreta à outra parte sem que alguém à escuta também a obtenha? Enviar a chave pelo mesmo canal que os dados anula o propósito, enviá-la em separado não escala para lá de um punhado de pessoas, e uma chave partilhada por chat ou e-mail fica em texto em claro na caixa de entrada de alguém indefinidamente. Este problema, por si só, é a razão pela qual a cifragem híbrida existe, e é abordado em pormenor mais adiante neste artigo.

A escalabilidade degrada-se rapidamente

Numa rede em que cada par de utilizadores precisa de uma chave partilhada única, o número de chaves cresce segundo n(n-1)/2. Dez utilizadores precisam de 45 chaves distintas. Cem utilizadores precisam de 4950. Uma organização de engenharia de média dimensão que começa com 20 pessoas a partilhar credenciais de bases de dados e cresce para 200 passa de 190 chaves por par para quase 20 000, sem que ninguém tenha decidido deliberadamente tornar a gestão de chaves mais difícil. Gerir, rodar e revogar manualmente tantas chaves por par exige uma gestão de chaves automatizada ou, de forma mais prática, uma arquitetura partilhada em que os utilizadores não precisem, cada um, de uma chave direta por par.

A solução alternativa habitual, uma única chave partilhada por equipa ou departamento em vez de uma por par, troca o problema de escalabilidade por um problema de raio de impacto ainda pior: uma única chave divulgada expõe todas as credenciais que o grupo partilha, e rodá-la implica mexer em tudo ao mesmo tempo, em vez de numa única relação.

Se a equipa já anda a gerir palavras-passe partilhadas de bases de dados e chaves de API para um número crescente de pessoas, é exatamente este o problema com que se depara. Experimentar o Passwork gratuitamente e ver o acesso ao nível do cofre substituir a folha de cálculo.

Ausência de não repúdio

Como o remetente e o destinatário detêm uma chave idêntica, nada no texto cifrado prova quem o criou de facto. Qualquer uma das partes poderia ter gerado a mesma mensagem com a mesma chave, pelo que a cifragem simétrica, por si só, não consegue fornecer o tipo de prova de origem que uma assinatura digital fornece. Isto importa mais do que parece: se uma credencial partilhada de base de dados for divulgada e duas pessoas tiverem tido acesso à chave que a cifrou, a cifragem simétrica, por si só, não oferece qualquer forma criptográfica de determinar qual delas a utilizou. Os sistemas que precisam de não repúdio acrescentam assinaturas assimétricas por cima ou recorrem ao registo de acessos para determinar quem fez o quê e quando.

AES vs. ChaCha20: Qual utilizar na prática?

Utilize o AES-256-GCM quando o hardware dispuser de aceleração AES-NI, o que abrange a maioria das CPU modernas de servidores e computadores de secretária. Utilize o ChaCha20-Poly1305 quando não dispuser, em chips móveis, dispositivos embebidos ou ambientes exclusivamente de software, onde o AES funciona sem suporte de hardware. Esta é a regra prática do AES-NI, e resolve a escolha na esmagadora maioria das implementações.

Ambos são modos de cifragem autenticada, o que significa que detetam adulterações além de ocultarem o conteúdo, numa única passagem, sem precisarem de um passo de autenticação acrescentado à parte. Ambos estão aprovados para utilização no TLS 1.3, e o WireGuard, o protocolo VPN integrado no kernel do Linux, utiliza o ChaCha20-Poly1305 como a sua única cifra precisamente por essa independência do hardware.

O AES-NI não é novo nem raro: a Intel acrescentou-o às CPU de servidores e de computadores de secretária a partir da geração Westmere, em 2010, e a AMD seguiu-a pouco depois. Para a maioria das equipas, a questão prática é saber se a pilha de software utiliza efetivamente essa aceleração, em vez de recorrer a uma implementação lenta e sem aceleração. A lista de algoritmos legados deve ser posta de parte por completo: o DES e o 3DES estão descontinuados ao abrigo da NIST SP 800-131A Rev. 2, e o RC4 e o Blowfish têm fraquezas práticas conhecidas que os excluem de qualquer utilização com tráfego real em 2026.

Computação quântica e algoritmos simétricos: O que muda realmente

O algoritmo de Grover reduz para metade a margem de segurança efetiva do AES-256, para cerca de 128 bits de resistência quântica, o que continua a tornar computacionalmente inviável um ataque de força bruta com qualquer hardware quântico previsível. O algoritmo em si não precisa de mudar. Compare-se com o que o algoritmo de Grover faz a uma chave de 128 bits: reduz a margem efetiva para 64 bits, bem dentro do alcance da força bruta, e é essa a verdadeira razão pela qual as chaves de 256 bits são hoje o mínimo prático para tudo o que tenha uma vida longa, e não uma mera preferência conservadora.

A CNSA 2.0 impõe uma substituição definitiva do RSA e da ECC. Não toca no AES-256. As FAQ da Commercial National Security Algorithm Suite 2.0 publicadas pela NSA afirmam que os requisitos simétricos são «essencialmente os mesmos» que os da CNSA 1.0, desde que os tamanhos de chave se mantenham nos 256 bits. A migração obrigatória segue um calendário fixo: as novas aquisições de National Security Systems (sistemas de segurança nacional) têm de estar em conformidade com a CNSA 2.0 até 1 de janeiro de 2027, o equipamento não conforme é retirado até 31 de dezembro de 2030, a CNSA 2.0 torna-se obrigatória até 31 de dezembro de 2031 e a resistência quântica total está prevista para 2035. Todos estes prazos dizem respeito à substituição da troca de chaves e das assinaturas RSA e ECC pelo ML-KEM e pelo ML-DSA, as normas pós-quânticas que o NIST finalizou como FIPS 203 e FIPS 204 em agosto de 2024.

Existe, no entanto, um risco quântico real que afeta os dados protegidos por cifragem simétrica: harvest-now-decrypt-later (recolher agora, decifrar depois). Um atacante que grava hoje tráfego cifrado, apostando que um futuro computador quântico quebrará a troca de chaves assimétrica que o protegeu, está a visar o handshake RSA ou ECC, e não a chave de sessão AES em si. Uma chave de sessão TLS de curta duração, descartada no momento em que a ligação termina, é um alvo pobre para este tipo de recolha. A exposição real diz respeito a dados cuja confidencialidade a longo prazo ainda depende de uma troca de chaves assimétrica realizada há anos: registos governamentais, assinaturas digitais de longa duração ou propriedade intelectual cifrada com uma chave envolvida por RSA que nunca foi rodada para um esquema pós-quântico.

Nada disto altera as orientações específicas para as cifras simétricas. As organizações que planeiam uma migração pós-quântica devem concentrar esse esforço na substituição da troca de chaves e das assinaturas RSA e ECC, e não na renovação das chaves de implementações AES-256 que já cumprem o requisito de 256 bits.

Superar as desvantagens: Como as empresas gerem, na prática, as chaves simétricas

A resposta padrão do setor ao problema da distribuição de chaves é a cifragem híbrida, que já funciona por baixo de quase todas as ligações seguras do dia a dia. O TLS 1.3 utiliza uma troca de chaves assimétrica (normalmente ECDHE) para acordar um segredo partilhado através de uma rede não fiável sem nunca transmitir esse segredo diretamente, e passa depois para uma cifra simétrica, AES-256-GCM ou ChaCha20-Poly1305, para o tráfego da sessão propriamente dito. A criptografia assimétrica resolve uma vez, no início da ligação, o problema de «como acordar um segredo sem que ninguém o ouça»; a criptografia simétrica faz o trabalho pesado em tudo o que se segue, porque nessa altura ambas as partes já partilham a chave de que precisam.

Esse padrão resolve a distribuição para uma sessão pontual. Não resolve a gestão de chaves para dados em repouso nem para segredos empresariais de longa duração que sobrevivem a qualquer ligação individual, como credenciais guardadas num cofre durante meses ou anos e partilhadas por toda uma equipa. Isso exige controlos deliberados e contínuos:

• Rodar as chaves segundo um calendário definido e imediatamente após qualquer suspeita de comprometimento, e não de forma ad hoc, ao sabor de quem se lembrar de o fazer
• Separar funções para que nenhum administrador possa, sozinho, aceder a uma chave, exportá-la e utilizá-la, o que limita os danos que uma única conta comprometida pode causar
• Registar cada acesso e cada exportação de chaves e encaminhar esses registos para uma equipa de segurança que os reveja efetivamente com regularidade, e não para um repositório de retenção que ninguém abre
• Armazenar as chaves num módulo de segurança de hardware (HSM) ou num cofre equivalente baseado em hardware, e não em ficheiros de configuração, variáveis de ambiente ou numa folha de cálculo partilhada, nenhum dos quais foi concebido para manter um segredo em segredo
• Automatizar a rotação e a revogação, em vez de depender de alguém que se lembre de o fazer durante a saída de colaboradores, uma vez que é precisamente esse o passo que se salta quando o tempo aperta

Cada uma destas medidas é uma correção de processo aplicada sobre o algoritmo e, em conjunto, tratam a gestão de chaves como uma disciplina própria, com um responsável definido, e não como algo que acontece por omissão quando alguém se lembra.

Como o Passwork aplica isto: Uma hierarquia de chaves que isola cada registo

A arquitetura zero-knowledge do próprio Passwork é uma resposta concreta aos problemas de distribuição e de escalabilidade descritos acima. A cadeia do lado do cliente funciona assim:

• Uma palavra-passe mestra, nunca transmitida ao servidor, deriva uma chave mestra através do PBKDF2, com cerca de 300 000 iterações do lado do cliente
• Essa chave mestra decifra a chave privada RSA-2048 do utilizador, que por sua vez decifra as chaves de cada cofre a que o utilizador tem acesso
• Cada chave de cofre desbloqueia, por sua vez, a chave AES-256 individual de cada registo nele contido, e só essa chave decifra a palavra-passe ou o segredo propriamente dito

Todos os passos dessa cadeia acontecem no cliente. O servidor apenas armazena texto cifrado e chaves cifradas que não tem forma de ler por si só.

O objetivo de construir o sistema desta forma é o raio de impacto. Uma chave comprometida ou rodada afeta um registo ou um cofre, e não o conjunto de credenciais de toda a organização, porque não existe uma chave mestra única que desbloqueie tudo de uma vez, nem um equivalente ao problema das chaves por par n(n-1)/2 descrito anteriormente.

Alterar uma palavra-passe mestra apenas volta a envolver a chave privada do utilizador. Não exige voltar a cifrar todos os registos a que essa chave pode, em última instância, chegar, e é essa a diferença operacional entre uma rotação que demora segundos e outra que exige uma janela de manutenção. O Passwork executa também uma camada AES-256 independente do lado do servidor, sobre esta cadeia do lado do cliente, pelo que comprometer uma camada de cifragem não entrega a outra a um atacante, um padrão relacionado com a cifragem ponta a ponta dos sistemas de mensagens, mas distinto dela.

O acesso a uma credencial partilhada pode, ainda assim, ser revogado instantaneamente e registado, e é isso que transforma «quem consegue tecnicamente decifrar isto» em «quem continua realmente autorizado a fazê-lo». Os pormenores completos de implementação constam da documentação sobre a arquitetura criptográfica do Passwork.

Cifragem simétrica e requisitos de conformidade

A maioria dos referenciais que mencionam a cifragem descreve o que esta deve alcançar, e não que algoritmo utilizar, e confundir esta distinção conduz a alegações de conformidade que não resistem a uma auditoria.

O artigo 32.º, n.º 1, alínea a), do RGPD indica «a pseudonimização e a cifragem dos dados pessoais» como exemplo de medida técnica de segurança adequada, uma opção entre várias e não uma imposição de uma cifra específica. O artigo deixa a implementação, incluindo o algoritmo a utilizar, à avaliação de riscos da própria organização.

O requisito 3.5.1 da PCI DSS v4.0 exige que os dados armazenados dos titulares de cartões se tornem ilegíveis através de hashes unidirecionais, truncagem, tokens de índice ou criptografia forte com processos documentados de gestão de chaves, e conhecer a diferença entre hashing e cifragem é importante neste ponto, uma vez que apenas uma dessas quatro opções é reversível. O requisito não refere o AES nem especifica um comprimento mínimo de chave, pelo que tratar a PCI DSS como uma «obrigação de AES-256», alegação que aparece em bastantes artigos de blogues de segurança, exagera o que a norma realmente diz. Uma organização que consiga documentar o seu processo de criptografia e de gestão de chaves cumpre o requisito, independentemente do algoritmo aprovado que utilize.

A Diretiva NIS2 (UE) 2022/2555, no artigo 21.º, exige que as entidades essenciais e importantes implementem medidas de gestão de riscos que abranjam as suas redes e sistemas de informação, mais uma vez sem prescrever um algoritmo específico. Exige, sim, que as organizações consigam demonstrar que medidas tomaram e porquê, e é aí que a rotação de chaves documentada, o registo de acessos e uma hierarquia de chaves definida deixam de ser extras desejáveis e passam a ser provas de auditoria.

O padrão é coerente nos três casos: os reguladores exigem criptografia e gestão de chaves fortes e documentadas e deixam a escolha do algoritmo à organização. Essa é uma razão para escolher o AES-256 ou o ChaCha20-Poly1305 pelos seus méritos técnicos, e não porque uma regulamentação específica os menciona.

Conclusão

Nada disto altera o veredicto essencial: a cifragem simétrica nunca falhou no algoritmo, e a computação quântica não muda isso. O AES-256 continua a cumprir a sua função à velocidade de que as empresas precisam. O que determina realmente se as credenciais de uma organização estão seguras é quem detém que chave, como essa chave é rodada e com que rapidez o acesso desaparece quando alguém sai. A hierarquia de chaves por registo do Passwork, descrita acima, é uma forma concreta de evitar que esse trabalho se torne ingerível à escala.

Comece por auditar que sistemas ainda gerem chaves simétricas manualmente e, depois, transfira-os para uma estrutura em que uma única chave comprometida não consiga chegar mais longe do que o necessário.

Testar como a cifragem AES-256 por registo e uma hierarquia de chaves estruturada resistem à dispersão de credenciais da própria organização. Iniciar um teste gratuito do Passwork, sem necessidade de cartão de crédito.

Perguntas frequentes: Algoritmos simétricos para a segurança dos dados

O que é a cifragem zero-knowledge? Como funciona em 5 minutos

A cifragem zero-knowledge significa que o servidor nunca possui as chaves de decifragem, apenas o texto cifrado. Saiba como funciona a cadeia de chaves, contra o que protege, o que não protege e como verificar a alegação de um fornecedor.

PassworkPasswork Team

Shadow IT vs Shadow AI: Porque a IA é a ameaça maior

Os colaboradores estão a utilizar ferramentas de IA não aprovadas, em contas que não é possível monitorizar, com dados que não é possível recuperar. Eis como é, na realidade, o risco, e o que a governação precisa de resolver.

Passwork BlogAlex Muntyan

O que é a cifragem AES-256: É realmente inquebrável em 2026?

O AES-256 não tem qualquer fraqueza prática, clássica ou quântica. O risco real está em tudo o que o rodeia: gestão de chaves, controlo de acessos e higiene das credenciais. Eis o que realmente leva as organizações a sofrer violações e o que corrigir primeiro.

PassworkPasswork Team

Symmetrische Algorithmen verschlüsseln und entschlüsseln Daten mit einem einzigen gemeinsamen Schlüssel. Dieses Ein-Schlüssel-Design macht sie schnell genug, um eine Datenbank in Echtzeit zu schützen, und robust genug, dass die Post-Quantum-Richtlinien der NSA keine Algorithmusänderung erfordern, um ihnen weiterhin zu vertrauen. Was im Unternehmensmaßstab tatsächlich scheitert, ist die Verteilung dieses einen Schlüssels an alle, die ihn benötigen, und der saubere Entzug für alle, die ihn nicht mehr brauchen — nicht die zugrunde liegende Mathematik.

Dieser Kompromiss — Geschwindigkeit und Einfachheit gegen Schlüsselverteilung — ist die gesamte Geschichte der symmetrischen Kryptografie. Alles andere, Block- versus Stromchiffren, AES gegen ChaCha20, was sich ändert, wenn Quantencomputing Realität wird, sind Details darunter.

Zentrale Erkenntnisse

• Symmetrische Verschlüsselung verwendet einen Schlüssel sowohl für die Ver- als auch für die Entschlüsselung, weshalb sie schnell genug für große Datenmengen und Echtzeit-Datenverkehr ist.
• Ihre beiden echten Stärken sind Rohgeschwindigkeit und Quantenbeständigkeit. AES-256 benötigt keine algorithmische Änderung, um gegen einen Quantenangreifer sicher zu bleiben.
• Ihre beiden echten Grenzen sind das Schlüsselverteilungsproblem und das Fehlen der Nichtabstreitbarkeit, da beide Parteien einen identischen Schlüssel besitzen.
• Gemäß der CNSA 2.0-Richtlinie der NSA bleibt AES-256 unverändert. Das Migrationsmandat für 2027-2035 zielt auf RSA und ECC ab, nicht auf symmetrische Chiffren.
• Unternehmen lösen das Verteilungsproblem mit hybrider Verschlüsselung und strukturierten Schlüsselhierarchien, nicht indem sie symmetrische Algorithmen aufgeben.

Was ist symmetrische Verschlüsselung?

Symmetrische Verschlüsselung verwendet einen geheimen Schlüssel, um Daten in Chiffretext zu verwandeln und wieder in Klartext zurückzuverwandeln. Der Absender und jeder autorisierte Empfänger besitzen eine identische Kopie dieses Schlüssels. Wer ihn hat, kann die Daten lesen. Wer ihn nicht hat, kann es nicht — unabhängig davon, wie viel Chiffretext abgefangen wird.

Symmetrische Algorithmen lassen sich in zwei Familien einteilen. Eine Blockchiffre wie AES verschlüsselt Daten in Blöcken fester Größe (128 Bit pro Block bei AES) und füllt oder verkettet Blöcke für größere Datenmengen. Eine Stromchiffre wie ChaCha20 oder das inzwischen ausgemusterte RC4 verschlüsselt einen kontinuierlichen Datenstrom Bit für Bit oder Byte für Byte. Das eignet sich besser für Kontexte mit niedriger Latenz oder begrenzten Ressourcen als das Auffüllen von Daten zu Blöcken.

Die Schlüssellänge bestimmt die tatsächliche Sicherheitsmarge. AES unterstützt 128-, 192- und 256-Bit-Schlüssel, wobei 256 Bit zum praktischen Standard für alles Sensible geworden ist. Der Leistungsunterschied ist gering, aber die Sicherheitsmarge ist größer.

Asymmetrische Verschlüsselung löst das Problem der Schlüsselweitergabe anders: Ein öffentlicher Schlüssel verschlüsselt, ein mathematisch verknüpfter privater Schlüssel entschlüsselt, und beide müssen nie am selben Ort zusammenkommen. Symmetrische Algorithmen überspringen diese Mathematik vollständig. Der Preis ist, dass beide Seiten dasselbe Geheimnis benötigen, bevor sie kommunizieren können — und genau hier liegt der eigentliche Kompromiss.

Die Vorteile symmetrischer Algorithmen

Geschwindigkeit und Effizienz

Symmetrische Algorithmen sind um Größenordnungen schneller als asymmetrische bei gleichem Datenvolumen. AES-256-GCM kann eine vollständige Datenbank, ein Festplattenvolumen oder eine Live-TLS-Sitzung verschlüsseln — ohne den Rechenaufwand, den Public-Key-Mathematik in diesem Maßstab mit sich bringt. Deshalb verwenden alle großen Protokolle symmetrische Chiffren für die eigentliche Datenübertragung und reservieren asymmetrische Kryptografie für den Handshake. Diese Lücke ist auch der Grund, warum TLS 1.3 genau einen asymmetrischen Austausch pro Sitzung durchführt und dann alles Weitere an AES oder ChaCha20 übergibt.

Für große Datenmengen konzipiert

Die Verschlüsselung von Gigabytes an Datensätzen, Protokolldateien oder Backups mit einem asymmetrischen Algorithmus wird unpraktisch, lange bevor sie nur langsam wird. Symmetrische Chiffren skalieren linear mit dem Datenvolumen und laufen auf moderner Hardware nahe der Speicherbusgeschwindigkeit. Diese Eigenschaft macht Vollverschlüsselungstools wie BitLocker und LUKS sowie die Verschlüsselung einzelner Datensätze innerhalb von Anwendungen produktionstauglich — statt eines Batch-Jobs, den jemand über Nacht ausführt.

Einfach zu implementieren und zu prüfen

Ein Schlüssel, ein Algorithmus, kein Schlüsselpaar zum Generieren, Austauschen oder Validieren. Weniger bewegliche Teile bedeuten weniger Stellen, an denen eine Implementierung schiefgehen kann. Das ist ein wichtiger Grund, warum AES als NIST-Standard über zwei Jahrzehnte öffentlicher Kryptoanalyse ohne praktischen Bruch überstanden hat. AES-Implementierungen werden zudem weitgehend gegen das Cryptographic Algorithm Validation Program von NIST validiert, sodass ein Team, das es einsetzt, sich nicht auf eine selbst entwickelte oder ungeprüfte Bibliothek verlässt.

Quantenbeständigkeit

Symmetrische Algorithmen sind der einzige Teil des kryptografischen Stacks, der für die Post-Quantum-Ära keine Änderung benötigt. Grovers Algorithmus gibt einem Quantencomputer eine theoretische quadratische Beschleunigung gegen Brute-Force-Schlüsselsuche, aber eine quadratische Beschleunigung gegen einen 2²⁵⁶-Schlüsselraum halbiert die Quantenresistenz von AES-256 nur auf eine effektive 128-Bit-Marge. Diese bleibt mit jeglicher Hardware auf einem realistischen Entwicklungspfad rechnerisch unmöglich zu brechen. Der Abschnitt über Quantencomputing weiter unten behandelt, was CNSA 2.0 tatsächlich dazu sagt und warum der Migrationsdruck vollständig auf asymmetrischen Algorithmen liegt.

Die Nachteile symmetrischer Algorithmen

Das Schlüsselverteilungsproblem

Jedes symmetrische Schema stößt auf dieselbe Hürde: Wie bringt man den geheimen Schlüssel zur anderen Partei, ohne dass ein Lauscher ihn auch erhält? Den Schlüssel über denselben Kanal wie die Daten zu senden, verfehlt den Zweck. Ein separater Versand per Post skaliert nicht über eine Handvoll Personen hinaus. Und ein per Chat oder E-Mail geteilter Schlüssel liegt auf unbestimmte Zeit im Klartext in jemandes Posteingang. Dieses einzelne Problem ist der Grund, warum hybride Verschlüsselung überhaupt existiert — es wird später in diesem Artikel ausführlich behandelt.

Skalierbarkeit bricht schnell zusammen

Ein Netzwerk, in dem jedes Benutzerpaar einen eindeutigen gemeinsamen Schlüssel benötigt, wächst mit n(n-1)/2. Zehn Benutzer benötigen 45 verschiedene Schlüssel. Hundert Benutzer benötigen 4.950. Eine mittelgroße Engineering-Abteilung, die mit 20 Personen beginnt, die Datenbank-Zugangsdaten teilen, und auf 200 wächst, geht von 190 paarweisen Schlüsseln auf fast 20.000 — ohne dass jemand beschlossen hätte, das Schlüsselmanagement absichtlich schwieriger zu machen. Die Verwaltung, Rotation und der Widerruf so vieler paarweiser Schlüssel von Hand erfordert automatisiertes Schlüsselmanagement oder, praktischer, eine gemeinsame Architektur, in der Benutzer nicht jeweils einen direkten paarweisen Schlüssel benötigen.

Der übliche Workaround — ein einziger gemeinsamer Schlüssel pro Team oder Abteilung statt pro Paar — tauscht das Skalierbarkeitsproblem gegen ein schlimmeres Blast-Radius-Problem ein: Ein geleakter Schlüssel legt nun jede Zugangsberechtigung offen, die die gesamte Gruppe teilt, und eine Rotation bedeutet, alles auf einmal anzufassen statt nur eine Beziehung.

Wenn Ihr Team bereits gemeinsame Datenbankpasswörter und API-Schlüssel über eine wachsende Belegschaft hinweg verwaltet, ist dies genau das Problem, auf das Sie stoßen. Testen Sie Passwork kostenlos und sehen Sie, wie Zugangskontrolle auf Tresor-Ebene die Tabellenkalkulation ersetzt.

Keine Nichtabstreitbarkeit

Da Absender und Empfänger einen identischen Schlüssel besitzen, beweist nichts am Chiffretext, wer ihn tatsächlich erstellt hat. Beide Parteien hätten dieselbe Nachricht mit demselben Schlüssel erzeugen können, sodass symmetrische Verschlüsselung allein nicht die Art von Ursprungsnachweis liefern kann, die eine digitale Signatur bietet. Das ist wichtiger, als es klingt: Wenn eine gemeinsam genutzte Datenbank-Zugangsberechtigung durchsickert und zwei Personen Zugang zum Verschlüsselungsschlüssel hatten, gibt symmetrische Verschlüsselung allein keine kryptografische Möglichkeit festzustellen, wer ihn verwendet hat. Systeme, die Nichtabstreitbarkeit benötigen, setzen asymmetrische Signaturen zusätzlich ein oder verlassen sich auf Zugriffsprotokolle, um festzustellen, wer was und wann getan hat.

AES vs. ChaCha20: Welchen sollten Sie tatsächlich verwenden?

Verwenden Sie AES-256-GCM, wenn Ihre Hardware AES-NI-Beschleunigung hat — das trifft auf die meisten modernen Server- und Desktop-CPUs zu. Verwenden Sie ChaCha20-Poly1305, wenn nicht — auf mobilen Chips, eingebetteten Geräten oder reinen Software-Umgebungen, in denen AES ohne Hardware-Unterstützung läuft. Das ist die AES-NI-Faustregel, und sie entscheidet die Wahl für die überwiegende Mehrheit der Implementierungen.

Beide sind authentifizierte Verschlüsselungsmodi, was bedeutet, dass sie Manipulationen erkennen und Inhalte verbergen — in einem Durchgang, anstatt einen nachträglichen Authentifizierungsschritt zu benötigen. Beide sind für TLS 1.3 zugelassen, und WireGuard, das in den Linux-Kernel integrierte VPN-Protokoll, verwendet ChaCha20-Poly1305 als einzige Chiffre — genau wegen dieser Hardware-Unabhängigkeit.

AES-NI ist weder neu noch selten: Intel fügte es Server- und Desktop-CPUs ab der Westmere-Generation 2010 hinzu, und AMD folgte kurz darauf. Die praktische Frage für die meisten Teams ist, ob ihr Software-Stack diese Beschleunigung tatsächlich nutzt, anstatt auf eine langsame, unbeschleunigte Implementierung zurückzufallen. Überspringen Sie die Liste veralteter Algorithmen vollständig: DES und 3DES sind gemäß NIST SP 800-131A Rev. 2 veraltet, und RC4 und Blowfish haben bekannte praktische Schwächen, die sie für alles ausschließen, was 2026 Live-Datenverkehr verarbeitet.

Quantencomputing und symmetrische Algorithmen: Was sich tatsächlich ändert

Grovers Algorithmus halbiert die effektive Sicherheitsmarge von AES-256 auf ungefähr 128 Bit Quantenresistenz. Diese bleibt mit jeglicher absehbarer Quantenhardware rechnerisch unmöglich per Brute-Force zu brechen. Der Algorithmus selbst muss nicht geändert werden. Vergleichen Sie das mit dem, was Grovers Algorithmus mit einem 128-Bit-Schlüssel macht: Er senkt die effektive Marge auf 64 Bit, gut im Brute-Force-Bereich. Das ist der eigentliche Grund, warum 256-Bit-Schlüssel jetzt der praktische Mindeststandard für alles Langlebige sind — nicht nur eine konservative Präferenz.

CNSA 2.0 erzwingt einen harten Umstieg für RSA und ECC. AES-256 bleibt unangetastet. Das FAQ zur Commercial National Security Algorithm Suite 2.0 der NSA besagt, dass die symmetrischen Anforderungen „im Wesentlichen dieselben" sind wie bei CNSA 1.0, sofern die Schlüsselgrößen bei 256 Bit bleiben. Die vorgeschriebene Migration läuft nach einem festen Zeitplan: Neue Beschaffungen für Nationale Sicherheitssysteme müssen ab dem 1. Januar 2027 CNSA 2.0-konform sein, nicht konforme Ausrüstung wird bis zum 31. Dezember 2030 ausgemustert, CNSA 2.0 wird bis zum 31. Dezember 2031 verpflichtend, und vollständige Quantenresistenz ist für 2035 angestrebt. Jede dieser Fristen gilt für die Ablösung von RSA- und ECC-Schlüsselaustausch und -Signaturen durch ML-KEM und ML-DSA — die Post-Quantum-Standards, die NIST im August 2024 als FIPS 203 und FIPS 204 finalisiert hat.

Es gibt allerdings ein echtes Quantenrisiko, das symmetrisch geschützte Daten betrifft: Harvest-Now-Decrypt-Later. Ein Angreifer, der heute verschlüsselten Datenverkehr aufzeichnet und darauf setzt, dass ein zukünftiger Quantencomputer den asymmetrischen Schlüsselaustausch bricht, der ihn geschützt hat, zielt auf den RSA- oder ECC-Handshake ab — nicht auf den AES-Sitzungsschlüssel selbst. Ein kurzlebiger TLS-Sitzungsschlüssel, der im Moment des Verbindungsabbaus verworfen wird, ist ein schlechtes Sammelziel. Die tatsächliche Exposition betrifft Daten, deren langfristige Vertraulichkeit immer noch von einem asymmetrischen Schlüsselaustausch abhängt, der vor Jahren durchgeführt wurde — Regierungsunterlagen, langlebige digitale Signaturen oder geistiges Eigentum, das unter einem RSA-verpackten Schlüssel verschlüsselt wurde, der nie auf ein Post-Quantum-Schema rotiert wurde.

Nichts davon ändert die Richtlinien für symmetrische Chiffren im Speziellen. Organisationen, die eine Post-Quantum-Migration planen, sollten diese Anstrengung in die Ablösung von RSA- und ECC-Schlüsselaustausch und -Signaturen investieren — nicht in die Neuverschlüsselung von AES-256-Implementierungen, die bereits die 256-Bit-Anforderung erfüllen.

Die Nachteile überwinden: Wie Unternehmen symmetrische Schlüssel tatsächlich verwalten

Die branchenübliche Antwort auf das Schlüsselverteilungsproblem ist hybride Verschlüsselung — und sie läuft bereits bei fast jeder sicheren Verbindung, die Sie herstellen. TLS 1.3 verwendet asymmetrischen Schlüsselaustausch (typischerweise ECDHE), um über ein nicht vertrauenswürdiges Netzwerk ein gemeinsames Geheimnis zu vereinbaren, ohne dieses Geheimnis direkt zu übertragen. Dann wechselt es zu einer symmetrischen Chiffre — AES-256-GCM oder ChaCha20-Poly1305 — für den eigentlichen Sitzungsdatenverkehr. Asymmetrische Kryptografie löst das „Wie vereinbaren wir ein Geheimnis, ohne dass jemand mithört"-Problem einmal zu Beginn der Verbindung. Symmetrische Kryptografie übernimmt die Hauptlast für alles danach, weil dann beide Seiten bereits den benötigten Schlüssel teilen.

Dieses Muster löst die Verteilung für eine einmalige Sitzung. Es löst nicht das Schlüsselmanagement für ruhende Daten oder für langlebige Unternehmensgeheimnisse, die jede einzelne Verbindung überdauern — Zugangsdaten, die monatelang oder jahrelang in einem Tresor liegen und über ein ganzes Team geteilt werden. Das erfordert bewusste, kontinuierliche Kontrollen:

• Schlüssel nach einem definierten Zeitplan rotieren und sofort nach jedem Verdacht auf Kompromittierung — nicht ad hoc, gesteuert davon, wer gerade daran denkt.
• Aufgaben trennen, sodass kein einzelner Administrator einen Schlüssel einseitig abrufen, exportieren und verwenden kann. Das begrenzt, wie viel Schaden ein kompromittiertes Konto anrichten kann.
• Jeden Schlüsselzugriff und -export protokollieren und diese Protokolle an ein Sicherheitsteam weiterleiten, das sie tatsächlich regelmäßig überprüft — nicht an einen Aufbewahrungsspeicher, den niemand öffnet.
• Schlüssel in einem Hardware Security Module (HSM) oder einem gleichwertigen hardwaregestützten Tresor speichern — nicht in Konfigurationsdateien, Umgebungsvariablen oder einer geteilten Tabellenkalkulation, die nicht dafür gebaut wurden, ein Geheimnis geheim zu halten.
• Rotation und Widerruf automatisieren, anstatt sich darauf zu verlassen, dass jemand beim Offboarding daran denkt — denn genau dieser Schritt wird unter Zeitdruck übersprungen.

Jede dieser Maßnahmen ist eine Prozessverbesserung, die auf den Algorithmus aufgesetzt wird. Zusammen behandeln sie Schlüsselmanagement als eigene Disziplin mit definiertem Verantwortlichen — nicht als etwas, das automatisch passiert, wenn jemand daran denkt.

Wie Passwork dies umsetzt: Eine Schlüsselhierarchie, die jeden Datensatz isoliert

Passworks eigene Zero-Knowledge-Architektur ist eine konkrete Antwort auf die oben beschriebenen Verteilungs- und Skalierbarkeitsprobleme. Die clientseitige Kette funktioniert so:

• Ein Masterpasswort, das nie an den Server übertragen wird, leitet über PBKDF2 mit etwa 300.000 clientseitigen Iterationen einen Master-Schlüssel ab.
• Dieser Master-Schlüssel entschlüsselt den privaten RSA-2048-Schlüssel des Benutzers, der wiederum die Schlüssel für jeden Tresor entschlüsselt, auf den der Benutzer Zugriff hat.
• Jeder Tresor-Schlüssel entsperrt seinerseits den individuellen AES-256-Schlüssel für jeden darin enthaltenen Datensatz, und nur dieser Schlüssel entschlüsselt das tatsächliche Passwort oder Geheimnis.

Jeder Schritt in dieser Kette findet auf dem Client statt. Der Server speichert nur Chiffretext und verschlüsselte Schlüssel, die er selbst nicht lesen kann.

Der Sinn dieses Aufbaus ist der Blast Radius. Ein kompromittierter oder rotierter Schlüssel betrifft einen Datensatz oder einen Tresor — nicht den gesamten Zugangsdatenbestand der Organisation. Es gibt keinen einzelnen Master-Schlüssel, der alles auf einmal entsperrt, kein Äquivalent zum oben beschriebenen n(n-1)/2-Problem mit paarweisen Schlüsseln.

Das Ändern eines Masterpassworts verpackt nur den privaten Schlüssel des Benutzers neu. Es erfordert keine Neuverschlüsselung jedes Datensatzes, den dieser Schlüssel letztendlich erreichen kann — das ist der operative Unterschied zwischen einer Rotation, die Sekunden dauert, und einer, die ein Wartungsfenster erfordert. Passwork betreibt zusätzlich eine unabhängige serverseitige AES-256-Schicht über dieser clientseitigen Kette. Die Kompromittierung einer Verschlüsselungsschicht übergibt einem Angreifer nicht die andere — ein Muster, das verwandt mit, aber unterschiedlich von Ende-zu-Ende-Verschlüsselung in Messaging-Systemen ist.

Der Zugang zu einem geteilten Zugangsdatensatz kann weiterhin sofort widerrufen und protokolliert werden — das verwandelt „wer kann das technisch entschlüsseln" in „wer ist tatsächlich noch autorisiert". Vollständige Implementierungsdetails finden Sie in Passworks Dokumentation zur Kryptografie-Architektur.

Symmetrische Verschlüsselung und Compliance-Anforderungen

Die meisten Rahmenwerke, die Verschlüsselung erwähnen, beschreiben, was sie erreichen muss — nicht welchen Algorithmus man verwenden soll. Diese Unterscheidung falsch zu verstehen, führt zu Compliance-Behauptungen, die einer Prüfung nicht standhalten.

DSGVO Artikel 32(1)(a) nennt „die Pseudonymisierung und Verschlüsselung personenbezogener Daten" als Beispiel für eine geeignete technische Sicherheitsmaßnahme — eine Option unter mehreren, keine Vorschrift für eine bestimmte Chiffre. Der Artikel überlässt die Implementierung, einschließlich der Algorithmuswahl, der eigenen Risikobewertung der Organisation.

PCI DSS v4.0 Anforderung 3.5.1 verlangt, gespeicherte Karteninhaberdaten durch Einweg-Hashes, Kürzung, Index-Token oder starke Kryptografie mit dokumentierten Schlüsselmanagement-Prozessen unlesbar zu machen. Der Unterschied zwischen Hashing und Verschlüsselung ist hier wichtig, da nur eine dieser vier Optionen umkehrbar ist. Die Anforderung nennt weder AES noch spezifiziert sie eine Mindestschlüssellänge. PCI DSS als „AES-256-Mandat" zu behandeln — eine Behauptung, die in mehr als ein paar Sicherheits-Blogbeiträgen auftaucht — übertreibt, was der Standard tatsächlich sagt. Eine Organisation, die ihre Kryptografie und ihren Schlüsselmanagement-Prozess dokumentieren kann, erfüllt die Anforderung unabhängig davon, welchen zugelassenen Algorithmus sie verwendet.

Die NIS2-Richtlinie (EU) 2022/2555, Artikel 21, verpflichtet wesentliche und wichtige Einrichtungen, Risikomanagement-Maßnahmen für ihre Netz- und Informationssysteme umzusetzen — wiederum ohne einen spezifischen Algorithmus vorzuschreiben. Sie verlangt jedoch, dass Organisationen zeigen können, welche Maßnahmen sie ergriffen haben und warum. Hier werden dokumentierte Schlüsselrotation, Zugriffsprotokolle und eine definierte Schlüsselhierarchie von „nice-to-have" zu Prüfungsnachweisen.

Das Muster über alle drei hinweg ist konsistent: Regulierungsbehörden verlangen starke, dokumentierte Kryptografie und Schlüsselmanagement und überlassen die Algorithmuswahl der Organisation. Das ist ein Grund, AES-256 oder ChaCha20-Poly1305 aufgrund ihrer technischen Vorzüge zu wählen — nicht weil eine bestimmte Vorschrift sie namentlich nennt.

Fazit

Nichts davon ändert das grundlegende Urteil: Der Algorithmus war nie der Punkt, an dem symmetrische Verschlüsselung scheiterte, und Quantencomputing verschiebt dieses Ziel nicht. AES-256 erfüllt seine Aufgabe weiterhin mit der Geschwindigkeit, die Unternehmen benötigen. Die Arbeit, die tatsächlich bestimmt, ob die Zugangsdaten einer Organisation sicher sind, ist: wer welchen Schlüssel besitzt, wie er rotiert wird und wie schnell der Zugang entzogen wird, wenn jemand geht. Die oben beschriebene Schlüsselhierarchie pro Datensatz von Passwork ist eine konkrete Möglichkeit, diese Arbeit im großen Maßstab handhabbar zu halten.

Beginnen Sie damit zu prüfen, welche Systeme symmetrische Schlüssel noch manuell verwalten, und verschieben Sie diese dann in eine Struktur, in der ein einzelner kompromittierter Schlüssel nicht mehr erreichen kann, als er muss.

Testen Sie, wie AES-256-Verschlüsselung pro Datensatz und eine strukturierte Schlüsselhierarchie gegen Ihre eigene Zugangsdaten-Wildwuchs bestehen. Starten Sie eine kostenlose Testversion von Passwork — keine Kreditkarte erforderlich.

FAQ: Symmetrische Algorithmen für Datensicherheit

Was ist Zero-Knowledge-Verschlüsselung? So funktioniert sie in 5 Minuten

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server niemals Ihre Entschlüsselungsschlüssel besitzt — nur Chiffretext. Erfahren Sie, wie die Schlüsselkette funktioniert, wovor sie schützt, wovor nicht, und wie Sie die Behauptung eines Anbieters überprüfen.

PassworkPasswork Team

Shadow IT vs Shadow AI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. Hier erfahren Sie, wie das Risiko tatsächlich aussieht und was Governance ansprechen muss.

Passwork BlogAlex Muntyan

Was ist AES-256-Verschlüsselung: Ist sie 2026 wirklich unknackbar?

AES-256 hat keine praktische Schwäche — weder klassisch noch quantenbasiert. Das eigentliche Risiko ist alles drumherum: Schlüsselmanagement, Zugangskontrolle und Zugangsdaten-Hygiene. Hier erfahren Sie, was Organisationen tatsächlich kompromittiert und was Sie zuerst beheben sollten.

PassworkPasswork Team

Los algoritmos simétricos cifran y descifran datos con una única clave compartida. Ese diseño de clave única es lo que los hace lo suficientemente rápidos para proteger una base de datos en tiempo real, y lo suficientemente duraderos como para que la guía postcuántica de la NSA no requiera cambiar de algoritmo para seguir confiando en ellos. Lo que realmente falla a escala empresarial es conseguir que esa única clave llegue a todos los que la necesitan, y retirarla correctamente de quienes ya no deberían tenerla — no las matemáticas subyacentes.

Esa compensación entre velocidad y simplicidad frente a la distribución de claves es toda la historia de la criptografía simétrica. Todo lo demás — cifrados de bloque frente a cifrados de flujo, AES contra ChaCha20, qué cambia cuando la computación cuántica sea una realidad — son detalles por debajo de eso.

Puntos clave

• El cifrado simétrico utiliza una clave tanto para cifrar como para descifrar, razón por la cual es lo suficientemente rápido para grandes volúmenes de datos y tráfico en tiempo real.
• Sus dos verdaderas fortalezas son la velocidad bruta y la durabilidad cuántica. AES-256 no necesita ningún cambio algorítmico para permanecer seguro contra un adversario cuántico.
• Sus dos verdaderas limitaciones son el problema de distribución de claves y la falta de no repudio, ya que ambas partes poseen una clave idéntica.
• Bajo la guía CNSA 2.0 de la NSA, AES-256 se mantiene sin cambios. El mandato de migración 2027-2035 apunta a RSA y ECC, no a los cifrados simétricos.
• Las empresas resuelven el problema de distribución con cifrado híbrido y jerarquías de claves estructuradas, no abandonando los algoritmos simétricos.

¿Qué es el cifrado simétrico?

El cifrado simétrico utiliza una clave secreta para convertir los datos en texto cifrado y devolverlos a texto plano. El remitente y cada destinatario autorizado poseen una copia idéntica de esa clave. Quien la tiene puede leer los datos. Quien no la tiene, no puede — sin importar cuánto texto cifrado intercepte.

Los algoritmos simétricos se dividen en dos familias. Un cifrado de bloque, como AES, cifra los datos en fragmentos de tamaño fijo (128 bits a la vez para AES), rellenando o encadenando bloques para cualquier cosa mayor. Un cifrado de flujo, como ChaCha20 o el ya retirado RC4, cifra un flujo continuo de datos un bit o byte a la vez, lo que se adapta mejor a contextos de baja latencia o recursos limitados que rellenar datos en bloques.

La longitud de la clave es lo que establece el margen de seguridad real. AES admite claves de 128, 192 y 256 bits, y 256 bits se ha convertido en el estándar práctico para cualquier cosa sensible, ya que la diferencia de coste en rendimiento es pequeña y el margen de seguridad es mayor.

El cifrado asimétrico resuelve el problema del intercambio de claves de manera diferente: una clave pública cifra, una clave privada matemáticamente vinculada descifra, y las dos nunca necesitan encontrarse en el mismo lugar. Los algoritmos simétricos omiten completamente esas matemáticas. El coste es que ambos lados necesitan el mismo secreto antes de poder comunicarse, que es donde reside la verdadera compensación.

Las ventajas de los algoritmos simétricos

Velocidad y eficiencia

Los algoritmos simétricos son órdenes de magnitud más rápidos que los asimétricos para el mismo volumen de datos. AES-256-GCM puede cifrar una base de datos completa, un volumen de disco o una sesión TLS en vivo sin la sobrecarga computacional que conllevan las matemáticas de clave pública a esa escala, razón por la cual todos los protocolos principales utilizan cifrados simétricos para la transferencia real de datos y reservan la criptografía asimétrica para el handshake. Esa diferencia también explica por qué TLS 1.3 ejecuta un intercambio asimétrico exactamente una vez por sesión y luego entrega todo lo demás a AES o ChaCha20.

Diseñado para grandes volúmenes de datos

Cifrar gigabytes de registros, archivos de log o copias de seguridad con un algoritmo asimétrico se vuelve impráctico mucho antes de volverse meramente lento. Los cifrados simétricos escalan linealmente con el volumen de datos y, en hardware moderno, funcionan cerca de la velocidad del bus de memoria. Esa es la propiedad que hace que las herramientas de cifrado de disco completo como BitLocker y LUKS, y el cifrado por registro dentro de las aplicaciones, sean viables en producción en lugar de un trabajo por lotes que alguien ejecuta durante la noche.

Simple de implementar y auditar

Una clave, un algoritmo, sin par de claves que generar, intercambiar o validar. Menos piezas móviles significa menos lugares donde una implementación puede fallar, y es en gran parte la razón por la que AES ha sobrevivido más de dos décadas de criptoanálisis público como estándar NIST sin una ruptura práctica. Las implementaciones de AES también están ampliamente validadas contra el Programa de Validación de Algoritmos Criptográficos de NIST, por lo que un equipo que lo adopta no depende de una biblioteca casera o no auditada.

Durabilidad cuántica

Los algoritmos simétricos son la única parte de la pila criptográfica que no necesita cambiar para la era postcuántica. El algoritmo de Grover proporciona a un ordenador cuántico una aceleración teórica cuadrática contra la búsqueda de claves por fuerza bruta, pero una aceleración cuadrática contra un espacio de claves de 2²⁵⁶ solo reduce a la mitad la resistencia cuántica de AES-256 a un margen efectivo de 128 bits, que sigue siendo computacionalmente inviable de romper con cualquier hardware en una hoja de ruta realista. La sección de computación cuántica más adelante cubre lo que CNSA 2.0 realmente dice sobre esto, y por qué la presión de migración recae enteramente sobre los algoritmos asimétricos.

Las desventajas de los algoritmos simétricos

El problema de distribución de claves

Todo esquema simétrico se topa con el mismo muro: ¿cómo se hace llegar la clave secreta a la otra parte sin que un intruso también la obtenga? Enviar la clave por el mismo canal que los datos anula el propósito, enviarla por separado por correo no escala más allá de un puñado de personas, y una clave compartida por chat o correo electrónico queda en texto plano en la bandeja de entrada de alguien indefinidamente. Este único problema es la razón por la que existe el cifrado híbrido, y se cubre en detalle más adelante en este artículo.

La escalabilidad se descompone rápidamente

Una red donde cada par de usuarios necesita una clave compartida única crece a n(n-1)/2. Diez usuarios necesitan 45 claves distintas. Cien usuarios necesitan 4.950. Una organización de ingeniería de tamaño medio que comienza con 20 personas compartiendo credenciales de base de datos y crece a 200 pasa de 190 claves por pares a casi 20.000, sin que nadie haya decidido hacer la gestión de claves más difícil a propósito. Gestionar, rotar y revocar tantas claves por pares manualmente exige gestión automatizada de claves o, más prácticamente, una arquitectura compartida donde los usuarios no necesitan una clave directa por pares.

La solución alternativa habitual, una única clave compartida por equipo o departamento en lugar de por par, intercambia el problema de escalabilidad por un problema peor de radio de explosión: una clave filtrada ahora expone cada credencial que comparte todo el grupo, y rotarla significa tocar todo a la vez en lugar de una sola relación.

Si su equipo ya está gestionando contraseñas de bases de datos compartidas y claves API con una plantilla en crecimiento, este es el problema con el que se está encontrando. Pruebe Passwork gratis y vea cómo el acceso a nivel de bóveda reemplaza la hoja de cálculo.

Sin no repudio

Dado que el remitente y el destinatario poseen una clave idéntica, nada en el texto cifrado demuestra quién lo creó realmente. Cualquiera de las partes podría haber generado el mismo mensaje con la misma clave, por lo que el cifrado simétrico por sí solo no puede proporcionar el tipo de prueba de origen que ofrece una firma digital. Esto importa más de lo que parece: si una credencial de base de datos compartida se filtra y dos personas tenían acceso a la clave que la cifraba, el cifrado simétrico por sí solo no proporciona ninguna forma criptográfica de establecer cuál de ellas la usó. Los sistemas que necesitan no repudio agregan firmas asimétricas encima, o dependen del registro de accesos para establecer quién hizo qué y cuándo.

AES vs. ChaCha20: ¿cuál debería usar realmente?

Use AES-256-GCM cuando su hardware tenga aceleración AES-NI, lo que cubre la mayoría de las CPU modernas de servidor y escritorio. Use ChaCha20-Poly1305 cuando no la tenga — en chips móviles, dispositivos embebidos o entornos de solo software donde AES funciona sin soporte de hardware. Esta es la regla general de AES-NI, y resuelve la elección para la gran mayoría de las implementaciones.

Ambos son modos de cifrado autenticado, lo que significa que detectan manipulaciones además de ocultar el contenido, en una sola pasada en lugar de necesitar un paso de autenticación añadido. Ambos están aprobados para uso en TLS 1.3, y WireGuard, el protocolo VPN integrado en el kernel de Linux, utiliza ChaCha20-Poly1305 como su único cifrado precisamente por esa razón de independencia del hardware.

AES-NI no es nuevo ni raro: Intel lo añadió a las CPU de servidor y escritorio a partir de la generación Westmere en 2010, y AMD siguió poco después. La pregunta práctica para la mayoría de los equipos es si su pila de software realmente usa esa aceleración en lugar de recurrir a una implementación lenta y no acelerada. Omita completamente la lista de sistemas heredados: DES y 3DES están obsoletos bajo NIST SP 800-131A Rev. 2, y RC4 y Blowfish tienen debilidades prácticas conocidas que los descartan para cualquier cosa que maneje tráfico en vivo en 2026.

Computación cuántica y algoritmos simétricos: ¿Qué cambia realmente?

El algoritmo de Grover reduce a la mitad el margen de seguridad efectivo de AES-256 a aproximadamente 128 bits de resistencia cuántica, lo que sigue siendo computacionalmente inviable de romper por fuerza bruta con cualquier hardware cuántico previsible. El algoritmo en sí no necesita cambiar. Compare eso con lo que el algoritmo de Grover hace a una clave de 128 bits: reduce el margen efectivo a 64 bits, bien dentro del alcance de la fuerza bruta, lo cual es la razón real por la que las claves de 256 bits son ahora el piso práctico para cualquier cosa de larga duración en lugar de una preferencia conservadora.

CNSA 2.0 fuerza un cambio obligatorio para RSA y ECC. No toca AES-256. El FAQ del Commercial National Security Algorithm Suite 2.0 de la NSA establece que sus requisitos simétricos son «esencialmente los mismos» que los de CNSA 1.0, siempre que los tamaños de clave se mantengan en 256 bits. La migración obligatoria funciona con un calendario fijo: las nuevas adquisiciones de Sistemas de Seguridad Nacional deben ser compatibles con CNSA 2.0 para el 1 de enero de 2027, el equipamiento no compatible se elimina gradualmente para el 31 de diciembre de 2030, CNSA 2.0 se vuelve obligatorio para el 31 de diciembre de 2031, y se apunta a la resistencia cuántica completa para 2035. Cada uno de esos plazos se aplica a reemplazar el intercambio de claves y las firmas RSA y ECC con los estándares postcuánticos ML-KEM y ML-DSA, que NIST finalizó como FIPS 203 y FIPS 204 en agosto de 2024.

Sin embargo, hay un riesgo cuántico real que sí afecta a los datos protegidos simétricamente: «recopilar ahora, descifrar después». Un atacante que graba tráfico cifrado hoy, apostando a que un futuro ordenador cuántico romperá el intercambio de claves asimétrico que lo protegió, está apuntando al handshake RSA o ECC, no a la clave de sesión AES en sí. Una clave de sesión TLS de corta duración, descartada en el momento en que se cierra la conexión, es un objetivo de recopilación deficiente. La exposición real son datos cuya confidencialidad a largo plazo todavía depende de un intercambio de claves asimétrico realizado hace años — registros gubernamentales, firmas digitales de larga duración o propiedad intelectual cifrada bajo una clave envuelta con RSA que nunca se rotó a un esquema postcuántico.

Nada de esto cambia la orientación específica para los cifrados simétricos. Las organizaciones que planifican una migración postcuántica deberían dedicar ese esfuerzo a reemplazar el intercambio de claves y las firmas RSA y ECC, no a cambiar las claves de implementaciones AES-256 que ya cumplen con el requisito de 256 bits.

Superando las desventajas: Cómo gestionan realmente las empresas las claves simétricas

La respuesta estándar de la industria al problema de distribución de claves es el cifrado híbrido, y ya está funcionando debajo de casi cada conexión segura que realiza. TLS 1.3 utiliza el intercambio de claves asimétrico (típicamente ECDHE) para acordar un secreto compartido a través de una red no confiable sin transmitir nunca ese secreto directamente, luego cambia a un cifrado simétrico — AES-256-GCM o ChaCha20-Poly1305 — para el tráfico real de la sesión. La criptografía asimétrica resuelve el problema de «cómo acordamos un secreto sin que nadie lo escuche» una vez, al inicio de la conexión; la criptografía simétrica hace el trabajo pesado para todo lo demás, porque para entonces ambos lados ya comparten la clave que necesitan.

Ese patrón resuelve la distribución para una sesión puntual. No resuelve la gestión de claves para datos en reposo o para secretos empresariales de larga duración que sobreviven a cualquier conexión individual — credenciales que permanecen en una bóveda durante meses o años, compartidas en todo un equipo. Eso requiere controles deliberados y continuos:

• Rote las claves según un calendario definido e inmediatamente después de cualquier sospecha de compromiso, no de forma ad hoc impulsada por quien se acuerde de hacerlo.
• Separe las funciones para que ningún administrador individual pueda acceder, exportar y usar una clave unilateralmente, lo que limita cuánto daño puede hacer una cuenta comprometida.
• Registre cada acceso a claves y acción de exportación, y envíe esos registros a un equipo de seguridad que realmente los revise según un calendario, en lugar de un depósito de retención que nadie abre.
• Almacene las claves en un Módulo de Seguridad de Hardware (HSM) o una bóveda equivalente respaldada por hardware en lugar de en archivos de configuración, variables de entorno o una hoja de cálculo compartida — ninguno de los cuales fue diseñado para mantener un secreto en secreto.
• Automatice la rotación y revocación en lugar de depender de que alguien recuerde hacerlo durante la baja de empleados, ya que ese es exactamente el paso que se salta bajo presión de tiempo.

Cada uno de estos es una corrección de proceso superpuesta al algoritmo, y juntos tratan la gestión de claves como su propia disciplina con un propietario definido, en lugar de algo que sucede por defecto cuando alguien se acuerda.

Cómo aplica esto Passwork: Una jerarquía de claves que aísla cada registro

La propia arquitectura de conocimiento cero de Passwork es una respuesta concreta a los problemas de distribución y escalabilidad descritos anteriormente. La cadena del lado del cliente funciona así:

• Una contraseña maestra, nunca transmitida al servidor, deriva una clave maestra a través de PBKDF2 con aproximadamente 300.000 iteraciones del lado del cliente.
• Esa clave maestra descifra la clave privada RSA-2048 del usuario, que descifra las claves de cada bóveda a la que el usuario tiene acceso.
• Cada clave de bóveda, a su vez, desbloquea la clave AES-256 individual para cada registro dentro de ella, y solo esa clave descifra la contraseña o secreto real.

Cada paso en esa cadena ocurre en el cliente. El servidor solo almacena texto cifrado y claves cifradas que no tiene forma de leer por sí mismo.

El objetivo de construirlo de esta manera es el radio de explosión. Una clave comprometida o rotada afecta a un registro o una bóveda, no a todo el patrimonio de credenciales de la organización, porque no hay una única clave maestra que desbloquee todo a la vez — ningún equivalente al problema de claves por pares n(n-1)/2 descrito anteriormente.

Cambiar una contraseña maestra solo vuelve a envolver la clave privada del usuario. No requiere volver a cifrar cada registro al que esa clave puede eventualmente acceder, lo cual es la diferencia operativa entre una rotación que tarda segundos y una que requiere una ventana de mantenimiento. Passwork también ejecuta una capa AES-256 independiente del lado del servidor encima de esta cadena del lado del cliente, por lo que comprometer una capa de cifrado no entrega la otra al atacante — un patrón relacionado pero distinto del cifrado de extremo a extremo en sistemas de mensajería.

El acceso a una credencial compartida todavía puede revocarse instantáneamente y registrarse, lo que transforma «quién puede técnicamente descifrar esto» en «quién está realmente todavía autorizado». Los detalles completos de implementación están en la documentación de arquitectura criptográfica de Passwork.

Cifrado simétrico y requisitos de cumplimiento

La mayoría de los marcos que mencionan el cifrado describen lo que debe lograr, no qué algoritmo usar, y confundir esa distinción lleva a afirmaciones de cumplimiento que no resisten una auditoría.

El Artículo 32(1)(a) del RGPD nombra «la seudonimización y el cifrado de datos personales» como ejemplo de una medida técnica de seguridad apropiada — una opción entre varias en lugar de un mandato para un cifrado específico. El artículo deja la implementación, incluyendo qué algoritmo usar, a la propia evaluación de riesgos de la organización.

El Requisito 3.5.1 de PCI DSS v4.0 exige hacer ilegibles los datos de titulares de tarjetas almacenados mediante hashes unidireccionales, truncamiento, tokens de índice o criptografía fuerte con procesos documentados de gestión de claves — y conocer la diferencia entre hashing y cifrado importa aquí, ya que solo una de esas cuatro opciones es reversible. No nombra AES ni especifica una longitud mínima de clave, por lo que tratar PCI DSS como un «mandato de AES-256» — una afirmación que aparece en más de unas pocas publicaciones de blogs de seguridad — exagera lo que el estándar realmente dice. Una organización que puede documentar su proceso de criptografía y gestión de claves cumple el requisito independientemente del algoritmo aprobado que ejecute.

La Directiva NIS2 (UE) 2022/2555, Artículo 21, requiere que las entidades esenciales e importantes implementen medidas de gestión de riesgos que cubran sus sistemas de redes e información, nuevamente sin prescribir un algoritmo específico. Sí requiere que las organizaciones puedan demostrar qué medidas tomaron y por qué, que es donde la rotación de claves documentada, el registro de accesos y una jerarquía de claves definida dejan de ser opcionales y se convierten en evidencia de auditoría.

El patrón en los tres es consistente: los reguladores exigen criptografía fuerte y documentada y gestión de claves, y dejan la elección del algoritmo a la organización. Esa es una razón para elegir AES-256 o ChaCha20-Poly1305 por sus méritos técnicos, no porque una regulación específica los nombre.

Conclusión

Nada de esto cambia el veredicto básico: el algoritmo nunca fue donde falló el cifrado simétrico, y la computación cuántica no mueve esa meta. AES-256 todavía hace su trabajo a la velocidad que necesitan las empresas. El trabajo que realmente determina si las credenciales de una organización están seguras es quién tiene qué clave, cómo se rota y qué tan rápido desaparece el acceso cuando alguien se va. La jerarquía de claves por registro de Passwork, cubierta anteriormente, es una forma concreta de evitar que ese trabajo se vuelva inmanejable a escala.

Comience auditando qué sistemas todavía gestionan claves simétricas manualmente, luego muévalos a una estructura donde una única clave comprometida no pueda alcanzar más de lo necesario.

Pruebe cómo el cifrado AES-256 por registro y una jerarquía de claves estructurada resisten frente a su propia dispersión de credenciales. Inicie una prueba gratuita de Passwork — no se requiere tarjeta de crédito.

FAQ: Algoritmos simétricos para la seguridad de datos

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

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

PassworkPasswork Team

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Así es como se ve realmente el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

¿Qué es el cifrado AES-256: Es realmente irrompible en 2026?

AES-256 no tiene ninguna debilidad práctica — clásica ni cuántica. El riesgo real es todo lo que lo rodea: gestión de claves, control de acceso e higiene de credenciales. Esto es lo que realmente hace que las organizaciones sean vulneradas, y qué arreglar primero.

PassworkPasswork Team

Symmetric algorithms encrypt and decrypt data with a single shared key. That single-key design is what makes them fast enough to protect a database in real time, and durable enough that the NSA's post-quantum guidance requires no algorithm change to keep trusting them. What actually breaks at enterprise scale is getting that one key to everyone who needs it, and taking it away cleanly from everyone who doesn't, not the underlying math.

That trade-off, speed and simplicity against key distribution, is the whole story of symmetric cryptography. Everything else, block versus stream ciphers, AES against ChaCha20, what changes once quantum computing is real, is detail underneath it.

Key takeaways

• Symmetric encryption uses one key for both encryption and decryption, which is why it's fast enough for bulk data and real-time traffic.
• Its two real strengths are raw speed and quantum durability. AES-256 needs no algorithmic change to remain secure against a quantum adversary.
• Its two real limits are the key distribution problem and the lack of non-repudiation, since both parties hold an identical key.
• Under the NSA's CNSA 2.0 guidance, AES-256 stays as-is. The 2027-2035 migration mandate targets RSA and ECC, not symmetric ciphers.
• Enterprises solve the distribution problem with hybrid encryption and structured key hierarchies, not by abandoning symmetric algorithms.

What is symmetric encryption?

Symmetric encryption uses one secret key to scramble data into ciphertext and unscramble it back into plaintext. The sender and every authorized recipient hold an identical copy of that key. Whoever has it can read the data. Whoever doesn't, can't, regardless of how much ciphertext they intercept.

Symmetric algorithms fall into two families. A block cipher, like AES, encrypts data in fixed-size chunks (128 bits at a time for AES), padding or chaining blocks together for anything larger. A stream cipher, like ChaCha20 or the now-retired RC4, encrypts a continuous stream of data one bit or byte at a time, which suits low-latency or resource-constrained contexts better than padding data into blocks.

Key length is what sets the actual security margin. AES supports 128-, 192-, and 256-bit keys, and 256-bit has become the practical default for anything sensitive, since the cost difference in performance is small and the security margin is larger.

Asymmetric encryption solves the key-sharing problem differently: a public key encrypts, a mathematically linked private key decrypts, and the two never need to meet in the same place. Symmetric algorithms skip that math entirely. The cost is that both sides need the same secret before they can talk, which is where the real trade-off lives.

The pros of symmetric algorithms

Speed and efficiency

Symmetric algorithms are orders of magnitude faster than asymmetric ones for the same volume of data. AES-256-GCM can encrypt a full database, a disk volume, or a live TLS session without the computational overhead that public-key math carries at that scale, which is why every major protocol uses symmetric ciphers for the actual data transfer and reserves asymmetric cryptography for the handshake. That gap is also why TLS 1.3 runs an asymmetric exchange exactly once per session and then hands everything else to AES or ChaCha20.

Built for bulk data

Encrypting gigabytes of records, log files, or backups with an asymmetric algorithm turns impractical well before it turns merely slow. Symmetric ciphers scale linearly with data volume and, on modern hardware, run close to the memory bus speed. That's the property that makes full-disk encryption tools like BitLocker and LUKS, and per-record encryption inside applications, viable in production instead of a batch job someone runs overnight.

Simple to implement and audit

One key, one algorithm, no key pair to generate, exchange, or validate. Fewer moving parts means fewer places for an implementation to go wrong, and it's a large part of why AES has survived over two decades of public cryptanalysis as a NIST standard without a practical break. AES implementations are also widely validated against NIST's Cryptographic Algorithm Validation Program, so a team adopting it isn't relying on a homegrown or unaudited library.

Quantum durability

Symmetric algorithms are the one part of the cryptographic stack that doesn't need to change for the post-quantum era. Grover's algorithm gives a quantum computer a theoretical quadratic speedup against brute-force key search, but a quadratic speedup against a 2²⁵⁶ keyspace still only halves AES-256's quantum resistance to a 128-bit effective margin, which stays computationally infeasible to break with any hardware on a realistic roadmap. The quantum computing section below covers what CNSA 2.0 actually says about this, and why the migration pressure sits entirely on asymmetric algorithms instead.

The cons of symmetric algorithms

The key distribution problem

Every symmetric scheme runs into the same wall: how do you get the secret key to the other party without an eavesdropper getting it too? Sending the key over the same channel as the data defeats the purpose, mailing it separately doesn't scale past a handful of people, and a key shared over chat or email sits in plaintext in someone's inbox indefinitely. This single problem is why hybrid encryption exists at all, and it's covered in detail later in this article.

Scalability breaks down fast

A network where every pair of users needs a unique shared key grows at n(n-1)/2. Ten users need 45 distinct keys. A hundred users need 4,950. A mid-sized engineering org that starts with 20 people sharing database credentials and grows to 200 goes from 190 pairwise keys to nearly 20,000, without anyone deciding to make key management harder on purpose. Managing, rotating, and revoking that many pairwise keys by hand demands automated key management or, more practically, a shared architecture where users don't each need a direct pairwise key at all.

The usual workaround, a single shared key per team or department instead of per pair, trades the scalability problem for a worse blast-radius problem: one leaked key now exposes every credential the whole group shares, and rotating it means touching everything at once rather than one relationship.

If your team is already juggling shared database passwords and API keys across a growing headcount, this is the problem you're running into. Try Passwork free and see vault-level access replace the spreadsheet.

No non-repudiation

Because sender and recipient hold an identical key, nothing about the ciphertext proves who actually created it. Either party could have generated the same message with the same key, so symmetric encryption alone can't provide the kind of proof-of-origin that a digital signature does. That matters more than it sounds: if a shared database credential leaks and two people had access to the key that encrypted it, symmetric encryption alone gives you no cryptographic way to establish which one used it. Systems that need non-repudiation layer asymmetric signatures on top, or rely on access logging to establish who did what and when.

AES vs. ChaCha20: which one should you actually use?

Use AES-256-GCM when your hardware has AES-NI acceleration, which covers most modern server and desktop CPUs. Use ChaCha20-Poly1305 when it doesn't, on mobile chips, embedded devices, or software-only environments where AES runs without hardware support. This is the AES-NI rule of thumb, and it settles the choice for the overwhelming majority of deployments.

Both are authenticated encryption modes, meaning they detect tampering as well as hide content, in a single pass rather than needing a bolted-on authentication step. Both are approved for use in TLS 1.3, and WireGuard, the VPN protocol built into the Linux kernel, uses ChaCha20-Poly1305 as its only cipher for exactly that hardware-independence reason.

AES-NI isn't new or rare: Intel added it to server and desktop CPUs starting with the Westmere generation in 2010, and AMD followed shortly after. The practical question for most teams is whether their software stack actually uses that acceleration instead of falling back to a slow, unaccelerated implementation. Skip the legacy list entirely: DES and 3DES are deprecated under NIST SP 800-131A Rev. 2, and RC4 and Blowfish have known practical weaknesses that rule them out for anything handling live traffic in 2026.

Quantum computing and symmetric algorithms: What actually changes

Grover's algorithm halves AES-256's effective security margin to roughly 128 bits of quantum resistance, which remains computationally infeasible to brute-force with any foreseeable quantum hardware. The algorithm itself doesn't need to change. Compare that to what Grover's algorithm does to a 128-bit key: it drops the effective margin to 64 bits, well within brute-force range, which is the actual reason 256-bit keys are now the practical floor for anything long-lived rather than a conservative preference.

CNSA 2.0 forces a hard cutover for RSA and ECC. It does not touch AES-256. The NSA's Commercial National Security Algorithm Suite 2.0 FAQ states that its symmetric requirements are "essentially the same" as CNSA 1.0's, provided key sizes stay at 256 bits. The mandated migration runs on a fixed clock: new National Security Systems acquisitions must be CNSA 2.0-compliant by January 1, 2027, non-compliant equipment phases out by December 31, 2030, CNSA 2.0 becomes mandatory by December 31, 2031, and full quantum resistance is targeted for 2035. Every one of those deadlines applies to replacing RSA and ECC key exchange and signatures with ML-KEM and ML-DSA, the post-quantum standards NIST finalized as FIPS 203 and FIPS 204 in August 2024.

There's a real quantum risk that does touch symmetric-protected data, though: harvest-now-decrypt-later. An attacker who records encrypted traffic today, betting on a future quantum computer to break the asymmetric key exchange that protected it, is targeting the RSA or ECC handshake, not the AES session key itself. A short-lived TLS session key, discarded the moment the connection closes, is a poor harvesting target. The actual exposure is data whose long-term confidentiality still depends on an asymmetric key exchange performed years ago, government records, long-lived digital signatures, or intellectual property encrypted under an RSA-wrapped key that was never rotated to a post-quantum scheme.

None of this changes the guidance for symmetric ciphers specifically. Organizations planning a post-quantum migration should spend that effort on replacing RSA and ECC key exchange and signatures, not on re-keying AES-256 deployments that already meet the 256-bit requirement.

Overcoming the cons: How enterprises actually manage symmetric keys

The industry-standard answer to the key distribution problem is hybrid encryption, and it's already running under nearly every secure connection you make. TLS 1.3 uses asymmetric key exchange (typically ECDHE) to agree on a shared secret over an untrusted network without ever transmitting that secret directly, then switches to a symmetric cipher, AES-256-GCM or ChaCha20-Poly1305, for the actual session traffic. Asymmetric cryptography solves the "how do we agree on a secret without anyone overhearing it" problem once, at connection start; symmetric cryptography does the heavy lifting for everything after, because by then both sides already share the key they need.

That pattern solves distribution for a one-off session. It doesn't solve key management for data at rest or for long-lived enterprise secrets that outlive any single connection, credentials sitting in a vault for months or years, shared across a whole team. That takes deliberate, ongoing controls:

• Rotate keys on a defined schedule and immediately after any suspected compromise, not on an ad hoc basis driven by whoever remembers to do it.
• Separate duties so no single administrator can access, export, and use a key unilaterally, which limits how much damage one compromised account can do.
• Log every key access and export action, and route those logs to a security team that actually reviews them on a schedule, rather than a retention bucket nobody opens.
• Store keys in a Hardware Security Module (HSM) or an equivalent hardware-backed vault rather than in configuration files, environment variables, or a shared spreadsheet, none of which were built to keep a secret secret.
• Automate rotation and revocation instead of relying on someone remembering to do it during offboarding, since that's exactly the step that gets skipped under time pressure.

Each of these is a process fix layered on top of the algorithm, and together they treat key management as its own discipline with a defined owner, rather than something that happens by default when someone remembers.

How Passwork applies this: A key hierarchy that isolates every record

Passwork's own zero-knowledge architecture is a concrete answer to the distribution and scalability problems above. The client-side chain runs like this:

• A master password, never transmitted to the server, derives a master key through PBKDF2 with roughly 300,000 client-side iterations.
• That master key decrypts the user's RSA-2048 private key, which decrypts the keys for each vault the user has access to.
• Each vault key, in turn, unlocks the individual AES-256 key for every record inside it, and only that key decrypts the actual password or secret.

Every step in that chain happens on the client. The server only ever stores ciphertext and encrypted keys it has no way to read on its own.

The point of building it this way is blast radius. A compromised or rotated key affects one record or one vault, not the entire organization's credential estate, because there's no single master key that unlocks everything at once, no equivalent of the n(n-1)/2 pairwise-key problem described earlier.

Changing a master password only re-wraps the user's private key. It doesn't require re-encrypting every record that key can eventually reach, which is the operational difference between a rotation that takes seconds and one that takes a maintenance window. Passwork also runs an independent server-side AES-256 layer on top of this client-side chain, so compromising one encryption layer doesn't hand an attacker the other, a pattern related to but distinct from end-to-end encryption in messaging systems.

Access to a shared credential can still be revoked instantly and logged, which is what turns "who can technically decrypt this" into "who is actually still authorized to." Full implementation details live in Passwork's cryptography architecture documentation.

Symmetric encryption and compliance requirements

Most frameworks that mention encryption describe what it must accomplish, not which algorithm to use, and getting that distinction wrong leads to compliance claims that don't hold up under audit.

GDPR Article 32(1)(a) names "the pseudonymisation and encryption of personal data" as an example of an appropriate technical security measure, one option among several rather than a mandate for a specific cipher. The article leaves the implementation, including which algorithm to use, to the organization's own risk assessment.

PCI DSS v4.0 Requirement 3.5.1 requires rendering stored cardholder data unreadable through one-way hashes, truncation, index tokens, or strong cryptography with documented key-management processes, and knowing the difference between hashing and encryption matters here, since only one of those four options is reversible. It does not name AES or specify a minimum key length, so treating PCI DSS as an "AES-256 mandate", a claim that shows up in more than a few security blog posts, overstates what the standard actually says. An organization that can document its cryptography and key-management process meets the requirement regardless of which approved algorithm it runs.

The NIS2 Directive (EU) 2022/2555, Article 21, requires essential and important entities to implement risk-management measures covering their network and information systems, again without prescribing a specific algorithm. It does require that organizations be able to show what measures they took and why, which is where documented key rotation, access logging, and a defined key hierarchy stop being nice-to-haves and start being audit evidence.

The pattern across all three is consistent: regulators require strong, documented cryptography and key management, and leave the algorithm choice to the organization. That's a reason to pick AES-256 or ChaCha20-Poly1305 on their technical merits, not because a specific regulation names them.

Conclusion

None of this changes the basic verdict: the algorithm was never where symmetric encryption failed, and quantum computing doesn't move that goalpost. AES-256 still does its job at the speed enterprises need. The work that actually determines whether an organization's credentials are safe is who holds which key, how it's rotated, and how fast access disappears when someone leaves. Passwork's per-record key hierarchy, covered above, is one concrete way to keep that work from becoming unmanageable at scale.

Start by auditing which systems still manage symmetric keys manually, then move those into a structure where a single compromised key can't reach more than it has to.

Test how per-record AES-256 encryption and a structured key hierarchy hold up against your own credential sprawl. Start a free trial of Passwork — no credit card required.

FAQ: Symmetric algorithms for data security

What is zero-knowledge encryption? How it works in 5 minutes

Zero-knowledge encryption means the server never holds your decryption keys, only ciphertext. Learn how the key chain works, what it protects against, what it doesn’t, and how to verify a vendor’s claim.

PassworkPasswork Team

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

What is AES-256 encryption: Is it truly unbreakable in 2026?

AES-256 has no practical weakness — classical or quantum. The real risk is everything around it: key management, access control, and credential hygiene. Here’s what actually gets organizations breached, and what to fix first.

PassworkPasswork Team

O Passwork cifra cada cofre com a sua própria chave independente. O Bitwarden cifra uma organização inteira com uma única chave partilhada. Esta única opção de conceção determina até onde pode chegar uma credencial roubada: uma chave por cofre expõe um só cofre, ao passo que uma única chave de organização partilhada pode comprometer todos os itens corporativos da empresa.

Esta diferença determina o raio de impacto após um comprometimento, o funcionamento da recuperação de contas e a possibilidade de o incidente de uma equipa se propagar aos dados de outra. Ambas as abordagens são conceções zero-knowledge legítimas e documentadas. Têm apenas consequências operacionais diferentes, e é isso que esta comparação analisa.

Esta diferença sente-se de forma concreta numa saída de colaboradores, numa aquisição em que os cofres de duas equipas passam subitamente a exigir tratamento separado, ou numa revisão pós-incidente em que é necessário indicar exatamente o que um atacante poderia alcançar com uma única chave roubada. Mencionar isto desde o início facilita a aplicação do resto desta comparação ao ambiente próprio, seja qual for o gestor de palavras-passe utilizado atualmente.

Como o Passwork cifra os cofres

O Passwork funciona com uma arquitetura zero-knowledge: o servidor nunca dispõe de informação suficiente para decifrar os dados dos cofres e a palavra-passe mestra nunca sai do dispositivo do utilizador. Todas as chaves criptográficas são geradas do lado do cliente, pelo que o servidor armazena apenas texto cifrado e chaves públicas (visão geral de segurança, visão geral de criptografia).

Duas camadas de cifragem

O Passwork aplica duas camadas de cifragem. A cifragem do lado do servidor (AES-256) protege tudo em repouso e está sempre ativa. A cifragem do lado do cliente protege os campos sensíveis antes de saírem do dispositivo.

A hierarquia de chaves: da palavra-passe mestra à chave do cofre

O que mais importa nesta comparação é a hierarquia de chaves. Uma palavra-passe mestra deriva uma chave mestra através de PBKDF2. Essa chave mestra decifra uma chave privada RSA. A chave privada RSA decifra então uma chave de cofre: uma chave simétrica AES-256 gerada no cliente especificamente para um cofre.

Cada cofre tem a sua própria chave, gerada de forma independente no momento em que o cofre é criado. Cada utilizador com acesso possui uma cópia distinta dessa chave, cifrada com a respetiva chave pública RSA, e só a chave privada correspondente a consegue decifrar. O comprometimento da chave de um cofre não expõe a chave de nenhum outro cofre.

Isolamento abaixo do cofre: registos e anexos

O isolamento prossegue abaixo do cofre. Cada registo tem a sua própria chave de registo, cifrada com a chave do cofre, e cada ficheiro anexo tem a sua própria chave de anexo, cifrada com a chave do registo. Uma chave de registo divulgada expõe um registo, e não o cofre inteiro. Uma chave de anexo divulgada expõe um ficheiro. A chave do cofre situa-se a meio dessa cadeia, separando os registos de um cofre dos registos de todos os outros cofres, que é a camada em que esta comparação se concentra.

Partilha sem expor a chave

A partilha segue o mesmo padrão. Conceder acesso a um colega implica que o atual detentor decifre a chave do cofre com a sua própria chave privada e a volte a cifrar com a chave pública do destinatário. O servidor lida apenas com texto cifrado (mecanismos de partilha). Níveis de acesso como Ver, Editar, Acesso total e Administrador são aplicados pela aplicação, e não pela criptografia: todos os que têm acesso a um cofre possuem a mesma chave subjacente, e as permissões determinam o que a interface permite a cada pessoa fazer com ela.

Como o Bitwarden cifra os dados da organização

O Bitwarden cifra todos os dados de cofre pertencentes à organização com uma única chave partilhada: uma Organization Symmetric Key obtida a partir de um CSPRNG, gerada uma só vez para toda a organização. De acordo com o whitepaper de segurança do próprio Bitwarden, esta chave única decifra todos os itens de cofre corporativos. A própria chave, sem proteção, nunca é armazenada nos servidores do Bitwarden.

Uma chave de organização, muitas cipher keys

Os itens individuais continuam a ter a sua própria chave. Cada cipher (termo do Bitwarden para um item armazenado) tem uma Cipher Key única de 64 bytes. Essa Cipher Key é cifrada por uma User Symmetric Key pessoal ou, no caso de tudo o que pertence à organização, pela única Organization Symmetric Key. Aceder a essa chave de organização expõe de uma só vez todas as cipher keys corporativas, porque todas remontam à mesma chave principal.

As coleções controlam o acesso, não a cifragem

As coleções, o mecanismo de agrupamento do Bitwarden, assentam sobre isto sem alterar a criptografia. Uma coleção controla que membros e grupos podem ver que itens, mas não acrescenta nenhuma chave própria ao nível da coleção. Uma única chave de organização decifra o conteúdo de todas as coleções dessa organização, facto confirmado pela documentação do servidor do próprio Bitwarden. Remover alguém de uma coleção revoga o acesso por via da pertença, e não através de uma fronteira criptográfica associada a essa coleção específica.

A recuperação de contas assenta na mesma chave partilhada

A recuperação de contas segue o mesmo padrão de chave única. Quando um membro adere à funcionalidade de recuperação de contas do Bitwarden, a sua User Symmetric Key pessoal é cifrada com a chave pública RSA da organização, formando aquilo a que o Bitwarden chama Account Recovery Key. Para recuperar um membro bloqueado, a chave privada RSA da organização decifra essa Account Recovery Key e obtém a chave de cifragem pessoal do membro. Um único administrador com a permissão Manage account recovery (gerir a recuperação de contas) pode fazê-lo para qualquer membro inscrito.

Políticas de cofre vs coleções

O Passwork distingue os cofres por tipo, e não apenas por proprietário. A documentação define dois tipos básicos de cofre: cofres da empresa, armazenamento partilhado com direitos de acesso configuráveis para uma equipa, e cofres pessoais, armazenamento criado por um único utilizador e que inicialmente lhe pertence.

Ambos os tipos recebem o mesmo tratamento de chave por cofre, pelo que um cofre pessoal está tão isolado criptograficamente de um cofre da empresa como dois cofres da empresa quaisquer estão entre si.

Os cofres pessoais podem tornar-se cofres partilhados

Um cofre pessoal não fica bloqueado a uma só pessoa de forma permanente. O proprietário pode partilhá-lo com colegas e, nesse momento, passa a funcionar como um cofre partilhado, com o acesso regido da mesma forma que qualquer outro cofre partilhado no Passwork.

Tipos de cofre personalizados e atribuição obrigatória de administradores

O Passwork permite ainda que os administradores definam um número ilimitado de tipos de cofre personalizados, cada um com o seu próprio conjunto de administradores designados e as suas próprias regras de acesso. Isto permite a uma organização impor, por exemplo, um grupo de administradores para os cofres de finanças e outro diferente para os cofres de engenharia, sem depender de atribuições de permissões ad hoc a posteriori.

Os administradores podem também desativar por completo a criação de cofres pessoais, forçando todos os dados a ficarem em cofres da empresa ou em tipos de cofre personalizados, onde a atribuição de administradores é obrigatória.

Como isto se compara às coleções e às Enterprise Policies do Bitwarden

O Bitwarden não tem uma abstração equivalente de cofres por tipo. O seu análogo mais próximo, as coleções, agrupa itens dentro de uma organização, mas não os isola criptograficamente: como referido anteriormente, uma única Organization Symmetric Key decifra o conteúdo de todas as coleções, e remover um membro de uma coleção revoga o acesso por via da pertença, e não através de uma fronteira de chave separada. As coleções também não têm o conceito de um conjunto dedicado de administradores, como têm os tipos de cofre da empresa e personalizados do Passwork.

As Enterprise Policies do Bitwarden funcionam numa camada completamente diferente. Políticas como Single organization, Centralize organization ownership, Master password requirements, Require two-step login e Account recovery administration aplicam-se a toda a organização, e não por coleção ou por tipo de cofre (documentação de políticas do Bitwarden). Um administrador que aplique uma política de robustez da palavra-passe mestra, por exemplo, define uma regra para toda a organização. Não existe um equivalente por coleção ou por tipo de cofre que permita delimitar essa regra de forma mais restrita.

A diferença prática

As políticas de cofre do Passwork dão ao administrador uma forma estrutural de separar os dados individuais dos dados de equipa, atribuir administradores responsáveis por tipo e manter cada instância de qualquer dos tipos com a sua própria chave. As coleções do Bitwarden organizam o acesso dentro de uma única chave partilhada, e as respetivas políticas configuram o comportamento numa organização que já partilha essa chave, independentemente da coleção ou do tipo de dados a que uma determinada política se destina.

O que isto significa na prática

A arquitetura de chaves de cada produto origina quatro diferenças operacionais concretas: o raio de impacto após um comprometimento, a facilidade com que as equipas podem ser isoladas, o funcionamento da recuperação e a forma como uma auditoria responde a «o que poderia esta credencial decifrar».

Raio de impacto de um único segredo comprometido

No Passwork, uma chave de cofre divulgada, uma chave privada RSA divulgada ou uma palavra-passe mestra comprometida limita o atacante a um cofre ou aos cofres partilhados desse utilizador, e não à organização inteira. No Bitwarden, como todas as cipher keys corporativas remontam a uma única Organization Symmetric Key, o comprometimento dessa chave expõe todos os itens de cofre da organização.

Isolamento entre várias equipas

Uma organização com várias equipas no Passwork pode atribuir a cada equipa o seu próprio cofre, cada um com a sua própria chave, pelo que um incidente no cofre de uma equipa não tem nenhum caminho criptográfico para o cofre de outra. No Bitwarden, as equipas são tipicamente separadas por coleções dentro da mesma organização, o que é controlo de acesso sobreposto a uma única chave de organização partilhada.

Modelo de recuperação

O processo de recuperação do Passwork não restaura a chave mestra original. Estabelece uma nova, e o utilizador mantém acesso apenas aos cofres cujo acesso já tinha sido partilhado antes com outra conta. A recuperação de contas do Bitwarden assenta num único par de chaves RSA da organização, pelo que um administrador com a permissão adequada pode recuperar qualquer membro inscrito sem que esse membro tenha partilhado previamente o que quer que seja (documentação de recuperação de contas). Isto é operacionalmente cómodo. Significa também que a chave privada RSA de recuperação da organização é um ponto único de exposição para o cofre de todos os membros inscritos.

Âmbito de auditoria e conformidade

Quando um auditor pergunta «o que poderia esta credencial decifrar», o modelo por cofre do Passwork dá uma resposta curta e específica: um cofre, ou uma lista nomeada de cofres a que esse utilizador tinha acesso. No modelo de chave única de organização do Bitwarden, a resposta honesta à mesma pergunta é «tudo o que a organização possui», porque não existe subdivisão criptográfica abaixo do nível da organização a que se possa apontar. Nenhuma das respostas está errada, mas documentam-se de forma muito diferente num pacote de evidências de auditoria.

Tabela comparativa

A tabela seguinte resume onde as duas arquiteturas divergem, desde a chave raiz até à partilha e à recuperação.

Passar à prática

A questão não é saber qual dos fornecedores tem a melhor criptografia em abstrato. É saber se os dados necessitam realmente de isolamento por chave única ou por cofre. As equipas que tratam segredos sujeitos a requisitos regulamentares, a infraestrutura de um cliente específico ou uma fronteira de conformidade que tem de permanecer separada beneficiam diretamente de chaves por cofre. As equipas em que todos já partilham plena confiança mútua beneficiam menos do isolamento adicional.

Ambas as arquiteturas são consideradas zero-knowledge. A diferença está no que uma única chave roubada pode alcançar depois: um cofre ou a organização inteira. Esse é o ponto a confrontar com o modelo de risco próprio antes da próxima revisão de segurança.

Pretende ver o isolamento de chaves por cofre nos seus próprios dados antes de decidir? Experimente o Passwork gratuitamente e verifique como os tipos de cofre, a atribuição de administradores e as fronteiras de chaves resistem à sua própria revisão de segurança.

Perguntas frequentes

Gestão de credenciais SaaS: 5 passos para centralizar o conjunto de aplicações

A gestão de credenciais SaaS transforma palavras-passe e chaves de API dispersas num único inventário que pode ser partilhado de forma intencional e revogado à saída. Eis o modelo de cinco passos: inventário, estrutura, migração, controlo de acesso e automatização.

PassworkPasswork Team

Verizon DBIR 2026: 10 estatísticas que deveriam mudar a estratégia de segurança

O DBIR 2026 da Verizon analisou mais de 22 000 violações em 145 países. A exploração de vulnerabilidades ultrapassou o abuso de credenciais como principal vetor de ataque, enquanto o ransomware, o risco de terceiros e os ataques assistidos por IA cresceram acentuadamente. Estes são os 10 números que importam.

PassworkAlex Muntyan

Políticas de cofre do Passwork: guia do CIO para a segurança empresarial

Os tipos de cofre do Passwork associam os direitos de administração à própria política do cofre, e não a quem o criou, eliminando uma lacuna que a maioria das empresas nem sabe que existe. Este guia dá aos CIOs e CISOs um modelo de trabalho para a governação de cofres, mapeado para os requisitos da NIS2 e da ISO 27001.

PassworkPasswork Team

Passwork verschlüsselt jeden Tresor mit einem eigenen unabhängigen Schlüssel. Bitwarden verschlüsselt eine gesamte Organisation mit einem gemeinsamen Schlüssel. Diese einzelne Designentscheidung bestimmt, wie weit gestohlene Anmeldedaten reichen können: Ein Tresor-spezifischer Schlüssel legt nur einen Tresor offen, während ein einzelner gemeinsamer Organisationsschlüssel potenziell alle Unternehmensdaten kompromittieren kann.

Dieser Unterschied bestimmt den Schadensradius nach einer Kompromittierung, wie die Kontowiederherstellung funktioniert und ob ein Vorfall in einem Team sich auf die Daten eines anderen Teams ausbreiten kann. Beide Ansätze sind dokumentierte, legitime Zero-Knowledge-Designs. Sie haben lediglich unterschiedliche betriebliche Konsequenzen, und genau das behandelt dieser Vergleich.

Dieser Unterschied wird konkret spürbar beim Offboarding, bei einer Übernahme, bei der die Tresore zweier Teams plötzlich getrennt behandelt werden müssen, oder bei einer Post-Incident-Analyse, bei der genau angegeben werden muss, was ein Angreifer mit einem gestohlenen Schlüssel erreichen konnte. Dies vorab zu klären, macht den Rest dieses Vergleichs leichter auf Ihre eigene Umgebung anwendbar — unabhängig davon, welchen Passwort-Manager Sie heute verwenden.

Wie Passwork Tresore verschlüsselt

Passwork basiert auf einer Zero-Knowledge-Architektur: Der Server verfügt nie über genügend Informationen, um Tresordaten zu entschlüsseln, und das Masterpasswort verlässt nie das Gerät des Benutzers. Jeder kryptografische Schlüssel wird clientseitig generiert, sodass der Server nur Chiffretext und öffentliche Schlüssel speichert (Sicherheitsübersicht, Kryptografie-Übersicht).

Zwei Verschlüsselungsebenen

Passwork verwendet zwei Verschlüsselungsebenen. Die serverseitige Verschlüsselung (AES-256) schützt alles im Ruhezustand und ist immer aktiv. Die clientseitige Verschlüsselung schützt sensible Felder, bevor sie das Gerät verlassen.

Die Schlüsselhierarchie: Vom Masterpasswort zum Tresorschlüssel

Für diesen Vergleich ist die Schlüsselhierarchie am wichtigsten. Ein Masterpasswort leitet über PBKDF2 einen Master-Schlüssel ab. Dieser Master-Schlüssel entschlüsselt einen privaten RSA-Schlüssel. Der private RSA-Schlüssel entschlüsselt dann einen Tresorschlüssel: einen symmetrischen AES-256-Schlüssel, der clientseitig speziell für einen Tresor generiert wird.

Jeder Tresor erhält seinen eigenen Tresorschlüssel, der unabhängig bei der Erstellung des Tresors generiert wird. Jeder Benutzer mit Zugang besitzt eine separate verschlüsselte Kopie dieses Schlüssels, die mit seinem eigenen öffentlichen RSA-Schlüssel umschlossen ist — nur der passende private Schlüssel kann sie entschlüsseln. Die Kompromittierung eines Tresorschlüssels legt den Schlüssel keines anderen Tresors offen.

Isolation unterhalb des Tresors: Einträge und Anhänge

Die Isolation setzt sich unterhalb des Tresors fort. Jeder Eintrag erhält seinen eigenen Eintragsschlüssel, der mit dem Tresorschlüssel verschlüsselt ist, und jeder Dateianhang erhält seinen eigenen Anhangsschlüssel, der mit dem Eintragsschlüssel verschlüsselt ist. Ein geleakter Eintragsschlüssel legt einen Eintrag offen, nicht den gesamten Tresor. Ein geleakter Anhangsschlüssel legt eine Datei offen. Der Tresorschlüssel befindet sich in der Mitte dieser Kette und trennt die Einträge eines Tresors von denen aller anderen Tresore — das ist die Ebene, auf die sich dieser Vergleich konzentriert.

Teilen ohne Offenlegung des Schlüssels

Das Teilen folgt demselben Muster. Einem Kollegen Zugang zu gewähren bedeutet, dass der aktuelle Inhaber den Tresorschlüssel mit seinem eigenen privaten Schlüssel entschlüsselt und ihn mit dem öffentlichen Schlüssel des Empfängers erneut verschlüsselt. Der Server verarbeitet ausschließlich Chiffretext (Sharing-Mechanismen). Zugangsstufen wie Nur Lesen, Lesen und Bearbeiten, Vollständiger Zugang und Administrator werden von der Anwendung durchgesetzt, nicht durch die Kryptografie: Jeder mit Zugang zu einem Tresor besitzt denselben zugrundeliegenden Schlüssel, und die Berechtigungen steuern, was die Oberfläche jeder Person damit erlaubt.

Wie Bitwarden Organisationsdaten verschlüsselt

Bitwarden verschlüsselt alle organisationseigenen Tresordaten mit einem gemeinsamen Schlüssel: einem CSPRNG-abgeleiteten Organization Symmetric Key, der einmalig für die gesamte Organisation generiert wird. Laut Bitwardens eigenem Security-Whitepaper entschlüsselt dieser einzelne Schlüssel jedes Unternehmens-Tresorelement. Der ungeschützte Schlüssel selbst wird nie auf Bitwardens Servern gespeichert.

Ein Organisationsschlüssel, viele Cipher Keys

Einzelne Elemente erhalten weiterhin ihren eigenen Schlüssel. Jeder Cipher (Bitwardens Begriff für ein gespeichertes Element) hat einen einzigartigen 64-Byte Cipher Key. Dieser Cipher Key wird entweder mit einem persönlichen User Symmetric Key oder — für alles, was der Organisation gehört — mit dem einzelnen Organization Symmetric Key umschlossen. Das Entschlüsseln dieses einen Organisationsschlüssels legt alle Unternehmens-Cipher-Keys auf einmal offen, da sie alle auf denselben übergeordneten Schlüssel zurückgehen.

Collections steuern Zugang, nicht Verschlüsselung

Collections, Bitwardens Gruppierungsmechanismus, setzen darauf auf, ohne die Kryptografie zu ändern. Eine Collection steuert, welche Mitglieder und Gruppen welche Elemente sehen können, fügt aber keinen separaten Collection-spezifischen Schlüssel hinzu. Ein einzelner Organisationsschlüssel entschlüsselt den Inhalt jeder Collection dieser Organisation — ein Punkt, der sowohl durch Bitwardens eigene Server-Dokumentation bestätigt wird. Das Entfernen einer Person aus einer Collection widerruft den Zugang über die Mitgliedschaft, nicht durch eine kryptografische Grenze, die an diese spezifische Collection gebunden ist.

Kontowiederherstellung basiert auf demselben gemeinsamen Schlüssel

Die Kontowiederherstellung folgt demselben Einzelschlüssel-Muster. Wenn sich ein Mitglied für Bitwardens Kontowiederherstellungsfunktion registriert, wird sein persönlicher User Symmetric Key mit dem öffentlichen RSA-Schlüssel der Organisation umschlossen — das ergibt den sogenannten Account Recovery Key. Um ein gesperrtes Mitglied wiederherzustellen, entschlüsselt der private RSA-Schlüssel der Organisation diesen Account Recovery Key und gibt den persönlichen Verschlüsselungsschlüssel des Mitglieds frei. Ein einzelner Admin mit der Berechtigung „Manage account recovery" kann dies für jedes registrierte Mitglied durchführen.

Tresorrichtlinien vs. Collections

Passwork unterscheidet Tresore nach Typ, nicht nur nach Eigentümer. Die Dokumentation definiert zwei grundlegende Tresortypen: Unternehmenstresore, gemeinsamer Speicher mit konfigurierbaren Zugriffsrechten für ein Team, und Persönliche Tresore, Speicher, der von einem einzelnen Benutzer erstellt wird und diesem zunächst gehört.

Beide Typen erhalten die identische Tresor-spezifische Schlüsselbehandlung, sodass ein Persönlicher Tresor genauso kryptografisch vom Unternehmens-Tresor isoliert ist wie zwei Unternehmenstresore voneinander.

Persönliche Tresore können zu geteilten Tresoren werden

Ein Persönlicher Tresor ist nicht dauerhaft an eine Person gebunden. Der Eigentümer kann ihn mit Kollegen teilen, und ab diesem Zeitpunkt funktioniert er wie ein geteilter Tresor — mit derselben Zugangssteuerung wie jeder andere geteilte Tresor in Passwork.

Benutzerdefinierte Tresortypen und obligatorische Admin-Zuweisung

Passwork ermöglicht Administratoren außerdem, eine unbegrenzte Anzahl benutzerdefinierter Tresortypen zu definieren, jeweils mit eigenen designierten Administratoren und eigenen Zugriffsregeln. Das gibt einer Organisation die Möglichkeit, beispielsweise eine Admin-Gruppe für Finanztresore und eine andere für Engineering-Tresore festzulegen — ohne sich auf nachträgliche Ad-hoc-Berechtigungszuweisungen verlassen zu müssen.

Administratoren können auch die Erstellung Persönlicher Tresore vollständig deaktivieren und alle Daten in Unternehmens- oder benutzerdefinierte Tresortypen zwingen, bei denen die Admin-Zuweisung obligatorisch ist.

Wie sich das mit Bitwarden Collections und Enterprise Policies vergleicht

Bitwarden hat keine vergleichbare Tresortypen-Abstraktion. Die nächste Entsprechung — Collections — gruppiert Elemente innerhalb einer Organisation, isoliert sie aber nicht kryptografisch: Wie bereits behandelt, entschlüsselt ein einzelner Organization Symmetric Key den Inhalt jeder Collection, und das Entfernen eines Mitglieds aus einer Collection widerruft den Zugang über die Mitgliedschaft, nicht durch eine separate Schlüsselgrenze. Collections haben auch kein Konzept eines dedizierten Administrator-Sets, wie es Passworks Unternehmens- und benutzerdefinierte Tresortypen bieten.

Bitwardens Enterprise Policies arbeiten auf einer völlig anderen Ebene. Richtlinien wie „Single organization", „Centralize organization ownership", „Master password requirements", „Require two-step login" und „Account recovery administration" gelten organisationsweit, nicht pro Collection oder Tresortyp (Bitwarden-Richtliniendokumentation). Ein Administrator, der eine Masterpasswort-Stärkerichtlinie anwendet, legt beispielsweise eine Regel für die gesamte Organisation fest. Es gibt keine Collection- oder Tresortyp-spezifische Entsprechung, um diese Regel enger einzugrenzen.

Der praktische Unterschied

Passworks Tresorrichtlinien bieten Administratoren eine strukturelle Möglichkeit, individuelle Daten von Teamdaten zu trennen, verantwortliche Admins pro Typ zuzuweisen und jede Instanz beider Typen auf ihrem eigenen Schlüssel zu halten. Bitwardens Collections organisieren den Zugang innerhalb eines einzelnen gemeinsamen Schlüssels, und seine Richtlinien konfigurieren Verhalten über eine Organisation, die diesen Schlüssel bereits teilt — unabhängig davon, welche Collection oder welchen Datentyp eine bestimmte Richtlinie adressiert.

Was das in der Praxis bedeutet

Die Schlüsselarchitektur hinter jedem Produkt führt zu vier konkreten betrieblichen Unterschieden: Schadensradius nach einer Kompromittierung, wie sauber Teams isoliert werden können, wie die Wiederherstellung funktioniert und wie ein Audit die Frage „Was konnte diese Anmeldedaten entschlüsseln?" beantwortet.

Schadensradius eines einzelnen kompromittierten Geheimnisses

Bei Passwork beschränkt ein geleakter Tresorschlüssel, ein geleakter privater RSA-Schlüssel oder ein kompromittiertes Masterpasswort einen Angreifer auf einen Tresor oder auf die geteilten Tresore dieses einen Benutzers — nicht auf die gesamte Organisation. Bei Bitwarden legt die Kompromittierung des Organization Symmetric Key jedes Tresorelement offen, das der Organisation gehört, da jeder Unternehmens-Cipher-Key auf diesen einen Schlüssel zurückgeht.

Multi-Team-Isolation

Eine Organisation, die mehrere Teams in Passwork betreibt, kann jedem Team seinen eigenen Tresor mit eigenem Schlüssel geben, sodass ein Vorfall im Tresor eines Teams keinen kryptografischen Pfad in den Tresor eines anderen Teams hat. Bei Bitwarden werden Teams typischerweise mit Collections innerhalb derselben Organisation getrennt — das ist Zugangskontrolle, die auf einem gemeinsamen Organisationsschlüssel aufbaut.

Wiederherstellungsmodell

Der Wiederherstellungsprozess von Passwork stellt nicht den ursprünglichen Master-Schlüssel wieder her. Es wird ein neuer erstellt, und ein Benutzer behält nur Zugang zu Tresoren, bei denen der Zugang zuvor bereits mit einem anderen Konto geteilt wurde. Bitwardens Kontowiederherstellung basiert auf einem einzigen RSA-Schlüsselpaar der Organisation, sodass ein Admin mit der entsprechenden Berechtigung jedes registrierte Mitglied wiederherstellen kann, ohne dass dieses Mitglied zuvor etwas geteilt haben muss (Kontowiederherstellungs-Dokumentation). Das ist betrieblich praktisch. Es bedeutet aber auch, dass der private Recovery-RSA-Schlüssel der Organisation ein einzelner Expositionspunkt für den Tresor jedes registrierten Mitglieds ist.

Audit- und Compliance-Scoping

Wenn ein Auditor fragt „Was konnte diese Anmeldedaten entschlüsseln?", liefert Passworks Tresor-spezifisches Modell eine kurze, präzise Antwort: einen Tresor oder eine benannte Liste von Tresoren, auf die dieser Benutzer Zugriff hatte. Bei Bitwardens Einzelorganisationsschlüssel-Modell lautet die ehrliche Antwort auf dieselbe Frage „Alles, was der Organisation gehört", da es keine kryptografische Unterteilung unterhalb der Organisationsebene gibt. Keine der Antworten ist falsch, aber sie dokumentieren sich in einem Audit-Evidenzpaket sehr unterschiedlich.

Vergleichstabelle

Die folgende Tabelle fasst zusammen, wo die beiden Architekturen divergieren — vom Root-Schlüssel bis zu Sharing und Wiederherstellung.

Praktische Überlegungen

Die Frage ist nicht, welche Kryptografie des Anbieters abstrakt besser ist. Es geht darum, ob Ihre Daten tatsächlich Einzelschlüssel- oder Tresor-spezifische Isolation benötigen. Teams, die regulatorisch relevante Geheimnisse, die Infrastruktur eines bestimmten Kunden oder eine Compliance-Grenze verwalten, die getrennt bleiben muss, profitieren direkt von Tresor-spezifischen Schlüsseln. Teams, in denen bereits vollständiges gegenseitiges Vertrauen herrscht, profitieren weniger von der zusätzlichen Isolation.

Beide Architekturen qualifizieren sich als Zero-Knowledge. Der Unterschied liegt darin, was ein einzelner gestohlener Schlüssel danach erreichen kann: einen Tresor oder die gesamte Organisation. Das ist die Zahl, die Sie vor Ihrer nächsten Sicherheitsüberprüfung mit Ihrem eigenen Risikomodell abgleichen sollten.

Möchten Sie die Tresor-spezifische Schlüsselisolation mit Ihren eigenen Daten testen, bevor Sie sich entscheiden? Testen Sie Passwork kostenlos und prüfen Sie, wie Tresortypen, Admin-Zuweisung und Schlüsselgrenzen Ihrer eigenen Sicherheitsüberprüfung standhalten.

Häufig gestellte Fragen

SaaS-Credential-Management: 5 Schritte zur Zentralisierung Ihres App-Stacks

SaaS-Credential-Management verwandelt verstreute Passwörter und API-Schlüssel in ein Inventar, das Sie gezielt teilen und beim Ausscheiden widerrufen können. Hier ist das Fünf-Schritte-Framework: Inventarisierung, Strukturierung, Migration, Zugangskontrolle und Automatisierung.

PassworkPasswork Team

Verizon DBIR 2026: 10 Statistiken, die Ihre Sicherheitsstrategie ändern sollten

Verizons DBIR 2026 analysierte über 22.000 Datenschutzverletzungen in 145 Ländern. Die Ausnutzung von Schwachstellen überholte den Credential-Missbrauch als häufigsten Angriffsvektor, während Ransomware, Drittanbieter-Risiken und KI-gestützte Angriffe stark zunahmen. Hier sind die 10 Zahlen, die zählen.

PassworkAlex Muntyan

Passworks Tresorrichtlinien: Ein Leitfaden für CIOs zur Unternehmenssicherheit

Passworks Tresortypen binden Admin-Rechte an die Tresorrichtlinie selbst, nicht an denjenigen, der sie erstellt hat — und schließen damit eine Lücke, von der die meisten Unternehmen nicht einmal wissen. Dieser Leitfaden bietet CIOs und CISOs ein Arbeitsmodell für Tresor-Governance, abgestimmt auf NIS2- und ISO-27001-Anforderungen.

PassworkPasswork Team