Entropia de senhas: a matemática real de por que o comprimento vence a complexidade
O conselho sobre senhas está travado há duas décadas em alguma versão de «use maiúscula, minúscula, um número e um símbolo». A matemática diz que isso é em sua maior parte errado — ou pelo menos muito mal priorizado. A força de uma senha gerada aleatoriamente é governada por uma única fórmula, e essa fórmula recompensa o comprimento muito mais agressivamente do que recompensa um conjunto de caracteres maior. Isso também, não por coincidência, é o que o NIST vem dizendo desde o SP 800-63B (2017, revisado em 2024).
Este artigo percorre a matemática real, calcula valores concretos de entropia, fornece estimativas de força bruta com premissas explicitamente declaradas, e então traduz tudo em regras que você pode aplicar.
A fórmula da entropia
Para uma senha extraída uniformemente ao acaso de um conjunto de caracteres de tamanho P, com comprimento L, o número de senhas possíveis é P^L, e a entropia em bits é:
H = log2(P^L) = L × log2(P)Esse é o modelo inteiro. A entropia mede o tamanho do espaço de busca que um atacante precisa enumerar. Cada bit adicional dobra o trabalho.
As duas alavancas são P (tamanho do conjunto) e L (comprimento), e elas não são iguais. Adicionar um caractere multiplica o espaço de busca por P; ampliar o conjunto multiplica por uma razão. Aqui estão os conjuntos que importam e suas contribuições de entropia por caractere:
| Conjunto de caracteres | Tamanho (P) | Bits por caractere, log2(P) |
|---|---|---|
Apenas dígitos (0–9) | 10 | 3.32 |
Apenas minúsculas (a–z) | 26 | 4.70 |
Minúsculas + maiúsculas (a–zA–Z) | 52 | 5.70 |
Alfanumérico (a–zA–Z0–9) | 62 | 5.95 |
| ASCII imprimível completo (94 caracteres incl. símbolos) | 94 | 6.55 |
Note os retornos decrescentes ao ampliar o conjunto: ir de apenas minúsculas (26) para o conjunto imprimível completo (94) quase quadruplica o conjunto mas só eleva a entropia por caractere de 4.70 para 6.55 bits — um ganho de 39 % por caractere. Ir de 8 para 16 caracteres em qualquer tamanho de conjunto exatamente dobra a entropia. O comprimento escala linearmente sem teto; o tamanho do conjunto é limitado a ~94 em um teclado padrão.
Valores reais de entropia, calculados
Aplicando H = L × log2(P):
Conjunto ASCII imprimível completo (94 caracteres):
| Comprimento | Entropia (bits) | Espaço de busca |
|---|---|---|
| 8 | 52.4 | ~6.1 × 10^15 |
| 10 | 65.5 | ~4.4 × 10^19 |
| 12 | 78.7 | ~4.8 × 10^23 |
| 14 | 91.8 | ~5.1 × 10^27 |
| 16 | 104.9 | ~3.7 × 10^31 |
| 20 | 131.1 | ~2.9 × 10^39 |
Apenas minúsculas (26 caracteres):
| Comprimento | Entropia (bits) |
|---|---|
| 8 | 37.6 |
| 12 | 56.4 |
| 16 | 75.2 |
| 20 | 94.0 |
Conjunto alfanumérico (62 caracteres):
| Comprimento | Entropia (bits) |
|---|---|
| 8 | 47.6 |
| 12 | 71.5 |
| 16 | 95.3 |
| 20 | 119.1 |
Agora a comparação que torna o ponto. Olhe estas três senhas, todas saídas plausíveis de políticas diferentes:
xQ9#mK2!— 8 caracteres, conjunto completo de 94: 52.4 bitshkbwvztdpqrm— 12 caracteres, apenas minúsculas: 56.4 bitshkbwvztdpqrmjfyc— 16 caracteres, apenas minúsculas: 75.2 bits
A senha «simples» de 12 caracteres em minúsculas já supera a «complexa» de 8 caracteres, e a senha de 16 caracteres em minúsculas a supera por 23 bits — um fator de cerca de 8 milhões no espaço de busca — sendo dramaticamente mais fácil de digitar e lembrar. Quatro caracteres adicionais valem mais do que todo o conjunto de símbolos.
É nesse sentido que o comprimento vence a complexidade: não que a complexidade seja inútil (um conjunto mais amplo sempre ajuda em comprimento fixo), mas que humanos são péssimos em produzir complexidade aleatoriamente, e a entropia marginal por caractere adicionado excede a entropia marginal por ampliação do conjunto para qualquer conjunto realista.
A grande ressalva: isso só funciona para senhas aleatórias
A fórmula H = L × log2(P) assume uma extração aleatória uniforme. Senhas escolhidas por humanos não são nada disso. Summer2026! tem 11 caracteres de um conjunto de ~90 — nominalmente ~71 bits — mas qualquer ferramenta de cracking tenta dentro de seus primeiros milhares de palpites porque é uma palavra de dicionário, um ano e o símbolo mais comum, na disposição mais comum.
A entropia de senhas humanas é dominada pela previsibilidade, não pela fórmula. Análises empíricas de corpora de senhas vazadas consistentemente encontram que um pequeno dicionário de senhas comuns mais regras de modificação (capitalizar primeira letra, anexar dígitos, anexar !) cobre uma fração grande das senhas reais. Por isso:
- A matemática da entropia se aplica a senhas geradas, frases-senha de listas de palavras e segredos criados por gerenciador — não a qualquer coisa que uma pessoa invente sem ajuda.
- Para senhas escolhidas por humanos, a defesa não é estimativa de entropia, é triagem contra listas de senhas comuns e vazadas — que é exatamente o que o NIST exige.
Frases-senha e Diceware
O método Diceware torna a matemática concreta para segredos memoráveis: role dados para escolher palavras uniformemente de uma lista de 7.776 palavras (6^5). Cada palavra carrega log2(7776) ≈ 12.9 bits:
- 5 palavras: 64.6 bits
- 6 palavras: 77.5 bits
- 7 palavras: 90.4 bits
Uma frase-senha de 6 palavras no estilo correct horse battery staple (o famoso exemplo do XKCD ilustra a mesma matemática) dá ~77 bits com memorabilidade muito melhor do que uma string aleatória de 12 caracteres a 78.7 bits. Mesmo nível de segurança, usabilidade radicalmente diferente.
Estimativas de tempo de força bruta — com as premissas declaradas
Qualquer número de «tempo para quebrar» é sem sentido sem seu modelo de ataque. Aqui está um, declarado explicitamente:
Premissas: ataque offline contra um hash rápido e sem sal (ex., MD5/SHA-1 puro) a 10^10 (10 bilhões) de palpites por segundo — alcançável com um equipamento modesto multi-GPU. Busca exaustiva do espaço total; tempo esperado para encontrar a senha é metade disso. Sem limitação de taxa, sem atalhos por listas de vazamentos (válido porque assumimos senhas aleatórias).
| Classe de senha | Espaço de busca | Tempo exaustivo @ 10^10/s |
|---|---|---|
| 8 caracteres, minúsculas (26) | 2.1 × 10^11 | ~21 segundos |
| 8 caracteres, conjunto completo (94) | 6.1 × 10^15 | ~7 dias |
| 12 caracteres, minúsculas (26) | 9.5 × 10^16 | ~110 dias |
| 12 caracteres, conjunto completo (94) | 4.8 × 10^23 | ~1,5 milhão de anos |
| 16 caracteres, minúsculas (26) | 4.4 × 10^22 | ~140.000 anos |
| 16 caracteres, conjunto completo (94) | 3.7 × 10^31 | ~1.2 × 10^14 anos |
Trate estes como ordens de magnitude ilustrativas, não garantias. Eles mudam em ambas as direções:
- Mais lento na prática se o site usa uma função adequada de hash de senhas. bcrypt, scrypt ou Argon2 com parâmetros sensatos podem reduzir a vazão de palpites em 4–7 ordens de magnitude comparado a MD5 puro, transformando «~7 dias» em «mais longo que o cronograma de morte térmica que alguém se importa». É por isso que a escolha do algoritmo de hash importa mais do que quase qualquer coisa que usuários façam.
- Mais rápido se a senha não é aleatória (ataque de dicionário), o atacante tem hardware de estado, ou melhorias estilo lei de Moore se acumulam ao longo dos anos que um hash roubado permanece valioso.
- Ataques online (palpites contra um endpoint de login ao vivo) são um modelo completamente diferente: limites de taxa e bloqueios limitam atacantes a talvez centenas de palpites, então mesmo segredos de ~20 bits sobrevivem — é por isso que o NIST exige limitação de taxa, e por isso as senhas por site do seu gerenciador importam mais do que a força de qualquer senha individual.
A conclusão prática da tabela: 8 caracteres não são suficientes para qualquer coisa que será hasheada rápido, ponto final; 12+ caracteres aleatórios é confortável; 16 é exagero no bom sentido. E de novo, a string de 16 caracteres minúsculos supera a string de 12 caracteres de conjunto completo — o comprimento ganha.
O que o NIST SP 800-63B realmente diz
As Digital Identity Guidelines do NIST (SP 800-63B, originalmente 2017; Revision 4 publicada em 2024) codificaram muito disso na política federal dos EUA. As recomendações de peso para verificadores de senha («segredo memorizado»):
- Comprimento mínimo, não complexidade. Exija pelo menos 8 caracteres para senhas escolhidas pelo usuário (Revision 4 eleva isso para 15 para senhas usadas como único fator, 8 quando um segundo fator está presente). Permita pelo menos 64 caracteres. Não imponha regras de composição (não «deve conter maiúscula, dígito, símbolo») — elas empurram usuários para padrões previsíveis (
Password1!) que enfraquecem a segurança no mundo real. - Sem mudanças periódicas forçadas. A revisão de 2017 já descartou o dogma antigo de «rotacionar a cada 90 dias»; Revision 4 o reafirma. Mude senhas só quando houver evidência de comprometimento. Rotação forçada produz confiavelmente
Summer2026!→Autumn2026!— um incremento que uma regra de cracking cobre trivialmente. - Triagem contra listas de senhas vazadas e comuns. Verificadores devem comparar senhas candidatas contra dicionários de senhas comprometidas conhecidas, palavras de dicionário, strings repetitivas/sequenciais e palavras específicas do contexto (nome do serviço, nome do usuário). Isso substitui as regras de composição como verdadeira defesa para segredos escolhidos por humanos.
- Permita colar e gerenciadores de senhas. Verificadores devem permitir entradas coladas — o que é um endosso explícito a gerenciadores de senhas, já que strings aleatórias geradas de 20 caracteres são exatamente o que as diretrizes querem que os usuários tenham.
- Sem dicas baseadas em conhecimento nem perguntas de segurança. Dicas de senha e KBA («nome de solteira da mãe») são proibidas porque vazam ou revelam trivialmente o segredo.
- Hash com sal e memory-hard para armazenamento. Verificadores devem armazenar senhas hasheadas com uma função unidirecional adequada — o guia aponta para esquemas como Argon2, bcrypt ou PBKDF2 com fatores de trabalho adequados — com um sal por usuário de pelo menos 32 bits.
Observe como isso se alinha com a matemática da entropia: regras de composição não adicionam entropia real para humanos, comprimento sim; rotação destrói qualquer entropia que usuários tinham empurrando-os para padrões; e a triagem contra listas de vazamentos lida com o fato de que a entropia humana é impossível de medir. O padrão é a matemática, institucionalizada.
Regras que você pode realmente usar
- Deixe um gerador criar suas senhas. Geração aleatória é a única maneira de a fórmula da entropia se aplicar a você. Nosso Gerador de Senhas cria senhas criptograficamente aleatórias no seu navegador — nada é transmitido para lugar nenhum. Configure para 16+ caracteres e pare de pensar nisso.
- Padrão de 16 caracteres para qualquer coisa importante. Com 95+ bits mesmo só em minúsculas, você está além de qualquer orçamento concebível de força bruta contra um armazenamento corretamente hasheado.
- Para coisas que você precisa memorizar, use uma frase-senha de 6 palavras. ~77 bits, digitável, memorável. Gere candidatos com o modo frase-senha/lista de palavras da mesma ferramenta se disponível, ou use Diceware.
- Única por site, sempre. Entropia protege um site; reuso converte um vazamento em todos os vazamentos. É para isso que serve o gerenciador de senhas.
- Adicione um segundo fator onde oferecido. Os requisitos de comprimento do NIST se relaxam explicitamente quando MFA está presente, porque um segundo fator multiplica o trabalho do atacante de forma muito mais barata do que mais entropia de senha.
- Ignore o teatro da complexidade. Um site que exige «uma maiúscula, um dígito, um símbolo» mas te limita a 12 caracteres tem a política invertida. Cumpra mecanicamente, mas não confunda com força.
Resumo
- A entropia de senhas aleatórias é
H = L × log2(P): cada caractere adiciona um número fixo de bits dependendo apenas do tamanho do conjunto. - Ampliação do conjunto (26 → 94 caracteres) ganha ~1.85 bits por caractere; cada caractere adicionado ganha 4.7–6.6 bits. O comprimento ganha de forma decisiva.
- 8 caracteres aleatórios ≈ 52 bits ≈ dias-para-quebrar contra hashes offline rápidos; 12 caracteres aleatórios ≈ 78+ bits ≈ efetivamente inquebrável nesse modelo.
- A fórmula só se aplica a geração aleatória. Senhas escolhidas por humanos são derrotadas por dicionários, por isso o NIST exige triagem contra listas de vazamentos e proíbe regras de composição e rotação forçada.
- Gere senhas aleatórias de 16 caracteres com o Gerador de Senhas, armazene em um gerenciador e habilite MFA. Esse stack é o que a matemática recomenda.