Gerador de senhas em massa gratuito

Geração em lote de senhas

Esta ferramenta gera várias senhas criptograficamente robustas em uma única operação. Perfeita para preparar listas para a integração de uma equipe, a criação em massa de contas ou a gestão de inventários de senhas. Cada senha é produzida pelo gerador aleatório integrado do navegador.

Níveis de robustez

• Fraca · 8-11 caracteres : proteção básica, a evitar para contas sensíveis
• Correta · 12-15 caracteres : proteção moderada, aceitável para muitos usos
• Boa · 16-19 caracteres : proteção forte, recomendada para a maioria das contas
• Muito forte · 20 caracteres ou mais : proteção máxima, ideal para sistemas críticos

Perguntas frequentes

Essas senhas são realmente aleatórias ?

Sim. As senhas são geradas com window.crypto.getRandomValues(), que fornece valores aleatórios criptograficamente seguros, adequados para usos de segurança.

Posso gerar mais de 100 senhas ?

A ferramenta limita a geração a 100 por vez para evitar tornar o navegador lento. Gere vários lotes separadamente se necessário.

Como armazenar o arquivo baixado ?

Guarde o arquivo .txt em um local seguro, de preferência criptografado. Nunca o inclua em um repositório de código nem o compartilhe por canais não seguros. Exclua-o após a distribuição aos usuários.

De onde vêm os bons números aleatórios

Um computador é, por design, determinístico. Dadas as mesmas entradas e o mesmo código, ele produz as mesmas saídas todas as vezes. Essa é exatamente a propriedade que você quer de uma CPU rodando uma planilha, e exatamente a propriedade que você não quer de um gerador de senhas. Se um atacante consegue reproduzir a sequência de valores que o gerador emitiu, ele consegue reproduzir toda senha que ele já gerou.

Então o gerador coleta «entropia» (sinal físico imprevisível vindo de fora do programa) e a usa para semear um algoritmo chamado CSPRNG (Gerador de Números Pseudoaleatórios Criptograficamente Seguro). O «pseudo» é honesto: os bits são produzidos por um algoritmo, não pela física. O «criptograficamente seguro» significa que mesmo um atacante que veja uma longa sequência de saídas passadas não consegue prever o próximo byte melhor do que o acaso. Theodore Ts'o implementou o /dev/random no kernel do Linux em 1994, e o macOS, os BSDs, o Solaris e o Windows (com BCryptGenRandom) adotaram interfaces equivalentes. Por baixo dos panos, eles misturam toda fonte plausível de variação física (tempo de busca em disco, chegada de pacotes de rede, entrada de teclado e mouse, interrupções de hardware, RDRAND em CPUs Intel que o possuem) por meio de um hash criptográfico e, então, resemeiam continuamente.

No navegador, a Web Cryptography API do W3C expõe isso via window.crypto.getRandomValues(typedArray): passe a ela um array tipado, e o navegador o preenche com bytes aleatórios criptograficamente fortes. O máximo por chamada é de 65.536 bytes (esta ferramenta fica bem abaixo). A API tem suporte de base no Chrome, Firefox, Safari e Edge desde julho de 2015: não há possibilidade realista de um usuário chegar a esta ferramenta com um navegador que não a tenha.

Entropia de senha, a matemática de verdade

A «força» de uma senha, no sentido criptográfico formal, é medida em bits de entropia. A fórmula padrão para uma senha gerada aleatoriamente é:

Entropia = L × log₂(R)

onde L é o comprimento em caracteres e R é o tamanho do conjunto de caracteres. Entropia por caractere, por conjunto:

• Apenas dígitos (0-9): 10 caracteres → 3,32 bits/caractere
• Apenas minúsculas (a-z): 26 → 4,70 bits/caractere
• Minúsculas + maiúsculas (A-Za-z): 52 → 5,70 bits/caractere
• Minúsculas + maiúsculas + dígitos (alfanumérico): 62 → 5,95 bits/caractere
• Todo ASCII imprimível exceto o espaço: 94 → 6,55 bits/caractere

Vale a pena fixar o número 94: os códigos ASCII de 32 a 126 são os caracteres imprimíveis (95 no total); excluindo o espaço, sobram 94 glifos visíveis que não são espaço (26 minúsculas + 26 maiúsculas + 10 dígitos + 32 sinais de pontuação/símbolos). Inserindo números concretos na fórmula:

