Verificador de força de senha gratuito

Como a força da senha é calculada

A força de uma senha é a resposta a uma pergunta simples com resposta complicada: quantas tentativas um atacante precisa para descobrir sua senha? A fórmula ingênua, bits de entropia = comprimento × log₂(tamanho do conjunto de caracteres), dá um limite superior limpo, mas presume que o atacante faz força bruta pura sobre todo o espaço de chaves. Atacantes reais não fazem isso. Eles começam com dicionários de senhas prováveis (o corpus rockyou.txt e o top milhão de vazamentos públicos), aplicam regras de transformação que imitam as substituições que humanos realmente fazem (l33t-speak, primeira letra em maiúscula, anexar 1 ou ! ou um ano de quatro dígitos), e só recorrem à força bruta quando os padrões não encaixam. Um medidor por classes de caracteres vê P@$$w0rd99 como tendo as quatro classes e pontua alto. Um cracker real quebra em segundos porque todo padrão nela está na lista de regras de topo.

Esta ferramenta reporta os dois números, a entropia ingênua a partir do conjunto de caracteres e do comprimento, mais uma pontuação de força separada que penaliza padrões reconhecíveis (palavras de dicionário, passeios de teclado como a linha inferior «zxcvbn», repetições, sequências, datas) como faria um atacante informado. Os dois números divergirão quando sua senha contiver estrutura previsível, que é precisamente quando você mais precisa saber.

Uma breve história da segurança de senhas

Os computadores nem sempre tiveram senhas. Antes da chegada do time-sharing no início dos anos 1960, um «computador» era uma máquina monousuário e o modelo de segurança era uma porta trancada. A história mainstream da senha de computador começa no Project MAC do MIT, onde o Compatible Time-Sharing System (CTSS) de Fernando Corbató tornou uma máquina utilizável por muitas pessoas ao mesmo tempo. Uma vez que vários usuários partilhavam um sistema de arquivos, podiam ler os arquivos uns dos outros. Corbató é geralmente creditado com a introdução do prompt de senha como a solução mais simples possível: um segredo partilhado entre usuário e máquina que provava que você tinha direito aos arquivos que estava pedindo. A data exata é contestada entre fontes secundárias (entre 1960 e 1963), mas em meados dos anos 1960 a senha tinha se tornado uma característica padrão dos sistemas multiusuário, e Multics, o sucessor mais ambicioso do CTSS que começou a operar em 1965, herdou e estendeu substancialmente o design de Corbató.

O próximo momento fundador é novembro de 1979, quando Robert Morris e Ken Thompson nos Bell Laboratories publicam «Password Security: A Case History» em Communications of the ACM. O artigo é curto, menos de cinco páginas, e quase embaraçosamente prático. Duas ideias dele se tornaram a base de qualquer armazenamento sério de senhas construído depois. Primeiro, o hashing unidirecional: em vez de armazenar a senha em si, o sistema armazena um valor fácil de calcular a partir da senha mas praticamente impossível de inverter. Segundo, o salting: anexar um valor aleatório de 12 bits a cada senha antes de hashear, para que dois usuários com a mesma senha produzam hashes armazenados diferentes e um atacante não consiga pré-computar um único dicionário de hashes que funcione contra todos. Morris e Thompson notaram que isso multiplicava o trabalho de atacar um arquivo de senhas roubado por 4.096, por 2¹², o tamanho do espaço de sal. Toda discussão sobre bcrypt, scrypt e argon2id nos quarenta anos desde então é em certo sentido uma nota de rodapé sobre Morris e Thompson.

De onde vem o número de entropia

