A autenticação baseada em palavras-passe continua a ser o método dominante para autenticação na web, apesar dos seus desafios de segurança bem documentados. Os utilizadores enfrentam uma carga cognitiva ao gerir múltiplas palavras-passe fortes, o que leva à reutilização e à criação de palavras-passe fracas. Os gestores de palavras-passe prometem aliviar estes problemas, gerando, armazenando e preenchendo automaticamente palavras-passe. No entanto, a sua segurança tem sido questionada por investigações anteriores. Este artigo apresenta uma avaliação de segurança atualizada e abrangente de treze gestores de palavras-passe populares baseados no navegador, examinando todo o ciclo de vida: geração, armazenamento e preenchimento automático.
Avaliámos treze gestores de palavras-passe, incluindo cinco extensões de navegador (por exemplo, LastPass, Dashlane), seis gestores integrados no navegador (por exemplo, Chrome, Firefox) e dois clientes de desktop para comparação. A estrutura de avaliação abrangeu três fases principais: análise da aleatoriedade de 147 milhões de palavras-passe geradas, avaliação da segurança do armazenamento (encriptação, tratamento de metadados, configurações padrão) e testes de vulnerabilidades do preenchimento automático contra ataques como clickjacking e XSS.
Esta secção detalha a primeira análise em larga escala dos algoritmos de geração de palavras-passe em gestores de palavras-passe.
Empregámos testes estatísticos para aleatoriedade, incluindo análise de frequência, cálculo de entropia e testes para distribuição uniforme nos conjuntos de caracteres definidos (maiúsculas, minúsculas, dígitos, símbolos).
Vários gestores exibiram distribuições de caracteres não aleatórias. Por exemplo, alguns mostraram tendência para certas posições ou conjuntos de caracteres, reduzindo a entropia efetiva das palavras-passe geradas abaixo das expectativas teóricas.
Uma descoberta significativa foi que um subconjunto de palavras-passe geradas—particularmente aquelas com menos de 10 caracteres—era vulnerável a ataques de força bruta online. Palavras-passe com menos de 18 caracteres revelaram-se potencialmente vulneráveis a ataques offline, assumindo as capacidades do hardware moderno.
Replicando e estendendo trabalhos anteriores de Li et al., avaliamos como as palavras-passe são encriptadas e armazenadas localmente e na nuvem.
Embora a maioria dos gestores use encriptação forte (por exemplo, AES-256), as funções de derivação de chaves e os mecanismos de armazenamento de chaves variaram, com algumas implementações sendo mais fracas do que outras.
Uma falha crítica identificada foi o armazenamento de metadados sensíveis (por exemplo, URLs de sites, nomes de utilizador) em texto simples ou com proteção insuficiente, criando um risco de privacidade mesmo que a própria palavra-passe esteja encriptada.
Vários gestores de palavras-passe tinham configurações padrão inseguras, como ativar o preenchimento automático ou não exigir a palavra-passe mestra ao reiniciar o navegador, aumentando a superfície de ataque.
O preenchimento automático, embora conveniente, introduz vetores de ataque significativos. Testámos contra classes de exploração conhecidas.
Descobrimos que vários gestores permaneciam vulneráveis a ataques de clickjacking, onde um site malicioso sobrepõe elementos invisíveis sobre botões legítimos da interface para enganar os utilizadores e ativar o preenchimento automático num campo controlado pelo atacante.
Se um site tiver uma vulnerabilidade XSS, um script injetado poderia potencialmente interagir com os elementos DOM do gestor de palavras-passe para exfiltrar credenciais, um risco destacado em trabalhos anteriores de Stock e Johns.
Gestores que comunicam com serviços na nuvem para sincronização ou funcionalidades foram testados quanto à suscetibilidade a ataques man-in-the-middle que poderiam injetar código malicioso ou roubar tokens de autenticação.
No geral, a segurança melhorou em comparação com avaliações de há cinco anos, mas problemas significativos persistem. Nenhum gestor individual foi impecável em todas as três categorias (geração, armazenamento, preenchimento automático). Os gestores integrados no navegador frequentemente tinham uma lógica de preenchimento automático mais simples e segura, mas algoritmos de geração mais fracos. As extensões de terceiros ofereciam mais funcionalidades, mas introduziam maior complexidade e superfície de ataque. Identificamos gestores específicos com desempenho fraco que devem ser evitados por utilizadores conscientes da segurança.
13
147M+
4
Para Utilizadores: Escolham gestores com um histórico de segurança forte, ativem todas as funcionalidades de segurança disponíveis (como 2FA) e sejam cautelosos com o preenchimento automático. Para Programadores: Implementem geradores de números aleatórios criptograficamente seguros (CSPRNGs) para geração de palavras-passe, encriptem todos os metadados, adotem configurações padrão seguras (por exemplo, exigir sempre a palavra-passe mestra) e reforcem o preenchimento automático contra manipulação da interface. Para Investigadores: Explorem o compromisso entre usabilidade e segurança do preenchimento automático, desenvolvam estruturas de avaliação de segurança padronizadas e investiguem criptografia pós-quântica para garantir a segurança futura.
Ideia Central: O estudo de Oesch e Ruoti apresenta uma verificação da realidade sóbria: as próprias ferramentas concebidas para resolver a crise das palavras-passe são elas próprias um mosaico de vulnerabilidades. O foco da indústria na conveniência e na proliferação de funcionalidades, em vários casos, prejudicou diretamente as promessas de segurança fundamentais. A descoberta de que palavras-passe geradas podem ser fracas é particularmente condenatória—atinge o cerne da proposta de valor do gestor de palavras-passe.
Fluxo Lógico: O artigo estrutura brilhantemente o seu ataque ao longo da jornada do utilizador: criação (geração), em repouso (armazenamento) e em uso (preenchimento automático). Esta abordagem de ciclo de vida, que recorda a modelação de ameaças em estruturas como a STRIDE da Microsoft, revela que as fraquezas não são isoladas, mas sistémicas. Uma falha na geração reduz a eficácia de um armazenamento forte; uma falha no preenchimento automático anula ambas. Esta interconexão é frequentemente ignorada em auditorias pontuais.
Pontos Fortes e Fracos: O ponto forte do estudo é a sua abrangência e replicação de trabalhos anteriores, fornecendo uma rara visão longitudinal da evolução da segurança. O corpus massivo de 147 milhões de palavras-passe geradas para análise é louvável. No entanto, a análise tem uma falha comum a muitas avaliações de segurança: é maioritariamente um teste funcional de caixa preta. Identifica o que está quebrado, mas fornece menos perceção sobre porquê de uma perspetiva de engenharia de software—estas falhas foram devidas a prazos apertados, especificações mal compreendidas ou falta de revisão de segurança? Além disso, embora faça referência às Diretrizes de Identidade Digital do NIST, uma análise mais profunda de como estes gestores se alinham (ou não) com normas como a FIPS 140-3 ou os requisitos de segurança delineados nas propostas do IETF para Password Authenticated Key Exchange (PAKE) teria acrescentado peso significativo.
Perceções Acionáveis: Para equipas de segurança empresarial, este artigo é um mandato para examinar rigorosamente os gestores de palavras-passe aprovados. Confiar na reputação da marca é insuficiente. As listas de verificação de aquisição devem incluir testes específicos para aleatoriedade na geração (por exemplo, usando conjuntos de testes padronizados como Dieharder ou STS do NIST), encriptação de metadados e comportamento do preenchimento automático sob simulações de ataque. Para programadores, a lição é priorizar a simplicidade e configurações padrão seguras. O mecanismo de preenchimento automático mais seguro pode ser o mais simples: um "clique para preencher" manual que requer uma ação explícita e consciente do utilizador, como sugerido pela investigação da Universidade da Califórnia, Berkeley sobre interfaces de consentimento explícito. O futuro não está em tentar tornar o preenchimento automático inteligente perfeitamente seguro, mas em conceber interações do utilizador minimamente intrusivas, mas maximamente explícitas, que mantenham o humano no circuito para decisões críticas de segurança.
A avaliação da aleatoriedade na geração de palavras-passe baseou-se no cálculo da entropia de Shannon $H$ das palavras-passe geradas:
$H = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)$
onde $P(x_i)$ é a probabilidade do carácter $x_i$ aparecer numa determinada posição. Para uma seleção verdadeiramente aleatória de um conjunto de $C$ caracteres, a entropia máxima por carácter é $\log_2(C)$. Para um conjunto de 72 caracteres (26 minúsculas + 26 maiúsculas + 10 dígitos + 10 símbolos), o máximo $H_{char} \approx 6.17$ bits. Uma palavra-passe de 10 caracteres tem, portanto, um máximo teórico de ~61.7 bits de entropia.
O estudo descobriu que as tendências nos algoritmos de alguns gestores reduziram a entropia efetiva. A vulnerabilidade a ataques offline foi avaliada usando uma taxa estimada de quebra $R$ (hashes por segundo) e o espaço de palavras-passe $N$:
$\text{Tempo para quebrar} \approx \frac{N}{2 \times R}$
Assumindo uma taxa de ponta de $10^{10}$ hashes/seg (dentro do alcance para clusters modernos de GPU), uma palavra-passe com menos de ~65 bits de entropia ($N = 2^{65}$) poderia ser quebrada num prazo viável para um atacante motivado.
Gráfico-Chave 1: Tendência na Distribuição de Caracteres. Um gráfico de barras comparando a frequência observada vs. esperada dos tipos de caracteres (maiúsculas, minúsculas, dígitos, símbolos) em vários gestores de palavras-passe. Vários gestores mostraram um desvio estatisticamente significativo (p < 0.01) da distribuição uniforme esperada, com uma sobre-representação de dígitos em certas posições.
Gráfico-Chave 2: Entropia vs. Comprimento da Palavra-passe. Um gráfico de dispersão mostrando a entropia medida por gestor para diferentes comprimentos configurados de palavras-passe (8, 12, 16, 20 caracteres). O gráfico revelaria que, embora a maioria dos gestores se aproxime da linha de entropia teórica para palavras-passe mais longas, vários ficam aquém para comprimentos mais curtos (8-12 caracteres), agrupando-se abaixo da linha, indicando aleatoriedade mais fraca.
Gráfico-Chave 3: Matriz de Vulnerabilidade do Preenchimento Automático. Um mapa de calor com os gestores no eixo Y e as classes de vulnerabilidade (Clickjacking, Fuga por XSS, Injeção na Rede) no eixo X. As células são coloridas a verde (não vulnerável), amarelo (parcialmente/variadamente vulnerável) e vermelho (vulnerável). Esta visualização mostra claramente quais os gestores mais arriscados na superfície de ataque do preenchimento automático.
Caso: Avaliar a Segurança do Preenchimento Automático do "Gestor X".
Passo 1 - Mapeamento de Funcionalidades: Documentar como o Gestor X ativa o preenchimento automático: Preenche automaticamente? Mostra uma lista pendente? Em que atributos DOM se baseia (id, name, class, placeholder)?
Passo 2 - Modelação de Ameaças: Aplicar o modelo STRIDE.
Passo 3 - Execução de Testes: Criar uma página web de teste que tente sistematicamente cada vetor de ameaça. Para clickjacking, criar elementos sobrepostos transparentes. Para XSS, simular um script a ler a propriedade `value` dos campos preenchidos.
Passo 4 - Análise e Pontuação: Classificar cada vulnerabilidade com base na probabilidade e impacto (por exemplo, usando pontuação DREAD). A pontuação agregada determina a classificação geral de segurança do preenchimento automático para o Gestor X.
Esta abordagem estruturada vai além dos testes ad-hoc e garante uma cobertura abrangente.
1. Integração com WebAuthn/Passkeys: O futuro é sem palavras-passe. A próxima evolução para os gestores de palavras-passe é tornarem-se intermediários principais para passkeys (baseadas na API de Autenticação Web do W3C). É necessária investigação sobre a sincronização segura e recuperação de chaves privadas de passkeys entre dispositivos, um desafio destacado pela FIDO Alliance.
2. Preenchimento Automático Consciente do Contexto e Baseado no Risco: Em vez de uma lógica binária de preencher/não preencher, os gestores futuros poderiam usar aprendizagem automática para avaliar a legitimidade da página (verificando a antiguidade do domínio, certificado SSL, pontuações de reputação) e o contexto do utilizador (hora de login típica, dispositivo) para ajustar o comportamento do preenchimento automático, exigindo autenticação adicional para cenários de alto risco.
3. Verificação Formal e Hardware Seguro: Componentes críticos, especialmente o gerador de números aleatórios e as rotinas principais de encriptação/desencriptação, poderiam ser formalmente verificados usando ferramentas como Coq ou Tamarin Prover. A integração com Módulos de Plataforma Confiável (TPMs) ou Secure Enclaves para armazenamento de chaves poderia elevar a segurança para alvos de alto valor.
4. Arquiteturas Descentralizadas e Centradas no Utilizador: Afastar-se de cofres centralizados na nuvem para protocolos descentralizados (por exemplo, baseados em computação multipartidária segura ou servidores pessoais) poderia mitigar os riscos de violações em larga escala dos fornecedores. Isto alinha-se com a visão mais ampla do projeto "Solid" para pods de dados pessoais.