Como escolher e testar uma senha forte

Entropia: a única medida honesta

A força de uma senha é o número de tentativas que um atacante precisa fazer, em média, para adivinhá-la. Contar esse número diretamente é inviável, então usamos o seu logaritmo na base 2, a entropia, em bits. Cada bit dobra o espaço de busca: 40 bits são cerca de um trilhão de combinações; 80 bits são um trilhão de trilhões. O ponto que quase todo tutorial erra é este: a entropia não é uma propriedade da string. É uma propriedade do processo que a gerou. A mesma sequência de caracteres pode valer 3 bits ou 60, dependendo de como você chegou até ela.

A fórmula sai de contar combinações: se você sorteia L símbolos independentes, cada um de um conjunto de R opções, há R^L senhas possíveis, e log2(R^L) = L × log2(R). Repare na palavra “sorteia”. A conta só vale com aleatoriedade uniforme, um dado, um gerador criptográfico, nunca a sua cabeça. Quando uma pessoa escolhe, ela concentra probabilidade em pouquíssimos resultados (nomes, datas, o padrão maiúscula-no-início-número-no-fim), e o atacante começa por eles. A entropia real vira o logaritmo da posição da sua senha na lista de tentativas de um bom atacante, não o log do tamanho teórico do conjunto.

O gráfico conta a história inteira. Oito caracteres minúsculos aleatórios dão só 37,6 bits, dentro da faixa “fraca” de qualquer medidor. Adicionar tipos de caractere ajuda (alfanumérico sobe para 47,6), mas o salto grande vem do comprimento: doze caracteres com símbolos chegam a 78,8 bits, e, a parte contraintuitiva, seis palavras aleatórias de uma lista Diceware alcançam praticamente o mesmo (77,5 bits) sendo muito mais fáceis de lembrar. Agora o exemplo que abre o artigo, feito com números.

// "P@ssw0rd!" tratada como aleatória / treated as random
L = 9 caracteres, R = 95 (minúscula + maiúscula + dígito + símbolo)
H = 9 × log2(95) = 9 × 6,5699 ≈ 59,1 bits   ← o que a conta ingênua diz

// "P@ssw0rd!" como o que realmente é / as what it actually is
base = "password"  (entre as ~20 senhas mais vazadas do mundo)
regra = capitaliza + a→@ + o→0 + acrescenta "!"  (a mangling mais comum)
um ataque de dicionário+regras chega nela em ~16 tentativas
H_real ≈ log2(16) ≈ 4 bits   ← o que um atacante realmente gasta

Por que comprimento vence complexidade

Na fórmula, comprimento e alfabeto entram de formas diferentes. Aumentar o alfabeto R cresce a base uma única vez: passar de minúsculas (26) para todos os símbolos imprimíveis (95) multiplica o espaço por um fator fixo, some. Aumentar o comprimento L eleva a potência, e você pode fazer isso sem teto. Cada caractere aleatório a mais multiplica o espaço inteiro por R de novo. Por isso a complexidade se esgota rápido e o comprimento não.

Leia a tabela na diagonal. Todos os símbolos do teclado somam, no máximo, cerca de 22 bits a uma senha de 12 caracteres (de 56,4 minúsculas para 78,8), e cobram esse preço em memorização e erros de digitação. Já quatro minúsculas a mais (de 12 para 16) somam 18,8 bits, e nada impede você de somar outras quatro, e mais quatro. Uma senha de 16 minúsculas (75,2 bits) já supera qualquer senha de 8 caracteres, por mais símbolos que ela tenha (52,6 bits). A complexidade é um bônus de uma vez; o comprimento é uma esteira que não acaba.

Passphrase Diceware: fácil de lembrar, difícil de quebrar

Se comprimento aleatório vence, o desafio é gerar comprimento que um humano consiga lembrar. A resposta é o Diceware, método publicado por Arnold Reinhold em 1995: você rola cinco dados de seis faces, lê o resultado numa lista numerada e obtém uma palavra; repita algumas vezes e junte as palavras. Como cada palavra vem de uma lista de exatamente 6^5 = 7.776 entradas, cada uma acrescenta log2(7.776) ≈ 12,9 bits, e, crucialmente, esses bits são reais porque o sorteio é uniforme (os dados não têm preferência). A lista longa da EFF, de 2016, tem essas 7.776 palavras escolhidas para serem comuns, fáceis de digitar e sem nenhuma ser prefixo de outra.

7.776 palavras

O tamanho da lista, igual a 6^5, o número de resultados de cinco dados de seis faces, para sortear uma palavra por rolagem sem viés.

≈ 12,9 bits por palavra

log2(7.776). É quanto de entropia cada palavra sorteada acrescenta, desde que sorteada de verdade, com dados ou um gerador criptográfico.

Propriedade de prefixo

Nenhuma palavra da lista da EFF é começo de outra, então a passphrase é lida sem ambiguidade mesmo escrita sem espaços.

Vale comparar de frente uma passphrase de seis palavras com uma senha aleatória de doze caracteres, o outro extremo popular:

// Passphrase Diceware de 6 palavras / 6-word Diceware passphrase
H = 6 × log2(7776) = 6 × 12,925 ≈ 77,5 bits
exemplo: "correto-cavalo-bateria-grampo-limao-trilho"

// Senha aleatória de 12 caracteres com símbolos / random 12-char with symbols
H = 12 × log2(95) = 12 × 6,5699 ≈ 78,8 bits
exemplo: "9x!Kd2#vQ7@m"

// Praticamente empatadas em bits, mas só uma delas você decora.