A unidade de medida é o bit de entropia, e vem do artigo de Claude Shannon de 1948 «A Mathematical Theory of Communication», publicado em duas partes no Bell System Technical Journal. O artigo de Shannon inventou o campo da teoria da informação e deu ao mundo o termo «bit», que Shannon atribuiu a John Tukey. Traduzido para o contexto de senhas, a entropia de uma senha é log₂ do número de senhas distintas que o mesmo processo poderia ter produzido. Se um gerador escolhe cada caractere de forma independente e uniforme de um conjunto de R caracteres possíveis e produz uma senha de comprimento L, então há R^L senhas igualmente prováveis e a entropia é L × log₂(R) bits. Uma senha escolhida uniformemente entre os 95 caracteres ASCII imprimíveis com comprimento 12 carrega cerca de 78,8 bits. Cada bit adicional dobra o trabalho do atacante; a relação é exponencial, por isso uma extensão de dois caracteres a uma senha aleatória importa muito mais que um único caractere substituído. A ressalva, e é uma ressalva grande, é que senhas reais quase nunca são produzidas por amostragem aleatória uniforme. As pessoas escolhem aniversários, nomes de parceiros, palavras de dicionário, padrões de teclado e sequências. A fórmula ingênua é portanto um limite superior sobre a força, geralmente bem folgado.

NIST e a mudança de paradigma de 2017

Durante décadas a voz institucional dominante sobre regras de senhas nos EUA foi o NIST, o National Institute of Standards and Technology. Suas publicações anteriores nos deram a sabedoria popular atual sobre política de senhas: mínimo de oito caracteres, mistura de maiúsculas e minúsculas, deve conter um dígito, deve conter um símbolo. Essa orientação foi amplamente copiada em políticas de TI corporativas muito depois de a comunidade de pesquisa em segurança ter concluído que era ativamente contraproducente. Em 2017, na NIST Special Publication 800-63B, a agência reverteu formalmente as partes mais dolorosas da orientação antiga. Mudanças chave: nada de mudanças periódicas forçadas a menos que haja evidência de que a senha foi comprometida, estudos mostraram que reinícios obrigatórios de noventa dias fazem com que os usuários escolham senhas mais fracas e previsíveis (capitalizar uma letra e adicionar 1 é o exemplo canônico), derrotando o propósito mesmo da rotação. Nada de regras de composição obrigatórias, verificadores não devem exigir classes de caracteres particulares, porque empurram os usuários para substituições previsíveis como P@ssw0rd! em vez de senhas mais fortes. O comprimento é o fator dominante. Verificar senhas contra listas de vazamentos conhecidos, a mudança operacional mais consequente, e a razão pela qual o corpus Pwned Passwords do Have I Been Pwned existe na sua forma atual. O NIST publicou a versão final da próxima revisão maior, SP 800-63B-4, em 31 de julho de 2025, reforçando a direção de 2017 e estendendo-a a autenticadores resistentes a phishing (incluindo autenticadores sincronizáveis do tipo usado pelos passkeys).

zxcvbn, por que medidores modernos se parecem

A razão pela qual a maioria dos medidores sérios de força de senha se parecem na superfície é que a maioria executa, ou se inspira em, o mesmo pedaço de código. Esse código é zxcvbn, um estimador open-source consciente de padrões publicado originalmente por Daniel Lowe Wheeler na Dropbox em abril de 2012 e mais tarde formalizado num artigo revisado por pares no 25º USENIX Security Symposium em agosto de 2016. O nome é em si uma piada, é a linha inferior de um teclado QWERTY, o tipo de senha que a biblioteca foi projetada para reconhecer e penalizar. zxcvbn detecta correspondências de dicionário contra cerca de 30.000 senhas comuns mais nomes e sobrenomes do censo dos EUA, palavras inglesas populares, tokens da Wikipédia e títulos de cinema/TV dos EUA; substituições leet-speak (então p@ssw0rd é tratada como password); passeios de teclado como qwertyuiop e asdfghjkl; repetições (aaaa, abcabcabc); sequências (abcdef, 12345); e datas dentro de faixas humanas plausíveis. Depois computa a decomposição de mínimo de tentativas, a combinação mais barata de padrões reconhecidos que explica toda a senha, e multiplica as contagens de tentativas por padrão para estimar o total de tentativas que um atacante informado precisaria. A biblioteca é implantável em navegador mas não leve: empacotada e minificada, zxcvbn pesa cerca de 400 KB em gzip, a maior parte sendo os próprios dicionários. Isso é pequeno o suficiente para uma página de propósito único como esta mas pesado o suficiente para que os mantenedores alertem explicitamente contra incluí-la em cada página de um app web generalista.

