1. Introdução
Os gestores de senhas (GS) são ferramentas críticas recomendadas por especialistas em segurança para mitigar vulnerabilidades associadas à autenticação por senha, como senhas fracas e reutilização de senhas. Eles permitem o uso de senhas fortes e únicas, tratando do armazenamento e da geração. No entanto, a adoção pelos utilizadores é dificultada pela falta de confiança nestas aplicações. Este artigo identifica a funcionalidade de geração de senhas aleatórias (GSA) como um fator-chave que influencia tanto a confiança como a utilização. Para resolver isto, os autores propõem o desenvolvimento e a verificação formal de uma implementação de referência para um algoritmo de GSA, com o objetivo de fornecer uma base criptograficamente sólida e comprovadamente segura em que utilizadores e programadores possam confiar.
O problema central é que, embora os GS promovam a segurança, os seus mecanismos internos — especialmente a geração de senhas — são frequentemente caixas negras opacas. Sem garantias verificáveis, os utilizadores mantêm-se céticos. A via de solução envolve o uso de métodos formais, especificamente o enquadramento EasyCrypt, para especificar matematicamente o algoritmo e provar as suas propriedades de correção e segurança face a um modelo adversário bem definido.
2. Algoritmos Atuais de Geração de Senhas
O artigo analisa 15 gestores de senhas, focando-se em três exemplos de código aberto e amplamente utilizados: o gestor integrado do Google Chrome, o Bitwarden e o KeePass. A análise revela padrões comuns e diferenças críticas nas suas abordagens para gerar senhas aleatórias.
2.1 Políticas de Composição de Senhas
Todos os GS estudados permitem que os utilizadores definam políticas que restringem a estrutura das senhas geradas. Estas políticas incluem tipicamente:
- Comprimento da Senha: Varia de 1-200 (Chrome) a um extremo de 1-30000 (KeePass).
- Conjuntos de Caracteres: Os conjuntos padrão incluem letras minúsculas, maiúsculas, números e caracteres especiais. O KeePass oferece granularidade adicional com conjuntos separados para parênteses, espaço, hífen e sublinhado.
- Mínimo/Máximo por Conjunto: O Chrome e o Bitwarden permitem definir ocorrências mínimas por conjunto de caracteres. O KeePass não o faz.
- Exclusão de Caracteres Ambíguos: Todos os três permitem excluir caracteres visualmente semelhantes (ex.: 'l', '1', 'O', '0') para reduzir erros do utilizador.
- Conjuntos Personalizados & Duplicados: O KeePass permite, de forma única, definir conjuntos de caracteres personalizados para incluir ou excluir, e pode remover caracteres duplicados da senha gerada.
A variação nas opções de política destaca a falta de padronização, o que complica a criação de um modelo universal e verificável.
2.2 Geração de Senhas Aleatórias
O algoritmo geral envolve a seleção aleatória de caracteres dos conjuntos permitidos, respeitando as restrições da política (comprimento, mínimos, máximos). O artigo descreve em detalhe o algoritmo do Chrome:
- Primeiro, gerar caracteres para cada conjunto que tenha um número mínimo de ocorrências definido.
- Depois, gerar os caracteres restantes selecionando aleatoriamente da união de todos os conjuntos que ainda não atingiram o seu número máximo de ocorrências permitido.
- Finalmente, aplicar uma permutação aleatória à cadeia de caracteres gerada.
Este processo, embora aparentemente simples, deve ser implementado com cuidado para garantir uma verdadeira aleatoriedade e uma distribuição imparcial em todo o espaço de senhas restringido pela política. Subtis enviesamentos na seleção ou permutação podem enfraquecer as senhas resultantes.
3. Implementação Formalmente Verificada Proposta
A contribuição central do artigo é a proposta de construir uma implementação de referência de GSA com provas verificadas por máquina das suas propriedades.
3.1 Especificação Formal
O primeiro passo é criar uma especificação matemática precisa do algoritmo de geração de senhas dentro do EasyCrypt. Esta especificação define:
- Entradas: Parâmetros da política (comprimento $L$, conjuntos de caracteres $S_1, S_2, ..., S_n$, mínimos $min_i$, máximos $max_i$).
- Saída: Uma cadeia de senha $p$ de comprimento $L$.
- Pré-condições: A política deve ser consistente (ex.: $\sum min_i \leq L$).
- Pós-condições (Correção Funcional): A saída $p$ deve satisfazer todas as restrições da política. Formalmente, $\forall i, min_i \leq count(p, S_i) \leq max_i$, onde $count$ conta os caracteres do conjunto $S_i$ em $p$.
3.2 Propriedades de Segurança e Provas
Para além da correção, a implementação deve ser comprovadamente segura. O artigo adota uma abordagem de prova criptográfica baseada em jogos. A propriedade de segurança chave é a amostragem aleatória uniforme do conjunto de todas as senhas que satisfazem a política dada.
Isto é formalizado como um jogo de segurança onde um adversário tenta distinguir entre uma senha gerada pelo algoritmo real e uma senha amostrada uniformemente do espaço de senhas válidas. A prova demonstra que nenhum adversário eficiente pode vencer este jogo com uma probabilidade significativamente melhor do que um palpite aleatório (1/2). Isto garante que o algoritmo não introduz padrões previsíveis ou enviesamentos.
A prova aproveitaria as bibliotecas do EasyCrypt para raciocinar sobre computações probabilísticas e amostragem aleatória.
4. Resultados Experimentais & Análise
Embora o PDF fornecido seja um trabalho preliminar e não contenha resultados experimentais completos, ele prepara o terreno para os mesmos. A verificação proposta produziria os seguintes resultados tangíveis:
- Relatório de Verificação: Um certificado de prova gerado por máquina a partir do EasyCrypt, confirmando que o código do algoritmo adere à sua especificação formal e aos teoremas de segurança.
- Análise Comparativa: O algoritmo verificado poderia ser comparado com as implementações existentes no Chrome, Bitwarden e KeePass. Os testes envolveriam gerar grandes lotes de senhas (ex.: 1 milhão) sob políticas idênticas e analisar estatisticamente a distribuição.
- Métrica: Uma métrica chave seria a Divergência de Kullback-Leibler (KL) ou o teste do Qui-quadrado entre a distribuição empírica das senhas geradas e a distribuição uniforme teórica sobre o espaço definido pela política. Um algoritmo formalmente verificado deveria mostrar uma divergência estatisticamente indistinguível de zero, enquanto implementações não verificadas poderiam revelar enviesamentos subtis.
- Descrição do Gráfico: Um gráfico de barras comparando a entropia (em bits) da distribuição de senhas geradas para o algoritmo de cada GS contra a entropia máxima teórica para a política dada. A barra da implementação de referência verificada deveria alinhar-se perfeitamente com a barra "Máximo Teórico".
5. Detalhes Técnicos & Enquadramento Matemático
A verificação formal baseia-se na modelação matemática precisa. Vamos definir os conceitos centrais:
Espaço de Senhas: Dada uma política com comprimento $L$ e conjuntos de caracteres permitidos $S_1, ..., S_n$, o conjunto total de senhas conformes $\mathcal{P}$ é um subconjunto do produto cartesiano $\mathcal{C}^L$, onde $\mathcal{C} = \bigcup_{i=1}^n S_i$. O tamanho de $\mathcal{P}$ é restringido pelas regras de mínimo e máximo.
Distribuição Uniforme: O objetivo de segurança é que o algoritmo $\mathcal{A}$ implemente uma função indistinguível de um verdadeiro amostrador uniforme $\mathcal{U}_{\mathcal{P}}$. Para qualquer senha $p \in \mathcal{P}$, a probabilidade deve ser: $$\Pr[\mathcal{A}(policy) = p] = \frac{1}{|\mathcal{P}|}$$ onde $|\mathcal{P}|$ é a cardinalidade do conjunto de senhas válidas.
Esboço da Prova Baseada em Jogos: A segurança é enquadrada como um jogo "Real-ou-Aleatório" (RoR).
- O desafiante lança uma moeda secreta $b \xleftarrow{\$} \{0,1\}$.
- O adversário $\mathcal{D}$ pode consultar o desafiante com políticas de senha.
- Se $b=0$ (Real), o desafiante executa o algoritmo real $\mathcal{A}$.
- Se $b=1$ (Aleatório), o desafiante amostra uniformemente de $\mathcal{P}$ usando $\mathcal{U}_{\mathcal{P}}$.
- $\mathcal{D}$ produz um palpite $b'$.
6. Enquadramento de Análise: Um Exemplo Sem Código
Como o PDF não inclui código real, aqui está um enquadramento de análise conceptual para avaliar um algoritmo de GSA, apresentado como uma lista de verificação:
Caso: Avaliar o gerador de senhas do "GS-X".
Passo 1 - Desconstrução da Política: Mapear as opções da interface do utilizador do GS-X (caixas de verificação, controlos deslizantes) para um tuplo de política formal: (L=12, Sets={Minúsculas, Maiúsculas, Dígitos}, min_Minúsculas=1, min_Maiúsculas=1, min_Dígitos=1, exclude={'l','O','0'}).
Passo 2 - Transparência Algorítmica: Os passos do algoritmo (como o processo de 3 passos do Chrome) podem ser claramente descritos a partir da documentação ou do código-fonte? Se não, falha no teste de transparência.
Passo 3 - Cálculo da Entropia: Calcular a entropia máxima teórica para a política: $log_2(|\mathcal{P}|)$ bits. Para a política acima, $|\mathcal{P}|$ é o número de cadeias de 12 caracteres de um alfabeto (ex.: 70 caracteres após exclusões) que satisfazem as restrições mínimas. Este é o benchmark de segurança.
Passo 4 - Desenho do Teste Estatístico: Desenhar uma experiência para gerar $N$ senhas e testar a distribuição uniforme. Usar o teste do Qui-quadrado em todo o espaço de senhas ou num subconjunto inteligentemente amostrado.
Passo 5 - Deteção de Enviesamento: Procurar enviesamentos específicos: Certas posições de caracteres são menos aleatórias? O algoritmo para cumprir os mínimos reduz a aleatoriedade para as posições restantes?
Este enquadramento fornece uma metodologia estruturada, sem código, para examinar criticamente qualquer GSA, alinhando-se com o objetivo do artigo de passar da obscuridade para uma análise verificável.
7. Aplicações Futuras & Direções de Investigação
O trabalho abre várias vias promissoras:
- Padronização: Um GSA formalmente verificado poderia tornar-se um componente padrão (como uma biblioteca) integrado em GS em toda a indústria, semelhante à forma como o libsodium fornece primitivas criptográficas verificadas.
- Integração no Navegador e SO: Sistemas operativos (ex.: Windows Hello, macOS Keychain) e navegadores poderiam adotar o gerador verificado para as suas funcionalidades integradas de sugestão de senhas, elevando o nível de segurança base para todos os utilizadores.
- Geração Suportada por Hardware: O algoritmo verificado poderia ser implementado em elementos de hardware seguro (TPM, Secure Enclave) para uma geração que é tanto fisicamente como logicamente segura.
- Considerações Pós-Quânticas: Investigação futura poderia explorar políticas de geração de senhas que produzam senhas resistentes a ataques de força bruta clássicos e quânticos, com provas formais adaptadas a novos modelos de ameaça.
- Verificação do Compromisso Usabilidade-Segurança: Estender o modelo formal para provar propriedades sobre a memorabilidade ou facilidade de digitação das senhas geradas, colmatando o fosso entre criptografia pura e interação humano-computador.
- Análise Automática de Políticas: Desenvolver ferramentas que usem o modelo formal para analisar automaticamente uma política definida pelo utilizador e reportar a sua entropia efetiva e quaisquer restrições não intencionais que enfraqueçam o espaço de senhas.
8. Referências
- Grilo, M., Ferreira, J. F., & Almeida, J. B. (2021). Towards Formal Verification of Password Generation Algorithms used in Password Managers. arXiv preprint arXiv:2106.03626.
- Bellare, M., & Rogaway, P. (2006). The security of triple encryption and a framework for code-based game-playing proofs. In Advances in Cryptology-EUROCRYPT 2006 (pp. 409-426). Springer.
- Barthe, G., Dupressoir, F., Grégoire, B., Kunz, C., Schmidt, B., & Strub, P. Y. (2016). EasyCrypt: A computer-aided cryptography toolset. Lecture Notes in Computer Science, 9573, 3-32.
- National Institute of Standards and Technology (NIST). (2020). Digital Identity Guidelines: Authentication and Lifecycle Management (SP 800-63B).
- Shannon, C. E. (1948). A mathematical theory of communication. The Bell System Technical Journal, 27(3), 379-423. (Trabalho fundamental sobre entropia e teoria da informação).
- Florêncio, D., Herley, C., & Van Oorschot, P. C. (2014). An administrator's guide to internet password research. In 28th Large Installation System Administration Conference (LISA14) (pp. 44-61).
9. Perspetiva do Analista: Ideia Central & Crítica
Ideia Central
Este artigo identifica corretamente uma vulnerabilidade crítica, mas frequentemente negligenciada, na cadeia de abastecimento de cibersegurança: a aleatoriedade não verificada no cerne dos gestores de senhas. A verdadeira ideia não é que a geração de senhas seja complexa — é que o modelo de confiança para uma ferramenta de segurança fundamental está quebrado. Pede-se aos utilizadores que confiem numa caixa negra com as suas chaves digitais. A proposta dos autores de aplicar verificação formal, uma técnica mais comum no desenho de hardware e software crítico de aviação (como sistemas certificados DO-178C), a uma primitiva de segurança de consumo é ambiciosa e necessária. É uma tentativa de transplantar o rigor do laboratório de investigação da SRI International ou da INRIA para o mundo frequentemente descuidado da segurança de aplicações.
Fluxo Lógico
O argumento flui logicamente de um problema bem estabelecido (desconfiança dos utilizadores nos GS) para uma causa raiz técnica e específica (geração de senhas opaca), e depois para uma via de solução concreta e de alta garantia (especificação formal e prova). O levantamento dos GS existentes não é apenas académico; demonstra efetivamente a enorme inconsistência nas implementações, fundamentando o caso para uma referência padrão e verificada. A mudança para o EasyCrypt e provas baseadas em jogos é apropriada, pois este enquadramento, desenvolvido por instituições líderes em criptografia formal, é precisamente desenhado para esta classe de problemas. O fluxo espelha a metodologia de trabalhos seminais em criptografia verificada, como a verificação do gerador HMAC-DRBG.
Pontos Fortes & Falhas
Pontos Fortes: O maior ponto forte do artigo é o seu foco num problema de alto impacto e tratável. Não tenta verificar um GS inteiro; vai ao cerne criptográfico. Usar GS de código aberto para análise fundamenta a investigação na realidade. A escolha de provas baseadas em jogos é o padrão da indústria para a análise criptográfica moderna.
Falhas Críticas & Lacunas: O artigo, tal como apresentado, é mais uma proposta convincente do que um estudo concluído. A omissão mais flagrante é o código EasyCrypt real e as provas concluídas. Sem estes, a afirmação permanece teórica. Além disso, subestima o problema da complexidade da política. A especificação formal deve lidar com todos os casos limite das políticas definidas pelo utilizador (ex.: mínimos/máximos conflituosos, conjuntos de caracteres personalizados). Isto poderia levar a uma especificação tão complexa quanto a implementação, um desafio conhecido nos métodos formais. Também contorna a fonte de entropia do mundo real — o algoritmo é tão bom quanto o CSPRNG do sistema (ex.: /dev/urandom). Um algoritmo verificado alimentado com aleatoriedade fraca continua fraco. O artigo seria mais forte ao limitar explicitamente as suas garantias com base numa suposição de fonte de entropia perfeita.
Ideias Acionáveis
1. Para Programadores de GS: Abrir imediatamente o código de geração de senhas e submetê-lo a auditoria de terceiros. Começar a modelar o seu algoritmo, mesmo informalmente, para identificar potenciais enviesamentos. Considerar integrar uma biblioteca verificada como a que esta investigação visa produzir.
2. Para Auditores de Segurança: Adicionar "Análise do Algoritmo de GSA" à sua lista de verificação padrão de auditoria de GS. Usar o enquadramento estatístico delineado na Secção 6 para testar enviesamentos distribucionais nas saídas do cliente.
3. Para Organismos de Normalização (ex.: NIST, FIDO Alliance): Iniciar um grupo de trabalho para definir uma API padrão e um conjunto de requisitos de segurança para geradores de senhas, preparando o caminho para implementações certificadas. Isto espelha a bem-sucedida padronização de algoritmos criptográficos.
4. Para Investigadores: Este trabalho é um ponto de partida perfeito. O próximo passo é completar a implementação e as provas no EasyCrypt. Uma fase subsequente e crucial é desenvolver um *harness* de testes que possa pegar no código verificado e testá-lo (*fuzzing*) contra o código do mundo real do Chrome, Bitwarden, etc., para encontrar discrepâncias e vulnerabilidades concretas, passando da teoria para o impacto prático.
Em conclusão, este artigo lança uma luz necessária sobre um canto escuro da nossa infraestrutura de segurança. Embora incompleto, a sua direção está correta. A indústria dos gestores de senhas amadureceu para além da fase "confie apenas em nós"; é tempo de confiança verificável e matemática. O sucesso desta investigação poderia estabelecer um novo precedente para a forma como construímos todo o software de segurança do lado do cliente.