• 8 caracteres × 6,55 ≈ 52,4 bits: rápido de quebrar por força bruta em hardware moderno
• 12 caracteres × 6,55 ≈ 78,6 bits: no limite, logo abaixo do limiar de 80 bits
• 16 caracteres × 6,55 ≈ 104,8 bits: acima de 100, em território aceitável pela ANSSI
• 20 caracteres × 6,55 ≈ 131,0 bits: além do limiar equivalente ao AES-128
• 32 caracteres × 6,55 ≈ 209,6 bits: exagero para qualquer adversário concebível

A comunidade criptográfica chegou a três limiares: 80 bits como o mínimo absoluto (o piso recomendado pelo NIST até 2014), alcançado com ~13 caracteres usando o conjunto completo de 94 caracteres; 100 bits exigidos pela ANSSI (o equivalente francês da NSA) para senhas que protegem sistemas de criptografia, alcançados com ~16 caracteres; e 128 bits correspondendo à força de chave simétrica do AES-128, recomendados para senhas-mestras de cofres, alcançados com ~20 caracteres.

A ressalva enorme: essa matemática só se aplica a senhas aleatórias. Se um humano escolheu a senha, a entropia efetiva é muito, muito menor. O atacante não está enumerando as R^L combinações em ordem alfabética: ele está rodando um programa de adivinhação alimentado com listas de senhas vazadas, palavras de dicionário, substituições comuns (a→@, o→0, s→$), sequências de teclado e modelos estatísticos de como os humanos constroem strings memorizáveis. O estudo de Joseph Bonneau, de 2012, sobre um corpus anonimizado de 70 milhões de senhas do Yahoo (IEEE Symposium on Security and Privacy) concluiu que as senhas escolhidas por usuários oferecem «menos de 10 bits de segurança contra um ataque de varredura on-line, e apenas cerca de 20 bits contra um ataque de dicionário off-line otimizado». Vinte bits é um milhão de tentativas. Uma GPU moderna faz isso em microssegundos.

NIST SP 800-63B: o que mudou em 2017 e de novo em 2025

Por cerca de trinta anos, a política de segurança norte-americana sobre senhas descendeu de uma publicação do NIST de 1985 que recomendava rotação periódica obrigatória, classes de caracteres mistas e comprimentos mínimos curtos. Bill Burr, autor da continuação de 2003 que codificou a regra «maiúscula + minúscula + dígito + símbolo, troque a cada 90 dias», retratou-se publicamente em 2017, dizendo ao Wall Street Journal que «boa parte do que fiz, hoje eu lamento». O NIST formalizou a reversão no mesmo ano.

A NIST SP 800-63B Rev 3 (junho de 2017) fez duas mudanças geracionais. A Seção 5.1.1.2 diz: «Os verificadores NÃO DEVEM exigir que segredos memorizados sejam alterados arbitrariamente (por exemplo, periodicamente)», porque rotações forçadas levam os usuários a escolher senhas mais fracas e mais previsíveis. A mesma seção: «Os verificadores NÃO DEVEM impor outras regras de composição (por exemplo, exigir misturas de diferentes tipos de caracteres) para segredos memorizados», porque forçar um dígito e um símbolo empurra os usuários para Password1! em vez de uma frase-senha mais longa. A Rev 3 definiu o comprimento mínimo escolhido pelo assinante em 8 caracteres, exigiu que os verificadores aceitassem até 64, tornou obrigatória a checagem de novas senhas contra listas de bloqueio de vazamentos e exigiu explicitamente que gerenciadores de senhas e colagens da área de transferência fossem permitidos.

A NIST SP 800-63B Rev 4 (finalizada em 31 de julho de 2025) elevou o nível: senhas de fator único agora exigem um mínimo de 15 caracteres («Os verificadores e CSPs DEVEM exigir que as senhas usadas como mecanismo de autenticação de fator único tenham no mínimo 15 caracteres de comprimento»). As senhas de múltiplos fatores permanecem em 8 caracteres porque o segundo fator carrega o peso da segurança. As regras de composição continuam proibidas, e a redação mudou do «SHOULD NOT» (não deveria) da Rev 3 para o «SHALL NOT» (não deve) da Rev 4, tornando-o um requisito rígido em vez de uma recomendação. A rotação ainda é desencorajada, a menos que haja evidência de comprometimento.

