Codificação, hash e criptografia são três coisas diferentes
Quase todo mal-entendido nesta página vem de tratar essas três coisas como se fossem a mesma, então vale a pena separá-las direito.
Codificação é reversível e não tem segredo nenhum. O Base64 existe para levar dados binários por canais que só aceitam texto — anexos de e-mail, data URIs, strings JSON — representando cada três bytes como quatro caracteres, e é por isso que o resultado é sempre cerca de um terço maior. Não há chave. Qualquer pessoa que veja a string consegue decodificá-la num passo, inclusive neste site. Base64 não é segurança, não é uma ofuscação digna do nome e não esconde nada de quem olhar. A codificação por porcentagem é o mesmo tipo de coisa para URLs, e é aí que mora o outro bug comum: codificar um valor que vai numa query string é uma operação diferente de limpar uma URL inteira já montada, porque só a primeira escapa os caracteres &, =, ? e / que dão estrutura à URL. Se errar, “Smith & Sons” chega ao servidor como dois parâmetros em vez de um valor.
Hash é de mão única e também não tem chave. Um hash recebe qualquer entrada e produz uma impressão digital de tamanho fixo, e não há como desfazer — não porque esteja criptografado, mas porque a informação se perdeu. O que dá para fazer é chutar entradas e comparar, e é exatamente isso que torna MD5, SHA-1 e SHA-256 inadequados para guardar senhas: eles são rápidos, uma placa de vídeo calcula bilhões deles por segundo, e uma tabela roubada é quebrada nessa velocidade. Senhas precisam de uma função propositalmente lenta e com salt — bcrypt, scrypt ou Argon2. Além disso, MD5 e SHA-1 estão quebrados por outro motivo: hoje é possível construir de propósito dois arquivos diferentes com o mesmo hash, então nenhum dos dois prova que um arquivo é o arquivo que você esperava, embora ambos continuem bons para detectar um download corrompido por acidente.
Criptografia é a única que tem chave, e nenhuma destas ferramentas faz criptografia. Não é um esquecimento. Criptografar direito exige gerenciar chaves, e uma página da web é o lugar errado para uma chave.
Um JWT é assinado, não criptografado, e isso pega muita gente de surpresa. O cabeçalho e o payload de um token são Base64URL — qualquer pessoa que tenha o token consegue ler, sem chave nenhuma. A assinatura impede que alguém altere o token; não impede ninguém de lê-lo, então nada confidencial deve ir num payload. Daí se conclui que decodificar um token não prova absolutamente nada sobre ele: qualquer um pode escrever as claims que quiser e passar em Base64. Verificar significa recalcular a assinatura com a chave do emissor, algo que o seu servidor faz e que um site nunca deve pedir. Por isso o nosso decodificador se recusa a sugerir qualquer verificação e sinaliza os padrões que indicam problema — um token expirado, um token sem nenhuma expiração e um algoritmo “none”, que é uma forma documentada de burlar a autenticação, e não uma curiosidade.
O JSON tem um limite de precisão numérica em que a maioria dos formatadores tropeça sem avisar. O JSON em si não limita o tamanho de um número, mas um número em JavaScript é um float de 64 bits, então números inteiros só ficam exatos até 9.007.199.254.740.991. Um ID de post do Twitter, um snowflake do Discord, uma chave de banco de dados de 64 bits ou um número de conta bancária passam disso, e passá-los pelo formatador de uma linha de sempre — parse e depois stringify — altera os últimos dígitos. O resultado continua parecendo um número plausível, e é isso que o torna perigoso: 7205759403792793600 vira silenciosamente 7205759403792793000. As nossas ferramentas de JSON reserializam exatamente os dígitos que você colou e informam quantos números precisaram proteger.
A versão de um UUID descreve como ele foi gerado, não o que ele garante. Nada registra um UUID nem impõe unicidade; a unicidade é probabilística, e a versão diz de onde vieram os bits. A versão 4 tem 122 bits de aleatoriedade vindos do gerador criptográfico do navegador, o que a torna impossível de adivinhar e, portanto, certa para links de redefinição, códigos de convite e qualquer coisa secreta — e errada como chave de banco de dados, porque chaves aleatórias se espalham por um índice ordenado e o fragmentam. A versão 7 coloca na frente um timestamp de 48 bits em milissegundos, então as chaves entram no fim do índice como um inteiro autoincrementado, sem deixar de ser globalmente únicas. A contrapartida é que um UUID v7 revela claramente quando foi criado, com precisão de milissegundo, para qualquer pessoa que o tenha.
Quando o navegador é mesmo a ferramenta errada
Nenhuma destas treze envia nada para lugar nenhum. Nenhuma requisição é feita, nada é registrado, e as páginas continuam funcionando com a rede desconectada — e é justamente por isso que dá para usá-las com uma resposta de API cheia de dados de clientes ou com um token que você não mandaria por e-mail para ninguém. Esse é o argumento honesto a favor delas. Veja agora o argumento honesto contra.
Colar um segredo de produção ativo numa página da web é um hábito que vale a pena não ter — nesta também. A nossa afirmação sobre privacidade é verdadeira, mas não é uma afirmação que protege você; é o comportamento do código, e a única postura sensata diante de qualquer página da web é conferir em vez de confiar. Conferir não custa nada: desconecte-se da internet depois que a página carregar e veja estas ferramentas continuarem funcionando. Uma ferramenta que dependesse de um servidor pararia. E se uma credencial ainda está válida e você já a colou em algum lugar que não tem como auditar, o certo é trocá-la, e não ficar pensando se foi seguro. Para um token que está ativo agora, decodificá-lo localmente — com a função Base64 da sua linguagem ou duas linhas no terminal — é uma prática melhor do que usar qualquer site, inclusive o nosso.
Validação de schema. As nossas ferramentas de JSON e XML verificam se um documento está bem formado, o que é uma pergunta diferente de saber se ele segue um schema. Validar com JSON Schema ou XSD significa buscar e aplicar um arquivo de schema, uma requisição de rede que estas páginas deliberadamente nunca fazem. Use o ajv para JSON Schema e o xmllint para XSD e DTD; os dois são gratuitos e fazem isso melhor do que uma página da web conseguiria.
Qualquer coisa realmente grande ou em streaming. Os documentos ficam inteiros na memória, às vezes em dobro durante a formatação, então o teto é a aba. Alguns megabytes são instantâneos; algumas centenas, não. O jq processa em streaming um JSON de vários gigabytes que nenhum navegador abre, e o ripgrep busca num repositório inteiro mais rápido do que você cola um único arquivo. O hash tem uma versão mais severa do mesmo limite: a criptografia do navegador não tem digest incremental, então o arquivo inteiro precisa caber na memória de uma vez — uma imagem de DVD vai falhar, enquanto sha256sum, shasum ou certutil a processam em streaming sem nem perceber.
Automação e CI. Estas ferramentas funcionam quando uma pessoa clica. Formatar todos os arquivos de um repositório, gerar dez mil UUIDs para uma fixture ou verificar JSON num pipeline é trabalho para um script: jq, xmllint, uuidgen, openssl e o comando base64 já vêm instalados na maioria das máquinas.
Verificar qualquer coisa assinada. Verificação de assinaturas, cadeias de certificados e qualquer coisa que exija uma chave privada devem acontecer no seu servidor, com uma biblioteca mantida. Esta página diz o que um token afirma; nunca vai dizer que um token é legítimo, e você deve desconfiar de qualquer site que diga conseguir fazer isso sem a sua chave.
Como escolher entre ferramentas parecidas
Formatador JSON vs. Validador JSON. Mesmo parser, pergunta diferente. O formatador serve para ler e remodelar um documento que já passa na análise — indentar, minificar, manter os números grandes intactos. O validador serve para um documento que não passa, e o que ele mostra é a linha, a coluna, o caractere problemático com um acento circunflexo embaixo e qual das quatro causas mais comuns foi a responsável. Se você está olhando para “Unexpected token”, o que você quer é o validador. A mesma divisão vale para Formatador XML e Validador XML.
Decodificar Base64 vs. Decodificador JWT. Um JWT são três seções em Base64URL, então o decodificador geral mostra as partes. A página de JWT separa as partes para você, formata o JSON, transforma as claims de expiração, emissão e “not before” de timestamps Unix em datas de verdade no seu fuso horário, identifica as claims registradas e avisa sobre expiração e algoritmo “none”. Use o decodificador geral para um bloco de Base64 e a página de JWT para um token.
Codificar Base64 vs. Codificar URL. Tarefas diferentes que produzem texto “seguro”. O Base64 transforma bytes quaisquer em texto com um custo de 33% no tamanho, e o Base64 padrão não é nada seguro numa URL — os caracteres +, / e = têm significado ali, e é por isso que o Base64URL existe. A codificação por porcentagem deixa texto legível continuar legível e escapa só o que quebraria a URL, que é o que você quer para um termo de busca, um endereço de e-mail ou um destino de redirecionamento. Codificar um arquivo inteiro para uma query string normalmente é sinal de que aquilo deveria ter sido o corpo de uma requisição.
Gerador de hash vs. Gerador de UUID. Um hash é derivado da entrada, então a mesma entrada sempre dá o mesmo valor — é isso que o torna uma impressão digital, bom para verificar um download ou eliminar conteúdo duplicado. Um UUID é aleatoriedade nova, sem relação com nada, então nunca se repete. Se você quer o mesmo identificador para o mesmo conteúdo, gere um hash. Se quer um identificador novo, gere um UUID.
Gerador de QR Code vs. Gerador de código de barras. O QR Code é uma grade bidimensional que guarda qualquer texto — uma URL, dados de Wi-Fi, um número de telefone — e é lido pela câmera do celular. A página de código de barras cria os códigos unidimensionais do varejo e da logística: EAN-13, EAN-8, UPC-A, ITF-14, Code 128 e Code 39, com o dígito verificador do varejo calculado, e um número errado ou curto é recusado em vez de ser completado silenciosamente num código de barras válido de outro produto.