Aleatório criptográfico versus pseudoaleatório em senhas (o que devs erram)

Uma senha é tão forte quanto o processo aleatório que a gerou. Se esse processo é previsível — mesmo estatisticamente — atacantes encolhem o espaço de busca. Devs importam funções "aleatórias" sem ler garantias; elas otimizam simulação e reprodutibilidade, não imprevisibilidade sob observação adversarial. Aqui contrastamos PRNG com CSPRNG, orçamento de entropia e a prática de Crypto.getRandomValues() no navegador — e por que rascunhar senhas localmente com o Safe Local Tools evita mandar candidatas por rede enquanto experimenta políticas.

Definições em linguagem simples

PRNGs expandem um estado pequeno por matemática determinística; vazando estado ou amostras, saídas futuras deixam de ser surpresa. CSPRNGs fortalecem suposições sob ataque: saídas devem ser computacionalmente indistinguíveis de bits uniformes mesmo quando o adversário viu saídas anteriores, dentro de pressupostos padrão da criptografia.

Desastres raramente são "bug idiota óbvio"; muitas vezes um PRNG de estatística entrou em costura criptográfica por dependência transitiva.

Por que Math.random não serve para segredo

APIs como Math.random() priorizam velocidade e floats "uniformes" para jogos — não resistência a engenharia reversa com saídas parcialmente observadas. Strings que "parecem embaralhadas" ainda podem vir de estado pequeno demais depois de formatar.

// Padrão INSEGURO para segredos (ilustrativo):
const tokenRuim = Math.random().toString(36).slice(2);
 
const buf = new Uint8Array(16);
crypto.getRandomValues(buf);

Modelagem de ameaça e entropia útil

Pergunte: atacante quebra offline depois de vazar hash ou adivinha com rate limit na UI? Observa múltiplas saídas correlacionadas? Senha precisa ser memorizada ou vai para gerenciador? Respostas guiam comprimento, alfabeto e rotação — aleatoriedade sozinha não conserta logística humana.

Com alfabeto de tamanho A e comprimento L uniforme, possibilidades ≈ A^L — por isso comprimento real importa mais que trocar fonte estética. Senhas humanas clusterizam culturalmente (P@ssw0rd); amostragem uniforme de máquina foge de dicionários — se a geração for verdadeiramente ampla.

Armadilha do módulo e hashing no servidor

Reduzir bytes aleatórios com % n sem correção introduz viés; algumas letras aparecem um pouco mais — margens pequenas importam em vazamentos massivos de hash.

No servidor, senhas de usuário devem passar por funções lentas (Argon2id, bcrypt, scrypt); tokens opacos de sessão/API podem ser octetos puros sem restrição de memorização — o gerador conversa diferente com humanos e com máquinas.

{
  "minLength": 16,
  "requireUpper": false,
  "requireDigits": true,
  "charset": "subconjunto-seguro-base94"
}

Geração no cliente e o papel do Safe Local Tools

Navegador serve para rascunhar e ensaiar, não para substituir controles regulatórios de emissão e revogação no backend quando aplicável. Ainda assim, evitar enviar candidatas por Slack ou e‑mail durante auditoria reduz vazamento desnecessário — lembre que gerenciadores, extensões e histórico de clipboard também retêm dados.

Safe Local Tools enfatiza fluxo local no navegador ao gerar senhas para experimentação compatível com políticas internas — siga o compliance da sua empresa antes de persistir qualquer segredo.

Passphrases, rotação com evidência e checklist de UI

Diceware uniforme de lista curada acumula entropia por palavra; citar frases de filme não. SSO resolve muito, mas chaves SSH, webhooks e PATs ainda precisam de disciplina CSPRNG.

Checklist: use crypto.getRandomValues (ou equivalente) para bytes; evite viés de módulo; mostre claramente o alfabeto amostrado; avise sobre copiar para canais inseguros.

Rotação por calendário frequentemente treina padrões previsíveis; troque após comprometimento confirmado ou sinais de stuffing, não ritual trimestral vazio.

Ao ensaiar políticas de complexidade em conjunto com jurídico, gerar prévias no navegador evita que amostras reais de senha virem anexo de e‑mail corporativo indexado por mecanismo de busca por engano. Mesmo "falsas" senhas ainda treinam usuários a copiar padrões; prefira exemplos sintéticos claramente marcados e destrua clipboard após demo quando possível.

Em pentests internos, rastreie Math.random residual com grep amplio: snippets de blog entram via dependência transitiva e sobrevivem anos porque ninguém reabre utilitário "pequeno". Código legado de sorteio de cupom não deveria importar a mesma função que gera reset token — o risco é organizacional tanto quanto técnico.

Aleatoriedade criptográfica remove templates que atacantes já esperam — comprimento, armazenagem, hashing e MFA ainda dominam o resultado sistêmico. Escolha primitivas de propósito (crypto.getRandomValues), codifique sem viés e documente o alfabeto para auditores. Para prototipar senhas fortes sem mandar candidatas por aí, Experimentar o gerador de senhas →