O gerador certo, linguagem certa. Nem todos os geradores de senhas são iguais, e a linguagem em que seu cofre é escrito não é um detalhe de engenharia. Entenda a entropia, os modos de geração e por que Rust se destaca por baixo do capô. Quando um gerenciador "gera uma senha forte", duas perguntas surgem: ela é realmente imprevisível? (a qualidade da aleatoriedade) e o que acontece com ela na memória depois de exibida? A primeira depende dos modos de geração. A segunda, da linguagem que executa a aplicação. Este artigo cobre as duas. ~100 bits senha aleatória de 16 caracteres (muito forte) ~77 bits passphrase Diceware de 6 palavras (EFF) 12,9 bits de entropia adicionados por palavra Diceware (lista de 7 776 palavras) Entropia: a única métrica que importa A força de uma senha não se mede pela "complexidade" percebida, mas por sua entropia : o número de bits de incerteza para um atacante. Quanto mais combinações possíveis, maior o custo de um ataque de força bruta. Uma senha de 16 caracteres escolhidos de todo o alfabeto ASCII chega a cerca de 100 bits, no patamar de "muito forte". Um ponto crucial, muitas vezes esquecido: a entropia só vale se a fonte de aleatoriedade for um CSPRNG (gerador pseudoaleatório criptograficamente seguro). Um Math.random() clássico é previsível e compromete todo o restante. Boas implementações leem a entropia do sistema operacional: /dev/urandom ou getrandom(2) no Unix, CNG no Windows. Quatro famílias de geradores Um bom gerenciador não oferece "um" gerador, mas vários modos adaptados ao uso. A regra: memorabilidade custa comprimento . Veja as quatro famílias, da mais densa à mais humana. O reflexo certo: adaptar a entropia ao uso Para uma conta web protegida por uma página de login com limite de tentativas, o atacante fica preso a algumas centenas de tentativas por segundo: até 50 bits resistem por tempos geológicos. Entropia em excesso só faz sentido para segredos offline (chave de criptografia, seed de carteira cripto), onde o ataque pode ser massivamente paralelizado. Para esses segredos de altíssimo valor, rolar dados físicos reais (Diceware no sentido literal) continua sendo a opção definitiva: elimina qualquer dependência da qualidade do CSPRNG ou de um navegador comprometido. Por que Rust muda o jogo Gerar uma boa senha é metade do trabalho. A outra metade: não deixá-la sobrando por aí . Depois de exibida ou descriptografada, sua senha vive na memória RAM, e é aí que a linguagem da aplicação se torna decisiva. A Microsoft relatou que 70 % das vulnerabilidades de segurança que encontra são bugs de memória (buffer overflow, use-after-free etc.). O Google observou a mesma proporção no Chrome e no Android. São exatamente essas classes de falhas que Rust elimina em tempo de compilação , por meio de seu modelo de propriedade ( ownership ) e empréstimo ( borrowing ), sem garbage collector. Os números do Google são eloquentes: as vulnerabilidades de memória do Android caíram de 223 em 2019 para menos de 50 em 2024 , ficando abaixo de 20 % do total pela primeira vez. O novo código em Rust apresenta uma densidade de falhas de memória até 1000× menor que a do código C/C++ legado, além de 4× menos rollbacks e 25 % menos tempo de revisão. 1. Segurança de memória sem garbage collector. Linguagens como Java ou Python são memory-safe, mas seu garbage collector libera memória de forma não determinística: um segredo pode sobreviver ali indefinidamente, exposto a um memory dump ou a um ataque cold-boot. Rust libera memória de forma determinística, assim que o dado deixa de ser usado. 2. Apagamento explícito com zeroize . Rust não garante que a memória liberada seja sobrescrita. A crate zeroize fecha essa lacuna: ao envolver um segredo em Zeroizing , garante-se sua sobrescrita com zeros, por meio de uma escrita volátil que o compilador não consegue otimizar, no momento exato em que ele sai de escopo. 3. Um sistema de tipos que força o uso correto da criptografia. O sistema de tipos rigoroso de Rust permite delimitar como um dado sensível pode ser usado, e quantas vezes. Por exemplo, é possível modelar uma chave que só pode ser empregada uma única vez, com o compilador recusando qualquer reutilização. Honestidade técnica: Rust não é uma varinha mágica Código unsafe e dependências de terceiros continuam sendo superfícies de ataque: o Google, inclusive, corrigiu uma falha (CVE-2025-48530) em um bloco unsafe de um parser Rust antes de qualquer entrada em produção. Segurança de memória é uma camada , não um fim em si: ela se combina com defesa em profundidade (KDF robusta como Argon2id, arquitetura zero-knowledge, bloqueio automático, MFA). O que exigir de um gerenciador Na hora de escolher, ou avaliar, um gerenciador de senhas, faça quatro perguntas concretas: 1. O gerador se apoia em um CSPRNG do sistema e mostra a entropia em bits? 2. Ele oferece um modo passphrase Diceware/EFF para a senha mestra? 3. A geração é local (client-side) , sem passar por um servidor? 4. O núcleo sensível é escrito em uma linguagem memory-safe com apagamento explícito de segredos? Geração segura. Um cofre pensado para durar. Senhas de alta entropia, passphrases memorizáveis e um núcleo preparado para segurança de memória. Conteúdo informativo com finalidade educativa. As estatísticas citadas (Google/Android, Microsoft, Diceware/EFF) vêm das fontes listadas acima. Os exemplos de código Rust são ilustrativos e simplificados.