A ferramenta da Absolutool usa, por padrão, 16 caracteres com as quatro classes de caracteres, fornecendo cerca de 104 bits de entropia e superando confortavelmente tanto o mínimo de 15 caracteres da Rev 4 quanto o limiar de equivalência simétrica de 80 bits. O máximo de 128 caracteres da ferramenta fica exatamente no dobro do comprimento máximo que o NIST determina que os verificadores devem aceitar: não há caso realista em que uma senha gerada seria longa demais para um servidor aceitar.

RockYou, o desastre que ainda assombra 2026

Em dezembro de 2009, a empresa de jogos sociais RockYou foi invadida por uma injeção de SQL de manual. A invasão expôs mais de 32 milhões de contas de usuário, incluindo as senhas dessas contas em texto puro: a RockYou as havia armazenado sem criptografia. A política de senhas da empresa na época exigia apenas cinco caracteres e não permitia caracteres especiais, o que havia agravado a vulnerabilidade.

O arquivo vazado, logo apelidado de rockyou.txt, foi publicado abertamente e continua sendo a lista de palavras de senha mais referenciada do mundo. Ele vem por padrão com o Kali Linux para testadores de penetração; toda ferramenta de ataque de dicionário do planeta verifica contra ele; serviços comerciais de credential stuffing o mantêm como base. Dezesseis anos depois, atacantes ainda capturam contas ativas usando senhas que apareceram pela primeira vez no vazamento de 2009. As lições que se propagaram: os servidores nunca deveriam ver senhas em texto puro (esta ferramenta gera no lado do cliente, então o servidor nunca as vê); as senhas armazenadas deveriam ser convertidas em hash com uma função lenta, com sal e de uso intensivo de memória, como Argon2id ou bcrypt, e não com um hash rápido como MD5 ou SHA-1 sem sal; senhas únicas por site são a única defesa contra o ataque de repetição de credenciais roubadas que dominou a última década de vazamentos.

Have I Been Pwned e o corpus de vazamentos

O Have I Been Pwned (HIBP), administrado pelo Microsoft Regional Director Troy Hunt, tornou-se a fonte autoritativa padrão para «esta senha já apareceu em um vazamento?». Hunt lançou o HIBP em 2013 como um índice pesquisável de endereços de e-mail vazados; mais tarde, ele acrescentou o corpus Pwned Passwords, uma lista para download de toda senha vista em um vazamento público, indexada pelo hash SHA-1. O Pwned Passwords V2 foi lançado em 22 de fevereiro de 2018 e introduziu a API de k-anonimato do conjunto de dados (construída com a Cloudflare): um cliente envia apenas os cinco primeiros caracteres do hash SHA-1; o servidor retorna todos os hashes completos que começam com esses cinco caracteres, junto com a contagem de vezes observadas; o cliente compara localmente. A senha (e até o seu hash completo) nunca sai do dispositivo do usuário.

Para um gerador em lote, a relevância é dupla. Qualquer senha que já esteja no HIBP, por definição, não é uma senha nova útil: será a primeira coisa que qualquer atacante de credential stuffing tentará. E como esta ferramenta gera com aleatoriedade total de CSPRNG a partir de um alfabeto de 94 caracteres, a probabilidade de que uma senha de 16 caracteres recém-gerada já esteja no HIBP é, para fins práticos, zero. (O número total de senhas de 16 caracteres com símbolos ASCII é 94^16 ≈ 3,7 × 10³¹; o HIBP contém cerca de 10⁹ senhas conhecidas; a probabilidade de colisão ≈ 10⁻²².)

O que «X bits de entropia» significa em tempo real de quebra

O número que dá significado concreto aos bits de entropia é «quanto tempo um atacante moderno precisaria?», e a resposta depende inteiramente do algoritmo de hash. O benchmark publicado pela comunidade para o hashcat v6.2.6 em uma única Nvidia RTX 4090 registra cerca de 300 GH/s para hashes NTLM (o antigo hash do Windows da Microsoft) e 200 kH/s para bcrypt. A diferença de quatro ordens de grandeza entre esses dois é o fato decisivo: o NTLM foi projetado para velocidade, o bcrypt foi projetado para ser lento.

