Um gerenciador de senhas não pensa uma senha do jeito que você pensaria. Para cada caractere, ele pede ao sistema operacional um byte genuinamente aleatório, descarta os que inclinariam o resultado para uma parte do alfabeto e converte o que sobra no conjunto de caracteres que você escolheu. Nada no resultado é pensado para ser memorável, pronunciável ou livre de qualquer coisa que uma pessoa reconheceria como padrão: memorabilidade é exatamente a propriedade que uma boa geração de senhas destrói de propósito.
De onde vem de fato a aleatoriedade?
Não vem de Math.random(). Todo motor de JavaScript traz essa função, e ela é rápida, bem distribuída e completamente errada para esse trabalho: é um algoritmo determinístico com um estado interno pequeno e fixo, e sua saída nunca foi feita para resistir a alguém tentando prevê-la. O V8, o motor por trás do Chrome e do Node, usa um algoritmo chamado xorshift128+, e pesquisadores de segurança já publicaram métodos que funcionam e reconstroem todo o estado interno dele a partir de uma sequência curta de saídas consecutivas; depois disso, toda chamada futura fica previsível, e as que já aconteceram também. O próprio blog técnico da equipe do V8 diz sem rodeios para não usá-lo em nada relacionado a segurança. Um gerador de senhas construído sobre Math.random() não é realmente aleatório: está ofuscado, o que é uma coisa diferente e bem mais fraca.
Um gerador de verdade, incluindo o desta página, chama crypto.getRandomValues() em vez disso. No navegador, essa função se apoia na própria fonte aleatória criptográfica do sistema operacional — /dev/urandom no Linux e no macOS, BCryptGenRandom no Windows —, o mesmo poço de imprevisibilidade que o sistema usa para gerar chaves de criptografia e dados de sessão TLS. O aplicativo de mesa ou de celular de um gerenciador de senhas nativo chama diretamente a API equivalente da plataforma, em vez de passar por um navegador. Ninguém nessa cadeia está inventando aleatoriedade: todo mundo está tirando do mesmo poço que o sistema operacional mantém mexido exatamente para isso.
Por que um byte aleatório não vira um caractere direto?
Porque um byte tem 256 valores possíveis, e um conjunto de caracteres quase nunca divide esse número de forma exata. Pegue o conjunto padrão desta página — minúsculas, maiúsculas, dígitos e símbolos — e o resultado é 86 caracteres. 256 dividido por 86 deixa um resto de 84, então mapear um byte para um caractere com um módulo simples faria os primeiros 84 caracteres do conjunto aparecerem um pouquinho mais do que os dois últimos. O viés é pequeno num único caractere, mas é real e mensurável, e não desaparece conforme a senha fica mais longa: só fica mais difícil de perceber.
A correção é o que os criptógrafos chamam de amostragem por rejeição: tirar um byte e, se ele cair nesse intervalo sobrando de 84 valores, descartá-lo e tirar outro em vez de usá-lo. Isso custa um byte extra de vez em quando e nada mais, e em troca cada caractere da senha final é realmente igual de provável, não só aproximadamente. Um gerador que pula essa etapa produz senhas que são mais fracas do que o comprimento sugere, de um jeito que nenhum medidor de força posterior consegue perceber: o medidor não tem como ver como os caracteres foram escolhidos, só no que eles deram.
O que significam os "bits de entropia" numa senha gerada?
Para uma senha que uma pessoa inventou, a entropia precisa ser estimada, porque o custo real para um atacante depende de quão adivinhável é o padrão por trás dela — esse problema de estimativa é todo o assunto de quanto tempo leva de fato para quebrar uma senha. Para uma senha tirada de forma uniformemente aleatória, a conta é exata em vez de estimada: a entropia é o comprimento da senha multiplicado pelo logaritmo em base 2 do tamanho do conjunto de caracteres. Vinte caracteres desse conjunto de 86 dão pouco mais de 128 bits, e cada um desses bits está fazendo trabalho de verdade, porque o valor de nenhum caractere estava correlacionado com o de nenhum outro na senha.
Por que uma senha que você nunca digita é um modelo de segurança diferente?
Memorizar uma senha obriga a duas concessões que um gerador não precisa fazer: ela tem que ser curta o bastante para caber na sua cabeça e, como lembrar quarenta diferentes não é realista, acaba reutilizada entre sites. A reutilização é o que de fato esvazia a maioria das contas, por credential stuffing e não por força bruta. Um gerenciador que gera e guarda a senha elimina as duas concessões de uma vez: o comprimento deixa de ser um imposto sobre a memória, e uma senha única por site passa de aspiração que ninguém sustenta a ser o padrão.
Isso também muda do que você está se defendendo no dia a dia. O preenchimento automático de um gerenciador de senhas confere a origem exata da página antes de digitar qualquer coisa, então uma página de login falsa e convincente num domínio parecido não consegue nada dele — uma conferência que sua própria memória não consegue fazer, porque você não compara dois nomes de domínio caractere por caractere tão bem quanto um software. Copiar e colar a senha na mão em vez de deixar o preenchimento automático fazer isso joga fora justo essa proteção, porque uma área de transferência não tem a menor ideia de em que página está prestes a ser colada.
O que você ganha em troca é um ponto único de falha que não existia antes: o cofre em si, destravado por uma senha mestra ou uma credencial do dispositivo, e criptografado de algum jeito antes de sincronizar entre os seus dispositivos. Esse cofre agora é o que vale a pena atacar, e é por isso que a senha mestra dele é uma das poucas que ainda vale a pena escolher como uma frase secreta longa e memorizada, em vez de uma string gerada — é a única senha que não tem um cofre próprio para guardá-la. E um cofre que deriva sua chave de criptografia com uma função rápida em vez de uma deliberadamente lenta como o Argon2id tem a mesma fraqueza que um hash puro tem para guardar qualquer senha, algo que vale a pena conferir antes de confiar a um gerenciador tudo o mais que você tem.
O que este gerador não faz
Ele gera, e só. Não guarda histórico do que gerou, não sincroniza nada entre dispositivos e não preenche formulário nenhum por você — fechar a aba descarta a senha junto com tudo mais na página. Isso é uma limitação real diante de um gerenciador de senhas completo, e é também o ponto principal: nada aqui precisa que você confie suas contas a ele, porque ele nunca as guarda por tempo suficiente para que isso importe.
O gerador de senhas usa exatamente o mecanismo descrito acima — crypto.getRandomValues() e amostragem por rejeição — e mostra a entropia resultante e um tempo de quebra ao vivo contra cinco atacantes enquanto você arrasta o controle de comprimento. Nada do que você digita ou gera ali sai da página.
Para o punhado de credenciais que você não pode entregar a um gerenciador, como a senha mestra que protege o próprio cofre, senha ou frase secreta mostra quando uma frase memorizada realmente ganha de uma string aleatória, e quando não ganha.
Perguntas frequentes
Por que o Math.random() não é seguro para gerar uma senha?
É um algoritmo determinístico com um estado interno pequeno e fixo, e sua saída nunca foi feita para resistir a previsão. Pesquisadores já publicaram métodos que funcionam para reconstruir esse estado interno a partir de uma sequência curta de saídas consecutivas da implementação do V8, e a partir daí toda chamada futura fica previsível. Uma senha construída com isso é tão segura quanto esse estado continuar em segredo, e normalmente não continua.
O que é amostragem por rejeição, e por que um gerador de senhas precisa dela?
É a técnica de descartar um byte aleatório e tirar outro sempre que esse byte cai num intervalo que deixaria alguns caracteres um pouco mais prováveis do que outros. Um byte tem 256 valores possíveis, e um conjunto de caracteres raramente divide 256 de forma exata, então sem essa etapa a saída de um gerador parece aleatória, mas está enviesada de forma mensurável para uma parte do conjunto.
Uma senha gerada me protege sozinha contra phishing?
Só de forma indireta, através do gerenciador que a guarda. O preenchimento automático de um gerenciador de senhas confere o domínio exato antes de digitar qualquer coisa, então ele não faz nada numa página de login falsa e convincente — uma conferência que a sua memória não consegue fazer. Copiar e colar a senha na mão em vez de deixar o preenchimento automático fazer isso joga essa proteção fora.
Como se calcula a entropia de uma senha gerada?
É o comprimento da senha multiplicado pelo logaritmo em base 2 do tamanho do conjunto de caracteres — por exemplo, 20 caracteres tirados de um conjunto de 86 dão pouco mais de 128 bits. Esse número é exato, não estimado, porque supõe que cada caractere foi escolhido de forma uniformemente aleatória, o que só é verdade para uma senha que um gerador produziu, não uma que uma pessoa inventou.
Esta ferramenta é, ela mesma, um gerenciador de senhas?
Não. Ela gera uma senha e mostra a entropia e o tempo de quebra dela, e nada do que produz é guardado, sincronizado ou preenchido automaticamente num formulário. Fechar a aba descarta a senha. Você ainda precisa de um gerenciador de senhas de verdade para guardá-la, preenchê-la automaticamente e obter a proteção de conferência de domínio que vem junto disso.
Última atualização 24 de setembro de 2026