O que «tempo para quebrar» realmente significa

Todo medidor de força mostra uma estimativa de «tempo para quebrar», incluindo este. A resposta honesta é que esse é um dos números mais fáceis de reportar e um dos mais difíceis de defender, porque depende quase totalmente de suposições que o usuário não pode ver. A suposição base é as tentativas por segundo do atacante. Esse número não é um único número, é uma faixa de cerca de dez ordens de magnitude conforme o que o atacante roubou e que esquema de hash o defensor usou. MD5 ou SHA-1 sem sal: uma única NVIDIA RTX 4090, placa gráfica de consumo de 2022, pode calcular da ordem de 150 a 165 bilhões de hashes MD5 por segundo usando a ferramenta de quebra padrão hashcat. Oito placas dessas num único rig empurram o número para além de um trilhão por segundo; instâncias multi-GPU alugadas na nuvem na AWS ou Google Cloud custam alguns dólares a algumas dezenas de dólares por hora. Para qualquer armazenamento de senhas que use hash rápido sem sal, senhas modestas estão essencialmente indefesas. bcrypt em fatores de custo sensatos: bcrypt foi projetado em 1999 especificamente para ser lento em hardware paralelo. No fator de custo 12 (o default aproximado da indústria), uma única GPU pode fazer centenas a alguns milhares de tentativas por segundo por núcleo, não dezenas de bilhões. O tempo de quebra contra bcrypt é milhões de vezes mais longo que contra MD5. scrypt e argon2id: esses adicionam dureza de memória, cada tentativa requer não só ciclos de CPU mas uma quantidade substancial de RAM, o que torna a paralelização em GPUs e ASICs proibitivamente cara em parâmetros sensatos. Argon2id é a recomendação atual da OWASP e vencedor do Password Hashing Competition de 2015.

Um medidor que cita um único tempo de quebra te dá, no melhor caso, a resposta para o pior cenário em que o atacante roubou uma base de hashes rápidos. Esse também é o único default honesto para um medidor de força genérico exibir, um usuário não pode saber antecipadamente se o próximo serviço pirateado terá usado MD5 ou argon2id. As 10 bilhões de tentativas por segundo que esta ferramenta presume estão na mesma ordem de magnitude que o pior cenário hash-rápido, uma ordem de magnitude abaixo do pico absoluto de um rig de topo mas representativo do que um atacante determinado pode alugar por um orçamento pequeno.

O vazamento RockYou de 2009 e por que reutilizar mata

RockYou, fabricante de add-ons para Facebook e MySpace, armazenava cerca de 32 milhões de senhas de usuário em texto plano. Em dezembro de 2009 um atacante explorou uma vulnerabilidade de SQL injection e exfiltrou toda a base de usuários. As senhas em texto plano foram publicadas publicamente. A lista de palavras deduplicada, rockyou.txt, com cerca de 14 milhões de senhas únicas, é agora o dicionário inicial padrão para quase qualquer ferramenta de quebra de senha no mundo. Toda senha que apareceu nesse vazamento é, para efeitos práticos, instantaneamente quebrável para sempre, não importa quão forte parecesse sua entropia ingênua. Essa é também a razão pela qual a reutilização de senhas é o maior risco prático para a maioria das contas de usuário. Um usuário que reutiliza a mesma senha em cinquenta sites só precisa que um vaze; um usuário com senha única por serviço precisa que os cinquenta vazem. O dataset de referência para senhas vazadas é o Have I Been Pwned, lançado pelo pesquisador australiano de segurança Troy Hunt em 4 de dezembro de 2013. O subsistema Pwned Passwords indexa mais de um bilhão de hashes SHA-1 únicos de senhas comprometidas, com cerca de 1,3 bilhão de senhas recém-vistas adicionadas só na atualização de novembro de 2025.