As amplamente citadas tabelas de senhas da Hive Systems transformam os benchmarks em números de tempo até a quebra. A versão de 2025 calculada contra hashes MD5 (quase tão rápidos quanto o NTLM) indica ~59 minutos em uma RTX 4090 para quebrar por força bruta uma senha de 8 caracteres a partir do conjunto completo. A mesma senha de 8 caracteres contra um hash bcrypt leva ~99 anos no mesmo hardware. Essa diferença de quatro ordens de grandeza é a diferença entre «vazada ontem, quebrada na hora do almoço» e «vazada ontem, vai sobreviver a você».

O usuário final controla o comprimento da senha e o conjunto de caracteres. Ele não controla o algoritmo de hash que o servidor usa para armazená-la. A maioria dos serviços modernos bem administrados usa bcrypt, scrypt ou Argon2id, todos deliberadamente lentos. Serviços mais antigos e serviços invadidos frequentemente usavam MD5 ou SHA-1 sem sal, e é por isso que corpora antigos de vazamentos podem ser quebrados nas velocidades citadas acima. Para uma senha gerada por esta ferramenta: uma senha aleatória de 16 caracteres é segura contra bcrypt praticamente para sempre e razoavelmente segura contra MD5 por enquanto; uma senha de 20 caracteres é exagero contra qualquer um dos dois. Não há modelo de ameaça realista em que 20 ou mais caracteres de saída de CSPRNG sejam o elo fraco.

FIDO2, WebAuthn e a transição para passkeys

A previsão mais antiga da indústria de segurança é a de que as senhas vão desaparecer. Desde 2019, ela finalmente tem um substituto crível: as passkeys, o nome de marketing para o consumidor das credenciais emitidas sob os padrões FIDO2 / WebAuthn. O WebAuthn Level 1 tornou-se uma Recomendação do W3C em 4 de março de 2019; o Level 2 veio em seguida em 8 de abril de 2021. O modelo criptográfico é assimétrico: quando um usuário se registra, o autenticador gera um par de chaves pública/privada, envia a chave pública ao servidor e armazena a chave privada em hardware local seguro. A autenticação usa um desafio-resposta assinado com a chave privada. O servidor nunca vê o segredo, o que significa que uma invasão no lado do servidor não pode expor credenciais de login.

As implantações nas grandes plataformas avançaram em sincronia ao longo de 2022-2023: a Apple demonstrou as passkeys na WWDC em 6 de junho de 2022 e as lançou publicamente com o iOS 16, o iPadOS 16 e o macOS Ventura em setembro de 2022, com sincronização via iCloud Keychain criptografado de ponta a ponta. O Google anunciou o suporte a passkeys para Android e Chrome em 12 de outubro de 2022; o suporte estável no Chrome chegou no Chrome 108 em dezembro de 2022, sincronizando via Google Password Manager. A Microsoft anunciou o gerenciamento de passkeys para o Windows 11 em 21 de setembro de 2023, integrado ao Windows Hello.

As passkeys resolvem as classes mais dolorosas de falha de senha (phishing, credential stuffing, invasão de servidor), mas não eliminaram as senhas porque: muitos sites e a maioria dos sistemas legados ainda exigem uma; as passkeys estão atreladas a um dispositivo ou ecossistema de sincronização (usuários sem uma conta Apple, Google ou Microsoft precisam de uma alternativa); sistemas sem interface (dispositivos IoT, contas de serviço no lado do servidor, cenários de cadastro em lote) não podem depender de um autenticador biométrico na etapa de registro; e muitas políticas de senha corporativas, sistemas bancários e portais governamentais ainda exigem senhas. A geração de senhas em lote se encaixa diretamente na segunda e na terceira categorias: um administrador de sistemas provisionando 50 novas contas não pode pedir a cada futuro usuário que cadastre uma passkey antes de a conta existir.

Por que a geração no lado do cliente importa especificamente

Imagine uma ferramenta concorrente que faz um POST da solicitação do usuário para um servidor, o servidor roda o gerador aleatório e retorna a lista como JSON. Mesmo que tudo funcione como anunciado, as seguintes partes podem ver as senhas geradas em texto claro: a memória de processo do servidor enquanto a solicitação está sendo tratada; os logs de requisições do servidor (se o registro for ingênuo); qualquer serviço de APM ou de rastreamento de erros a que o servidor esteja conectado; o proxy reverso que termina o TLS (Cloudflare, balanceador de carga da AWS, nginx); qualquer ferramenta de depuração rodando no servidor; qualquer atacante futuro que obtenha acesso a qualquer um desses logs. O modelo RockYou, com todas as suas consequências, se aplica.

