Caractere alfanumérico: definição, uso em criptografia, segurança

Sessenta e dois. Esse é o número total de símbolos distintos disponíveis quando alguém diz "use apenas caracteres alfanuméricos". Vinte e seis letras maiúsculas, vinte e seis minúsculas e dez dígitos. Desconsiderando a distinção entre maiúsculas e minúsculas, o número cai para trinta e seis. Ambos os números são importantes, porque quase todos os identificadores digitais que você já digitou — um endereço de carteira, uma senha de Wi-Fi, um hash de transação, um token do GitHub — são construídos a partir de um subconjunto escolhido desses sessenta e dois símbolos.

A escolha de qual subconjunto, e por quê, é a parte que a maioria das explicações omite. É também a parte que conecta a definição enciclopédica de um caractere alfanumérico à segurança prática da sua carteira de criptomoedas. Este artigo aborda a contagem, o padrão por trás dela, a forma como a criptografia moderna seleciona seus subconjuntos e o que a autoridade nacional dos EUA em senhas diz agora sobre o assunto. Algumas dessas diretrizes mudaram de maneiras que a maioria das recomendações de segurança ainda não acompanhou.

O que é um caractere alfanumérico? Definição e quantidade.

Comecemos pela definição. Um caractere alfanumérico é qualquer letra de A a Z (maiúsculas ou minúsculas) ou qualquer dígito decimal de 0 a 9. É só isso. A partir daí, a aritmética é óbvia: vinte e seis letras por caixa, mais dez dígitos, resultam em sessenta e dois caracteres distintos com distinção entre maiúsculas e minúsculas, trinta e seis sem distinção. Qualquer outra coisa é "especial". Pontuação, espaços em branco, símbolos matemáticos, letras acentuadas, emojis — nada disso conta como alfanumérico.

Normalmente, os engenheiros se deparam com a definição por meio de uma das duas abreviações. Ferramentas POSIX como grep, sed e awk reconhecem `[:alnum:]`, que corresponde aos sessenta e dois caracteres acima. A maioria das expressões regulares modernas — Python, JavaScript, Java, PCRE — usa `\w` em vez disso. O problema com `\w` é que ele inclui o sublinhado. O sublinhado não é formalmente alfanumérico. A maioria das sintaxes de programação o trata como honorário, e é por isso que o prefixo de chave do Stripe `sk_live_` e o prefixo de chave da AWS `AKIA` misturam sublinhados e letras maiúsculas com dígitos sem que ninguém perceba.

De onde surgiu o termo? Dos cartões perfurados, acredite se quiser. Os equipamentos de tabulação da IBM, na década de 1930, precisavam de uma palavra única para códigos que misturavam letras e números, e "alfanumérico" acabou sendo o termo escolhido. No início da década de 1960, com o IBM 1401, a palavra já era vocabulário padrão na área de computação empresarial. A distinção tinha um impacto prático: um campo declarado como "alfanumérico" aceitava qualquer letra ou dígito; um campo somente numérico rejeitava o alfabeto por completo. A partir daí, a palavra se espalhou para placas de veículos, códigos bancários IBAN, mnemônicos de teclados de telefone, SKUs de produtos e uma centena de outros lugares.

A distinção entre maiúsculas e minúsculas é mais importante do que parece. A entropia das senhas dobra quando letras maiúsculas são permitidas. Os endereços Base58 do Bitcoin mantêm ambos os casos propositalmente. O Bech32 descarta maiúsculas e minúsculas propositalmente. Cada uma dessas escolhas é um equilíbrio entre expressividade e erro humano. Escolha errado e as pessoas perdem dinheiro com erros de digitação.

Do ASCII ao Unicode: Uma Breve História Técnica

O sistema "alfanumérico" de hoje é o sobrevivente de uma guerra de padrões que durou sessenta anos. A maioria dos usuários ficou em algum ponto intermediário e nem percebeu.