O que o NIST mudou, e por quê

A “regra de complexidade”, pelo menos uma maiúscula, um número e um símbolo, troque a senha a cada 90 dias, não caiu do céu. Ela tem autor e data, e o próprio órgão que a popularizou já a abandonou. O documento que hoje define as boas práticas é o NIST SP 800-63B, cuja revisão vigente é a SP 800-63B-4, finalizada em julho de 2025. Ela desmonta, item por item, a cartilha que ensinamos por vinte anos.

1. 2003Nasce a regra de complexidade

   Um apêndice do NIST (SP 800-63, memorando atribuído a Bill Burr) recomenda misturar tipos de caractere e trocar a senha com frequência. Vira lei corporativa no mundo todo.

2. 2017A revisão 3 volta atrás

   O SP 800-63B (rev. 3) abandona as regras de composição e a expiração periódica, com base em pesquisas que mostraram que elas produziam senhas piores. Burr admite publicamente que se arrependeu do conselho original.

3. 2025A SP 800-63B-4 consolida

   A quarta revisão, final, sobe o mínimo recomendado para 15 caracteres quando a senha é o único fator, exige comparação contra listas de senhas vazadas e reforça que regras de composição e expiração periódica não devem ser impostas.

A lógica por trás de todas as linhas é a mesma que abre este guia. Regras de composição e trocas forçadas não aumentam a aleatoriedade, elas restringem o comportamento humano a padrões, e padrão é o que o atacante mapeia primeiro. Exigir um símbolo faz quase todo mundo colocá-lo no fim; exigir troca trimestral faz quase todo mundo incrementar um número. O NIST trocou “force o usuário a complicar” por “deixe o usuário alongar e bloqueie o que já vazou”. É a diferença entre combater a matemática do atacante e alimentá-la.

Como testar (e o que o medidor calcula)

Um medidor honesto não conta caracteres: ele estima a entropia e depois desconta os bits que a senha entrega de graça. O analisador de força de senha deste site faz exatamente isso, e é bom saber o que ele calcula por baixo, não é o zxcvbn do Dropbox, e sim um primo mais leve, no mesmo espírito. Primeiro estima a entropia ingênua pelo conjunto de caracteres detectado (comprimento × log2 do tamanho do conjunto). Depois aplica penalidades: subtrai bits ao ver sequências, repetições, padrões de teclado, datas e leetspeak de palavras comuns, e zera a pontuação quando a senha aparece numa lista embutida das mais vazadas. O zxcvbn, apresentado por Daniel Wheeler na USENIX Security 2016, leva essa ideia mais longe, casando a senha contra dicionários e estimando o número de tentativas de vários ataques reais; a lição comum aos dois é a mesma: a força é o log das tentativas que um bom atacante gasta, não do tamanho teórico do conjunto.

• Priorize comprimento: 15+ caracteres aleatórios ou 5–6 palavras Diceware sorteadas.
• Não conte com leetspeak nem com o padrão maiúscula-no-início-número-no-fim.
• Uma senha única por site, guardada num gerenciador, nunca reutilize.
• Cheque se ela já vazou (via k-anonymity) e evite qualquer senha da blocklist.
• Ligue um segundo fator: passkey de preferência, depois TOTP de app; evite SMS.
• Digite senhas reais só em ferramentas locais, que não enviam nada ao servidor.

Depois de escolher: guardar e reforçar

Escolher uma boa senha é metade do trabalho; a outra metade é como ela vive dos dois lados. No seu, use um gerenciador para ter uma senha longa e única por serviço, gerada pelo gerador de senhas, assim o vazamento de um site não contamina os outros. No lado de quem armazena, a senha nunca pode ficar em texto claro: ela vira um hash com salt por uma função deliberadamente lenta (bcrypt, scrypt, Argon2), como mostra o gerador de bcrypt. O guia hashing, criptografia e encoding explica por que essa lentidão é uma defesa, e não um defeito.

É aqui que o tempo de quebra ganha sentido, e onde é fácil inventar número. O analisador deste site estima o tempo dividindo as tentativas necessárias por perfis de atacante: um formulário limitado (cerca de 100 tentativas por hora), um serviço sem limite (dezenas por segundo), um hash lento offline (~10 mil/s, o caso do bcrypt bem configurado), um hash rápido numa GPU (~10 bilhões/s) e um cluster de GPUs (~1 trilhão/s). Esses são os perfis de referência do medidor em 2026, não a medição de uma placa específica, a velocidade real depende inteiramente do algoritmo de hash da senha no servidor. Um bcrypt com custo alto é ordens de magnitude mais lento de atacar que um SHA-256 puro, e é por isso que a escolha do hash importa tanto quanto a escolha da senha. Para dar ordem de grandeza: uma passphrase de 77,5 bits exige, em média, cerca de 2^76,5 ≈ 10^23 tentativas; mesmo ao ritmo do cluster (10^12/s), isso passa de milhares de anos. Já os 37,6 bits de oito minúsculas caem em uma fração de segundo no mesmo cluster.

Por fim, ligue a verificação em duas etapas. Mesmo que uma senha vaze, um segundo fator impede o acesso, mas nem todo segundo fator é igual. Prefira uma passkey, que resiste a phishing por amarrar a assinatura à origem do site; onde ela não existir, use um código TOTP de app, como o do gerador de TOTP, em vez de SMS, que pode ser desviado por troca de chip. É a camada que transforma um vazamento em um susto, não em uma invasão, a mesma lógica de defesa em profundidade que blinda um domínio inteiro no guia de SPF, DKIM e DMARC.