k-anonimato, verificar uma senha sem revelá-la

A parte engenhosa do Pwned Passwords é o design da API, que resolve o que historicamente foi um sério problema de privacidade: como você deixa um terceiro verificar se uma senha está numa lista de vazamentos conhecidos sem enviar a sua senha? A abordagem ingênua, POSTar sua senha ao serviço, recria precisamente o problema que o usuário tentava evitar. A solução de k-anonimato, projetada por Junade Ali na Cloudflare em 2018, funciona assim: o cliente computa o hash SHA-1 da senha; o cliente envia apenas os primeiros cinco caracteres hex desse hash (um prefixo que identifica um de cerca de um milhão de baldes possíveis); o servidor retorna todos os sufixos para hashes que começam com esse prefixo, tipicamente algumas centenas de correspondências; o cliente verifica localmente se o hash completo está na lista retornada. O servidor nunca aprende qual senha o usuário está verificando; só aprende um de cerca de um milhão de baldes de prefixo, o que por si só identifica centenas de senhas plausíveis. Esse é o mesmo modelo de anonimato estatístico usado para anonimizar registros médicos: cada consulta é estatisticamente indistinguível de pelo menos k outras. Gerenciadores de senhas de navegador, sistemas de identidade empresarial e medidores de força sérios usam o mesmo protocolo prefixo-e-sufixo.

Use um gerenciador de senhas

O argumento a favor de gerenciadores de senhas não é que eles te tornem imune a vazamentos, não tornam, e vários foram eles mesmos pirateados, mas que te permitem ter uma senha única em cada serviço, para que o próximo vazamento de um serviço que você usa não comprometa também sua conta bancária. KeePass, o mais antigo dos gerenciadores amplamente usados, foi publicado por Dominik Reichl pela primeira vez em novembro de 2003. 1Password, da AgileBits, lançou sua primeira versão em 2006. Bitwarden, o gerenciador dominante open-source com sincronização em nuvem, foi lançado em agosto de 2016. A recomendação moderna, memorize uma única passphrase mestre forte, deixe o gerenciador gerar todo o resto, é compartilhada por NIST, OWASP, EFF e essencialmente toda organização de segurança séria. A passphrase mestre única se torna a única senha que você precisa lembrar bem; o gerenciador cuida do resto, gera strings aleatórias de 20 caracteres por serviço, preenche por você, e te avisa quando reutiliza uma. Se você guardar um único conselho de toda esta página, guarde esse.

Passphrases para o que você tem que lembrar

Para as senhas que você realmente tem que memorizar, a passphrase mestre do seu gerenciador, o login do seu computador, o desbloqueio do seu telefone, passphrases ganham de senhas. XKCD #936 («Password Strength»), publicado em 10 de agosto de 2011, levou o argumento a uma audiência ampla: correct horse battery staple são quatro palavras inglesas aleatórias, mais fáceis de memorizar para um humano que Tr0ub4dor&3 e ordens de magnitude mais difíceis para um computador adivinhar. A matemática é direta: se você tira palavras uniformemente de uma lista de tamanho N, cada palavra contribui log₂(N) bits de entropia. O sistema Diceware, inventado por Arnold Reinhold em 1995 e originalmente distribuído na mailing list Cypherpunks, formaliza isso com uma lista de 7.776 palavras (cada palavra é selecionada por cinco lançamentos de um dado de seis lados). Cada palavra Diceware contribui cerca de 12,9 bits de entropia; uma passphrase de seis palavras carrega cerca de 77 bits, que Reinhold recomendou como piso para uso cotidiano. A Electronic Frontier Foundation publicou sua própria lista melhorada de palavras longas em julho de 2016, com palavras escolhidas por memorabilidade e comprimento (em média sete caracteres contra ~4,3 do Diceware). A segurança da lista EFF e da lista Diceware original é idêntica para o mesmo número de palavras; a lista EFF é só mais agradável de viver. A ressalva crucial é que as palavras precisam ser realmente aleatórias, escolhidas por dados ou um RNG real. Uma passphrase tirada de uma letra de música, citação de filme ou versículo bíblico famoso está na lista de palavras de qualquer atacante de dicionário e não é mais forte que uma única palavra de dicionário.