O ASCII veio primeiro. Foi lançado em 1963, pela American Standards Association, e formalizado cinco anos depois como ANSI X3.4-1968. Seguiram-se duas revisões — uma em 1977 e outra em 1986. A versão de 1968 fixou a letra maiúscula A no número 65, a letra minúscula a no número 97 e os dígitos de 0 a 9 nos números 48 a 57. Abra seu editor agora mesmo: o byte 'A' ainda é o 65. Nada mudou em sessenta anos.

Por aproximadamente quatro décadas, o conjunto alfanumérico ASCII foi o conjunto alfanumérico padrão. Então veio a internet global. Sete bits deixaram de ser suficientes. As falhas eram terríveis. E-mails ilegíveis. Bancos de dados corrompidos. Sites japoneses que funcionavam perfeitamente em Tóquio, mas pareciam paredes de pontos de interrogação em um laptop americano. O Unicode chegou em 1991 com uma ambição extravagante: atribuir um número único a cada caractere em todos os alfabetos já escritos. O UTF-8 surgiu em 1992 como a codificação que de fato transportou o Unicode pelas redes comuns. Seu truque era a retrocompatibilidade — os primeiros 128 pontos de código do UTF-8 correspondem exatamente aos 1968 bytes originais do ASCII. Textos em inglês publicados antes de 1991 continuaram funcionando indefinidamente.

A transição ocorreu em dezembro de 2007. Naquele mês, as estatísticas públicas de rastreamento da web finalmente mostraram que o UTF-8 ultrapassou o ASCII como a codificação mais comum online. A partir de então, "alfanumérico" deixou de se referir estritamente aos sessenta e dois símbolos do ASCII. O Unicode agora cataloga blocos alfanuméricos para os alfabetos cirílico, grego, árabe, hebraico e CJK. Cada alfabeto possui suas próprias letras e seus próprios dígitos.

Na prática, porém, o software que precisa cruzar fronteiras ainda usa por padrão o subconjunto ASCII original. Letras latinas de A a Z. Numerais arábicos de 0 a 9. Nada mais. A razão é prosaica. Todo teclado produz ASCII. Todo banco de dados o aceita. Todo mecanismo de expressões regulares o conhece. Saia desse intervalo e você herdará uma série de erros de codificação, caracteres semelhantes e os ataques de phishing aos quais voltarei mais adiante.

Caracteres alfanuméricos em criptografia: endereços, hashes e sementes

Eis a parte que a maioria das explicações genéricas omite. Os sistemas de criptomoedas nunca usam o conjunto alfanumérico completo de sessenta e dois caracteres. Eles escolhem subconjuntos cuidadosamente selecionados. Cada um deles é um compromisso de engenharia documentado, não uma escolha estética arbitrária.

Primeiro, o Bitcoin. Um endereço Bitcoin tradicional (aquele que começa com 1 ou 3) é codificado em Base58. O alfabeto foi criado à mão por Satoshi Nakamoto. Receita: pegue o conjunto alfanumérico de sessenta e dois caracteres e exclua quatro membros. Sai o dígito zero, o O maiúsculo, o I maiúsculo e o l minúsculo. Por que esses quatro? Escreva-os em um Post-it com uma caligrafia ruim. Saia. Volte em cinco minutos. Tente diferenciá-los. Você não conseguirá. Esse é exatamente o problema que o Base58 foi criado para resolver. Restam cinquenta e oito caracteres. Um endereço tradicional típico acaba tendo de vinte e seis a trinta e cinco símbolos — curto o suficiente para ser copiado à mão, se necessário.

O SegWit foi ativado em agosto de 2017. Com ele, surgiu um segundo formato de endereço Bitcoin: o Bech32, definido no BIP-173. O Bech32 faz apostas diferentes. A diferenciação entre maiúsculas e minúsculas desaparece completamente — todos os endereços são escritos em minúsculas. Quatro caracteres diferentes são descartados: o dígito 1, além de b, i e o. As trinta e duas letras e dígitos restantes contêm um checksum embutido. O checksum detecta automaticamente quase todos os erros de digitação de um único caractere. O Taproot, em operação desde novembro de 2021, refinou o formato para Bech32m (BIP-350) depois que pesquisadores encontraram uma falha em um caso específico nos cálculos originais.

