Em junho de 2026, três acontecimentos relançaram o debate sobre as garantias reais dos gestores «zero-knowledge»: um estudo académico da ETH Zurich e da Aalto University cartografa 25 ataques exploráveis se o servidor estiver comprometido, uma fuga de dados na LastPass transita por um CRM de terceiros, e um investigador da DEF CON 33 demonstra o desvio do autofill por clickjacking. Eis o impacto concreto destes três acontecimentos na arquitetura de ARDNTECH, sem retórica de marketing.
Publicado a 23 de junho de 2026 por ARDNTECH EI · Análise interna a partir das divulgações públicas
Um roubo de tokens OAuth na Klue (ferramenta de inteligência comercial integrada no Salesforce) permitiu aceder aos dados de contacto de clientes da LastPass. Os cofres cifrados não foram expostos. O risco real é o phishing direcionado a partir de uma lista de contactos roubada num subcontratante periférico, não o comprometimento do núcleo criptográfico.
Ensinamento : o zero-knowledge protege os cofres, não os metadados detidos por terceiros.
Matteo Scarlata e os seus coautores (divulgados pela Ars Technica) cartografam 25 ataques que mostram que as garantias «zero-knowledge» da Bitwarden, Dashlane e LastPass se degradam se o servidor estiver comprometido e se certas funcionalidades opt-in estiverem ativas: recuperação de conta, partilha através de distribuição de chaves públicas, retrocompatibilidade criptográfica (downgrade KDF).
Ensinamento : um ZK formalmente correto deve resistir ao cenário de um servidor comprometido, não apenas a um administrador honesto.
Marek Tóth demonstra que o autofill de 11 gestores pode ser despoletado por um overlay invisível. Um único clique num falso banner de cookies basta para preencher os campos de uma página controlada pelo atacante. A superfície atingida é a lógica de injeção DOM da extensão, não o cofre do servidor.
Ensinamento : a extensão de navegador é uma superfície de ataque distinta do servidor, a endurecer de forma independente.
O estudo visa três famílias de funcionalidades que, num servidor comprometido, enfraquecem as garantias ZK. Eis a sua correspondência na arquitetura de ARDNTECH.
| Vetor do estudo | Arquitetura de ARDNTECH | Veredito |
|---|---|---|
|
Recuperação de conta
Cópia da chave do cofre armazenada do lado do servidor, utilizável se o servidor estiver comprometido |
O wrap é produzido do lado do cliente (Argon2id) a partir de um código de recuperação que apenas o utilizador detém. O servidor armazena wraps opacos: não pode voltar a derivar a chave. Consumo com scrub imediato. | São |
|
Downgrade criptográfico
Forçar um cliente a usar um algoritmo mais fraco durante o wrap de recuperação |
Bloqueado do lado do servidor: um componente de inspeção analisa a armadura real (SKESK v6, S2K Argon2id, AEAD presente, custos mínimos). Um cliente adulterado que faça downgrade é rejeitado e obrigado a uma reativação. | Neutralizado |
|
Substituição de chave pública na partilha
O servidor serve a sua própria chave em vez da do destinatário |
O servidor expõe a chave pública + a impressão digital do destinatário. Uma correção de junho de 2026 (repo de extensões) cobre a verificação do lado do cliente. Ponto residual: garantir que uma mudança de chave de um contacto conhecido despoleta um alerta explícito. | Em verificação |
|
Chaves de recuperação de administrador (tipo LastPass)
Um administrador de grupo pode voltar a cifrar o cofre de um utilizador do lado do servidor |
ARDNTECH não dispõe de um mecanismo «break-glass admin» do lado do servidor que voltasse a cifrar a chave do cofre de um utilizador para uma chave de administrador. A partilha de equipa passa unicamente pela chave pública da equipa e a sua impressão digital. | São por conceção |
Síntese : um servidor ARDNTECH comprometido não permite decifrar os wraps de recuperação: são opacos, derivados do lado do cliente a partir de um segredo que o servidor não detém, e o downgrade KDF é recusado no registo. São precisamente os cenários explorados noutros gestores pelo estudo ETH/Aalto. Aqui estão fechados através de escolhas arquiteturais documentadas no modelo de ameaças.
A investigação de Tóth visa a lógica de injeção DOM das extensões. O autofill e o autologin são as superfícies afetadas. O cofre do servidor não está em causa: é a extensão que preenche os campos que pode ser enganada. Os pontos seguintes estão em curso de auditoria na extensão de ARDNTECH.
visibility:hidden, tamanho próximo de zero ou elemento coberto (hit-testing do ponto de clique).window.top === window.self ou de mesma origem.z-index controlado, reverificação de visibilidade no momento do clique.Um núcleo criptográfico são pode ser contornado pela stack SaaS periférica. Os cofres LastPass não se moveram, mas uma lista de contactos foi roubada num integrador CRM de terceiros.
Os subcontratantes atuais de ARDNTECH (Scaleway, Brevo, Stancer, HIBP, Bugsink) estão enquadrados no registo publicado na página Confiança. O zero-knowledge protege os cofres, não uma lista de contactos num CRM de terceiros não inventariado.
Rotação dos tokens de integrações de terceiros, scopes mínimos, revogação imediata em caso de incidente. Os acessos aos sistemas periféricos não devem permitir reconstituir uma cartografia dos clientes.
Zero-knowledge verificável, alojado em França, código-fonte AGPLv3. A beta privada é acessível mediante inscrição.