Passkeys: o substituto a longo prazo

A direção de viagem a longo prazo é que contas de alto valor estão deixando o mundo das senhas por completo. Em 5 de maio de 2022, Apple, Google e Microsoft anunciaram conjuntamente suporte expandido ao padrão FIDO e um fluxo de login sem senha baseado em passkey que se sincroniza entre dispositivos e plataformas. Um passkey é uma credencial de chave pública guardada no dispositivo do usuário; a chave privada nunca deixa o dispositivo, a chave pública é registrada com a parte verificadora, e a autenticação é um desafio-resposta criptográfico imune ao phishing de uma forma que senhas categoricamente não são. A FIDO Alliance reportou no início de 2025 que mais de quinze bilhões de contas online já podiam usar passkeys, e que a adoção tinha dobrado só em 2024. O Google reportou no final de 2024 que mais de 800 milhões de contas Google tinham pelo menos um passkey configurado, com taxas de sucesso de login subindo cerca de 30 % e velocidade de login subindo cerca de 20 % em média. As plataformas maiores, Amazon, Apple iCloud Keychain, Google Password Manager, Microsoft Authenticator, todas suportam passkeys sincronizados hoje. Passkeys ainda não são um substituto completo (muitos sites menores não os suportam, e a história de recuperação ainda varia por plataforma), mas para qualquer conta que os suporte, incluindo cada vez mais email, redes sociais, banca e plataformas SaaS maiores, um passkey é a resposta correta e uma senha forte é uma segunda escolha razoável.

Privacidade: por que importa um verificador só-navegador

Toda ferramenta «teste sua senha» que envia a senha a um servidor é, por construção, um risco. Isso inclui a maioria dos medidores históricos de senhas que faziam sua análise no lado servidor. O padrão correto para uma ferramenta moderna, o padrão que esta página segue, é que a senha nunca deixe seu navegador. O estimador de força roda localmente; a cifra de entropia é computada localmente; as sugestões são geradas localmente. Nada é registrado, nada é armazenado, nada cruza a rede. Esse é o argumento de privacidade que vale a pena fazer claramente. É o único argumento para uma ferramenta de senhas que distingue verdadeiramente uma implementação confiável de uma descuidada. Um usuário que não controla o código-fonte de um medidor de força não pode estar seguro de que sua senha não está sendo registrada, mas pelo menos pode olhar a atividade de rede nas ferramentas de desenvolvedor do navegador, e uma ferramenta que não faz requisições de rede quando o usuário digita é verificável em segundos. Isso faz com que «roda inteiramente no seu navegador» não seja apenas uma afirmação de marketing mas uma afirmação falsificável, que é uma espécie de afirmação muito melhor. Mesmo com essa garantia, a prática mais segura ainda é testar uma senha estruturalmente similar em vez da real, mesmo comprimento, mesma mistura de caracteres, mesmos padrões, para qualquer senha que você usa hoje.

Sete conclusões