O Ethereum escolheu um terceiro caminho: usar hexadecimal. Um endereço Ethereum é `0x` seguido exatamente por quarenta caracteres hexadecimais; quarenta e dois caracteres no total. O hexadecimal reduz o alfanumérico a dezesseis membros: os dígitos de 0 a 9, as letras de a a f e nada mais. A escolha pareceu sensata em 2015. Mas, depois de anos com usuários tentando decifrar blocos hexadecimais brutos no MetaMask, a situação ficou complicada. A solução foi o EIP-55. Ele converte seletivamente certas letras para maiúsculas, seguindo um padrão derivado do hash Keccak-256 do endereço em minúsculas. O resultado é a detecção de erros de digitação gratuita. O EIP-55 detecta erros de digitação com uma confiabilidade de cerca de 99,975%. A taxa de erros é de aproximadamente 0,0247%. Baixa. Mas não zero.

Os hashes são o caso mais simples. Um hash SHA-256 tem 256 bits, exibidos como 64 caracteres hexadecimais. O Keccak-256 do Ethereum produz um resultado de comprimento idêntico. Um ID de transação do Bitcoin — um txid — é o hash SHA-256 da própria transação, portanto, um txid também tem 64 caracteres alfanuméricos hexadecimais. Eles parecem intimidantes em um explorador de blocos. Mas são puramente alfanuméricos.

As frases-semente quebram o padrão. A recuperação de carteira BIP-39 é o único ponto em que as criptomoedas saem do domínio alfanumérico e retornam ao território puramente alfabético. O padrão codifica 128 ou 256 bits de entropia como doze ou vinte e quatro palavras em inglês, extraídas de uma lista fixa de 2.048 palavras. Cada palavra é composta apenas por letras minúsculas — sem dígitos, sem letras maiúsculas e minúsculas misturadas. Por quê? Porque o objetivo do projeto é uma pessoa escrevendo palavras em um papel às 3 da manhã, depois que o celular descarrega, e os dígitos introduzem ambiguidade que as letras não introduzem.

Cada subconjunto é uma peça de design centrada no ser humano, escondida dentro de um sistema profundamente técnico.

Senhas alfanuméricas: o que o NIST realmente diz em 2024

A maioria das dicas sobre senhas disponíveis na internet está desatualizada há vários anos. Usar letras maiúsculas e minúsculas, adicionar números, incluir pelo menos um caractere especial e trocá-la a cada noventa dias — essas regras foram consideradas válidas por duas décadas. O Instituto Nacional de Padrões e Tecnologia dos Estados Unidos (NIST) oficialmente as abandonou.

A Publicação Especial 800-63B do NIST, autoridade federal em diretrizes de identidade digital, finalizou a Revisão 4 em setembro de 2024. A nova diretriz impressiona pela quantidade de mudanças que implementou. A recomendação de comprimento mínimo para autenticação de fator único foi elevada para quinze caracteres. A instrução sobre regras de composição de caracteres é formulada como um "não deve": os serviços não devem exigir classes de caracteres específicas. A expiração periódica de senhas, aquela rotação de noventa dias que todos detestavam, também foi removida. Em vez dessas regras, o NIST agora exige que os serviços verifiquem as senhas enviadas em relação a uma lista de bloqueio de credenciais comprometidas conhecidas.

A mudança é justificada por cálculos de entropia. Um conjunto alfanumérico de 62 caracteres produz cerca de 5,95 bits por caractere. O conjunto completo de 95 caracteres ASCII imprimíveis — alfanuméricos mais especiais — produz 6,57 bits. Adicionar o conjunto completo de caracteres especiais resulta em um ganho de 0,62 bits por caractere. Adicionar mais um caractere de comprimento igual ao especificado resulta nos 5,95 bits completos. O comprimento domina a complexidade por uma ordem de magnitude.