Quando a geração acontece via window.crypto.getRandomValues() no navegador do usuário, nada disso se aplica. Os bytes são produzidos dentro do processo do navegador, na máquina do usuário, por um código que o usuário pode auditar (a fonte da página é visível). Eles nunca cruzam a rede. O servidor da Absolutool nunca os vê, nunca os registra e não pode vazá-los em uma invasão futura porque nunca os teve. As únicas entidades que veem as senhas geradas são o usuário, qualquer pessoa com acesso à sessão de navegador do usuário (normalmente só o usuário) e quaisquer extensões de navegador rodando na página. Esse é o mesmo modelo de segurança do gerador local de um gerenciador de senhas, e mais forte do que o modelo de qualquer serviço web que retorna senhas geradas a partir de um servidor.

Mirai 2016, o exemplo negativo para padrões de IoT

O exemplo negativo de manual para «vamos simplesmente usar a mesma senha padrão em cada unidade» é a botnet Mirai. A Mirai explorou uma lista codificada de cerca de 62 combinações de usuário/senha padrão de fábrica (admin/admin, root/root, root/xc3511, root/vizxv) para infectar centenas de milhares de câmeras IP, DVRs e roteadores domésticos no fim de 2016, e então as usou em 21 de outubro de 2016 para derrubar o grande provedor de DNS Dyn, tirando do ar brevemente o Twitter, o Reddit, a Netflix e o GitHub. Um gerador de senhas em lote é exatamente a primitiva certa para a alternativa: produzir um padrão forte e único por unidade na linha de produção, imprimi-lo em um adesivo e enviá-lo dentro da caixa.

Mais perguntas

Por que o NIST recomenda comprimento em vez de complexidade?

Porque forçar complexidade (um dígito, um símbolo, uma letra maiúscula) empurra os usuários para padrões previsíveis que o atacante já modelou. O Password1! tem, matematicamente, mais entropia do que password, mas, na prática, a lista de palavras de todo atacante começa por aí. Uma string de 20 caracteres só em minúsculas vinda de um CSPRNG tem ~94 bits de entropia e não pode ser adivinhada por nenhuma lista de palavras, porque não corresponde a uma lista de palavras. A NIST SP 800-63B Rev 4 (julho de 2025) torna a proibição de regras de composição um requisito rígido de NÃO DEVE.

Devo usar frases-senha em vez disso?

Para senhas que você precisa memorizar, sim, foi o que o xkcd #936 (10 de agosto de 2011) defendeu. O método Diceware (Arnold Reinhold, 1995) dá 12,9 bits por palavra a partir de uma lista de 7.776 palavras; seis palavras ≈ 77,5 bits é a recomendação moderna. A EFF lançou listas de palavras atualizadas e compatíveis com o Diceware em julho de 2016. Mas, para o caso de uso de provisionamento em lote que esta ferramenta atende (tokens temporários que são trocados no primeiro login), o ASCII aleatório é a primitiva certa, porque o usuário nunca precisa digitá-lo.

Excluir caracteres ambíguos é um compromisso de segurança?

Sim, tecnicamente: descartar i, l, 1, L, O, 0, o encolhe o alfabeto de 94 para 87, reduzindo a entropia por caractere de 6,55 bits para 6,44 bits. Em 16 caracteres, isso dá 103,0 bits em vez de 104,8 bits, completamente irrelevante. O compromisso compensa quando humanos precisam ler a senha em voz alta ou transcrevê-la de uma folha impressa, que é exatamente o cenário de distribuição em lote que esta ferramenta atende.

Qual é a forma mais segura de distribuir uma lista gerada?

Trate a lista gerada como um artefato de uso único. Distribua por um canal combinado de antemão (e-mail criptografado com PGP/GPG, transferência segura de arquivos, importação para gerenciador de senhas, entrega em mãos para contextos de alto risco). Configure os sistemas para exigir uma troca de senha no primeiro login. Apague o arquivo após a distribuição. Nunca envie listas em texto puro por e-mail, nunca as coloque em controle de versão, nunca as cole em um chat. As senhas geradas são pensadas como tokens de uso único: o valor está na aleatoriedade criptográfica para a entrega inicial, não na retenção de longo prazo.

Ferramentas relacionadas