1. Comprimento domina. Doze caracteres é o mínimo prático; dezesseis ou mais é o piso correto para contas importantes. Cada caractere adicional aproximadamente dobra a superfície de ataque por força bruta.
2. Regras de composição são teatro. Uma passphrase longa ganha de uma string curta de mixed-case-mais-dígitos-mais-símbolos em qualquer medida honesta.
3. Reutilização é a superfície de ataque dominante. Uma única senha vazada se torna chave para todo serviço que a compartilhe.
4. Um gerenciador de senhas é a resposta para a maioria das pessoas. Memorize uma passphrase forte, deixe o gerenciador cuidar do resto.
5. Passkeys, onde suportados, são melhores que qualquer senha. São resistentes ao phishing por design e se sincronizam entre os dispositivos do usuário.
6. Um medidor de força é um estimador, não uma garantia. Presume um modelo de ataque particular; atacantes reais podem fazer melhor contra senhas cheias de padrões do que o número do medidor sugere.
7. Confie na afirmação de privacidade de um medidor apenas se conseguir verificá-la. Um medidor que roda inteiramente no navegador pode ser verificado por qualquer usuário com as ferramentas de desenvolvedor abertas. Um medidor que posta para um servidor não pode.

Perguntas frequentes

Minha senha é enviada para um servidor?

Não. Toda a análise acontece no seu navegador. Sua senha nunca sai do seu dispositivo.

Quantos caracteres minha senha deve ter?

Pelo menos 12 caracteres para a maioria das contas, 16 ou mais para as importantes (banco, e-mail, gerenciadores de senhas). Quanto mais longa, melhor.

Uma frase-senha é melhor que uma senha aleatória?

Uma frase-senha (como "correct-horse-battery-staple") pode ser muito forte se for longa o suficiente (4 ou mais palavras aleatórias). São mais fáceis de lembrar, mas devem ser realmente aleatórias · não letras de músicas ou citações.

Por que esta ferramenta mostra pontuação diferente de outro medidor?

Porque medidores diferentes usam modelos diferentes. Um medidor ingênuo por classes de caracteres vê P@$$w0rd99 como tendo as quatro classes e pontua alto; um medidor consciente de padrões (modelado na biblioteca open-source zxcvbn da Dropbox) reconhece a palavra de dicionário, as substituições leet-speak e o padrão de dígitos no sufixo, e pontua como quebrável em segundos. Esta ferramenta reporta os dois, entropia ingênua a partir do comprimento e conjunto de caracteres, mais uma pontuação consciente de padrões que penaliza estruturas reconhecíveis. As duas divergirão quando sua senha contiver padrões previsíveis, que é exatamente quando o aviso é mais útil.

Devo confiar na estimativa de tempo de quebra?

Como ordem de magnitude do pior caso, sim. As 10 bilhões de tentativas por segundo que esta ferramenta presume estão na mesma ordem de magnitude que um atacante determinado com uma única GPU recente quebrando MD5 ou SHA-1 sem sal (um RTX 4090 pode fazer 150-165 bilhões de MD5/seg; um rig pequeno empurra isso para os trilhões). Para serviços que usam hashing moderno correto (bcrypt em fator de custo 12, scrypt, argon2id), o ataque real seria milhões de vezes mais lento, mas você não tem como saber antecipadamente que esquema de hash o próximo serviço pirateado usou, então planejar para o pior caso é prudente.

E para verificar se minha senha esteve em um vazamento?

Para isso, use o serviço Pwned Passwords do Have I Been Pwned (haveibeenpwned.com/Passwords). Usa um modelo de k-anonimato projetado por Junade Ali na Cloudflare em 2018: seu navegador computa o SHA-1 da sua senha, envia apenas os primeiros cinco caracteres hex, e o servidor retorna todos os sufixos correspondentes, sua senha completa e seu hash completo nunca cruzam a rede. O corpus contém mais de um bilhão de hashes SHA-1 vazados conhecidos. Gerenciadores de senhas de navegador (Watchtower do 1Password, relatório de vazamento de dados do Bitwarden, Password Checkup do Chrome) integram automaticamente a mesma API.

Ferramentas relacionadas