O Relatório de Investigações de Violações de Dados de 2025 da Verizon constatou que as credenciais representam 22% de todos os pontos de entrada confirmados em violações de dados. O credential stuffing — reutilização automatizada de listas de senhas vazadas — ocorre em 19% das tentativas de autenticação, em média, chegando a um pico de 44%. Quarenta e nove por cento dos usuários reutilizam senhas em diferentes serviços. Nenhum desses problemas é resolvido exigindo o uso de letras maiúsculas.

Uma senha alfanumérica mais longa, sem caracteres especiais, é mais difícil de quebrar do que uma senha curta, criada para atender a uma lista de verificação de complexidade. Se o seu banco ainda exige que você crie uma senha de doze caracteres com uma letra maiúscula, um dígito e um caractere especial, essa política agora está formalmente em desacordo com o padrão federal dos EUA.

Onde mais aparecem caracteres alfanuméricos?

Saindo do âmbito da criptografia, senhas e sequências alfanuméricas ainda surgem sempre que um sistema precisa de um identificador que humanos possam digitar e computadores possam analisar sem ambiguidade.

Os códigos bancários são um exemplo simples. Um IBAN pode ter até trinta e quatro caracteres alfanuméricos e sempre começa com um código de país ISO de duas letras. Os códigos SWIFT/BIC têm oito ou onze caracteres. As placas de veículos variam de país para país — uma placa do Reino Unido é completamente diferente de uma placa alemã —, mas ambas são subconjuntos alfanuméricos do mesmo conjunto de sessenta e dois símbolos. Os Números de Identificação de Veículos (VINs) têm exatamente dezessete caracteres em todo o mundo, e os VINs proíbem deliberadamente as letras I, O e Q para que sejam visualmente distintos dos dígitos.

As chaves de API são exemplos comuns que a maioria dos usuários nem se dá ao trabalho de verificar. Uma chave ativa do Stripe abre com `sk_live_` mais um token alfanumérico. Uma chave de acesso da AWS abre com `AKIA` mais dezesseis caracteres alfanuméricos. Um token de acesso pessoal do GitHub emitido após 2021 abre com `ghp_`. Esses prefixos são alfanuméricos, escolhidos para que os provedores possam verificar repositórios públicos e logs em busca de chaves vazadas. Em muitos casos, essa verificação detecta uma falha antes que qualquer invasor a perceba.

Os códigos QR merecem uma breve menção. A norma ISO/IEC 18004 define um "modo alfanumérico" dedicado que codifica um conjunto específico de 45 caracteres — letras maiúsculas, dígitos, espaços e alguns sinais de pontuação — de forma mais eficiente do que o modo de bytes geral. Um código QR que contém apenas conteúdo alfanumérico em maiúsculas armazena cerca de 1,6 vezes mais dados por quadrado do que o mesmo conteúdo codificado como bytes brutos.

Base32, Base58, Base64: Quando a Criptografia Escolhe um Subconjunto

Existem alguns padrões de codificação específicos para mapear binário em um subconjunto alfanumérico. A referência é a RFC 4648, publicada pela IETF em 2006. Ela define três codificações.

O hexadecimal é o mais simples deles. Oficialmente Base16. Dezesseis caracteres: 0–9, a–f. Usado para endereços Ethereum, hashes criptográficos e praticamente qualquer depuração de baixo nível que exija a leitura de bytes brutos. O Base32 é o mais interessante. O alfabeto de 32 caracteres foi escolhido para não diferenciar maiúsculas de minúsculas e, em algumas variantes, para eliminar os dígitos visualmente confundíveis 0, 1, 8 e 9. Qualquer pessoa que já configurou a autenticação de dois fatores e digitou uma senha no Google Authenticator digitou Base32 — na maioria das vezes sem saber.

