Gerador de Senhas

Um gerador de senhas cria senhas aleatórias e difíceis de adivinhar conforme comprimento e regras de caracteres escolhidos. Um bom gerador usa aleatoriedade criptograficamente segura e combina letras maiúsculas, minúsculas, números e símbolos apenas quando o sistema de destino aceita esses caracteres. Senhas fortes reduzem ataques de dicionário, força bruta e credential stuffing, mas não substituem bons hábitos como usar gerenciador de senhas, manter uma senha única por conta e ativar autenticação multifator. Senhas muito complexas não devem ser memorizadas nem reutilizadas; devem ser armazenadas com segurança. Em sistemas compartilhados, rotação, propriedade e regras de acesso também precisam ficar claras.

O gerador de senhas extrai aleatoriedade de crypto.getRandomValues(new Uint32Array(n)), que preenche um array tipado com valores pseudo-aleatórios criptograficamente seguros provenientes do pool de entropia do sistema operacional (getrandom no Linux, BCryptGenRandom no Windows, SecRandomCopyBytes no macOS/iOS). Trata-se de um CSPRNG conforme definido pela W3C Web Cryptography API — diferentemente de Math.random(), que no V8 usa o algoritmo xorshift128+ e é explicitamente documentado como não criptográfico e previsível a partir de uma pequena amostra de saídas. O pool de caracteres é montado a partir das classes de caracteres selecionadas pelo usuário: maiúsculas (26 letras A-Z), minúsculas (26 letras a-z), dígitos (10 caracteres 0-9) e símbolos (32 caracteres de !@#$%^&*()_+-=[]{}|;:,.<>?), resultando em um pool máximo de 94 caracteres. Um conjunto personalizado de caracteres ou lista de exclusão (incluindo um filtro de caracteres ambíguos que remove i, I, l, L, 1, o, O, 0) refina ainda mais o pool. Cada caractere da senha é selecionado tomando array[i] % pool.length, que é uniformemente distribuído porque a saída do CSPRNG é uniforme em 32 bits e o viés do módulo (|pool| não divide 2^32 uniformemente) é insignificante para pools com menos de 256 caracteres — o viés é inferior a 0,00000006%, muito abaixo de qualquer preocupação prática. A força da senha é medida pelo tamanho do espaço de busca: para um pool de tamanho C e comprimento de senha L, o número de senhas possíveis é C^L. A entropia em bits é log2(C^L) = L × log2(C). Para uma senha de 16 caracteres com as quatro classes de caracteres habilitadas (C=94), isso resulta em 94^16 ≈ 4,4 × 10^31 combinações, ou cerca de 105 bits de entropia. A uma taxa hipotética de ataque de 10^12 tentativas por segundo (aproximamente a capacidade de um grande cluster de GPU contra um hash rápido como NTLM), a busca exaustiva levaria aproximadamente 4,4 × 10^19 segundos — muito mais que a idade do universo. Este modelo assume que o atacante deve testar cada combinação (sem atalhos baseados em dicionário ou padrão) e que a senha é hasheada com um algoritmo lento e salgado como bcrypt ou Argon2id, em vez de armazenada em texto simples. O NIST SP 800-63B recomenda um mínimo de 8 caracteres para senhas escolhidas pelo usuário e pelo menos 6 caracteres gerados aleatoriamente para credenciais geradas por máquina, com o conjunto de caracteres documentado. O intervalo de comprimento do gerador de 4 a 64 caracteres abrange tudo, desde códigos PIN até credenciais de máquina de alta entropia. A opção de começar com uma letra garante que o primeiro caractere seja extraído de [A-Za-z], o que atende a sistemas legados que exigem que as senhas comecem com uma letra.

• Fonte CSPRNG: crypto.getRandomValues() obtém entropia do CSPRNG do kernel do sistema operacional (getrandom/BCryptGenRandom/SecRandomCopyBytes) — diferentemente de Math.random() (xorshift128+), não é previsível, não pode ser inicializado pela página e é adequado para geração de credenciais.
• Matemática do espaço de caracteres: Com as quatro classes habilitadas, o tamanho do pool é 94; a entropia por caractere é log2(94) ≈ 6,55 bits. Uma senha de 16 caracteres possui ~105 bits de entropia; dobrar o comprimento para 32 eleva isso para ~210 bits.
• Seleção por módulo: array[i] % pool.length mapeia a saída CSPRNG de 32 bits para um índice de caractere — o viés é inferior a 6 × 10^-8 % para pools com menos de 256 caracteres, tornando-o criptograficamente irrelevante.
• Modelo de resistência a força bruta: A 10^12 tentativas/segundo (escala de cluster GPU), uma senha de 16 caracteres com 94 símbolos levaria ~10^19 segundos para esgotar — mas isso assume um hash rápido; bcrypt com fator de custo 12 reduz o atacante para ~10^4 tentativas/segundo, tornando até senhas de 8 caracteres resilientes.
• Exclusão de caracteres ambíguos: O filtro remove {i, I, l, L, 1, o, O, 0} (8 caracteres) — isso reduz o pool de 94 para 86, custando aproximadamente 0,6 bits de entropia por caractere, o que é aceitável pelo ganho de usabilidade em cenários de transcrição manual.
• Alinhamento com NIST SP 800-63B: O padrão exige um mínimo de 6 caracteres escolhidos aleatoriamente para segredos gerados por máquina e recomenda documentar o espaço de caracteres — as predefinições do gerador (Simples 8 caracteres, Forte 20 caracteres) mapeiam para diferentes níveis de garantia.
• Histórico no localStorage: As últimas 10 senhas geradas são persistidas em window.localStorage, que é delimitado por origem e perfil do navegador — limpar o histórico remove as senhas do armazenamento, mas uma ferramenta forense a nível de disco poderia recuperá-las porque o localStorage é armazenado como um banco de dados SQLite em texto simples no diretório do perfil do navegador.