Base64 é o formato principal. Sessenta e dois caracteres alfanuméricos mais os dois símbolos `+` e `/`. Uma variante segura para URLs substitui esses símbolos por `-` e `_`. O Base64 é usado para enviar anexos de e-mail, codifica URLs de dados dentro do HTML e empacota JSON Web Tokens para OAuth.

O Base58 do Bitcoin não está incluído na RFC 4648. Satoshi Nakamoto o criou de forma independente. O objetivo era diferente — evitar que as pessoas digitassem endereços repetidamente, e não otimizar a quantidade de bytes por caractere — e o resultado foi um alfabeto personalizado que ninguém mais usa. O Base85, às vezes chamado de ASCII85, segue na direção oposta. Ele compacta quatro bytes em cinco caracteres e aparece em arquivos PDF e PostScript, onde a densidade extra justifica a perda de legibilidade.

Armadilhas comuns: Confusão visual e sósias

Os mesmos motivos que levam as criptomoedas a escolher subconjuntos alfanuméricos são os mesmos pelos quais todos cometem erros. Um punhado de pares de caracteres causa a maior parte dos problemas.

Os clássicos caracteres que podem ser confundidos: zero e O maiúsculo. Dígito um, l minúsculo, I maiúsculo. l minúsculo e I maiúsculo. O Bitcoin Base58 descarta todos os quatro por causa disso. Outros sistemas usam diferentes medidas de mitigação — os números de identificação do veículo (VINs) descartam I, O e Q, alguns códigos financeiros descartam o O completamente, e você pode encontrar regras nacionais para placas de veículos que proíbem a letra que mais se assemelha a um 0 na fonte do país.

Um problema mais complexo e recente são os ataques homográficos Unicode. A ideia foi documentada em um artigo de 2001 por Evgeniy Gabrilovich e Alex Gontmakher. Um homógrafo troca um caractere visualmente idêntico de um alfabeto diferente — por exemplo, o 'а' cirílico (U+0430) pelo 'a' latino (U+0061). Registre um nome de domínio com essa substituição e você poderá hospedar uma página de phishing que parece indistinguível do site legítimo do banco. Os navegadores modernos exibem a representação Punycode bruta — algo como `xn--80akhbyknj4f` — sempre que um domínio mistura alfabetos. Essa defesa detecta a maioria dos ataques. Mas não todos.

Como criar uma senha alfanumérica forte em 2026

Três regras. Todas elas derivadas diretamente da matemática do NIST.

Primeiro: o comprimento é mais importante que a classe de caracteres. Procure usar dezesseis caracteres ou mais. Essa regra vale tanto para sistemas que aceitam apenas letras e dígitos quanto para aqueles que aceitam todo o conjunto ASCII imprimível.

Segundo: se você tiver que memorizar, use uma frase-senha. Quatro palavras aleatórias de uma lista extensa — a lista da Diceware é a opção mais comum — superam quase qualquer senha curta que uma pessoa possa inventar.

Três: para todo o resto, use um gerenciador de senhas. Deixe que o gerenciador gere longas sequências alfanuméricas que você nunca precisará ler ou digitar manualmente. Uma vez que o gerenciador processa a saída, a legibilidade da mesma deixa de importar.

Referência rápida: Contagens alfanuméricas e exemplos

Sessenta e dois caracteres com distinção entre maiúsculas e minúsculas. Trinta e seis sem distinção. Códigos ASCII 48–57 para dígitos. 65–90 para maiúsculas. 97–122 para minúsculas. Combine todo o conjunto com a expressão regular `[A-Za-z0-9]` ou a classe POSIX `[:alnum:]`. Esse conjunto de sessenta e dois símbolos é a base de praticamente todos os identificadores digitais que você usará esta semana. Senhas. Chaves de API. IBANs. Placas de veículos. IDs de transação. Todos os endereços de carteira que você gerar.

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.