Ferramentas de desenvolvedor · Codificador e decodificador Base64
Como o cabeçalho de autenticação básica HTTP é construído e decodificado com Base64
· Como funciona
base64 segurança
O cabeçalho Authorization: Basic é apenas nome de usuário: senha executado em Base64. Esta postagem mostra como o valor é construído, como decodificar um a partir de um log de solicitação e por que a codificação não esconde nada.
O 401 que persiste embora as credenciais estejam corretas — um valor de cabeçalho que decodifica para uma string sutilmente errada
Um HTTP API retorna 401 Unauthorized e espera um cabeçalho Authorization: Basic. O valor é a palavra do esquema Basic, um espaço e uma string Base64. Um prefixo ausente, um prefixo codificado ou uma nova linha despercebida altera o que o servidor recebe mesmo quando o nome de usuário e a senha visíveis parecem corretos.
Decodifique essa string e ela lerá nome de usuário: senha (literalmente dois pontos entre dois). Os bytes nome de usuário: senha são codificados em UTF-8 e depois codificados em Base64, produzindo valor de cabeçalho. Se as credenciais forem admin:s3cret, UTF-8 bytes são 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (ASCII letras mais dois pontos), a codificação Base64 produz YWRtaW46czNjcmV0, e o cabeçalho é Autorização: Basic YWRtaW46czNjcmV0.
A receita de RFC 7617: 'user:pass', UTF-8, Base64 - as etapas exatas e a função dos dois pontos
Este é o esquema de autenticação básico completo HTTP definido em RFC 7617. É simples, padronizado e não oferece segurança por si só: qualquer pessoa que leia o cabeçalho pode decodificá-lo imediatamente para ler a senha. É por isso que HTTPS é obrigatório para autenticação básica. A codificação é um requisito de transporte, não um recurso de segurança. A senha viaja como UTF-8 bytes, assim como qualquer outro dado; Base64 é apenas uma notação usada no protocolo HTTP.
Se for necessário decodificar o cabeçalho Basic do log de rede, o processo é simples: retire o restante da decodificação Basic, Base64 e você terá nome de usuário: senha. Dois pontos é o delimitador entre nome de usuário e senha. RFC 7617 especifica que as credenciais são ID do usuário: senha e o primeiro dois pontos é o separador. Se a senha contiver dois pontos, o segundo dois pontos será apenas outro caractere na senha. Os dois pontos são estruturais porque o receptor precisa de um limite inequívoco. Ele procura os primeiros dois pontos após a decodificação; tudo antes de identificar o usuário e tudo depois é a senha. Portanto, dois pontos ausentes indicam um par de credenciais malformado, não um problema do alfabeto Base64.
Exemplo resolvido: codificação admin:s3cret e decodificação de um cabeçalho de um log - ambas as direções, incluindo um bug de nova linha final
Se o nome de usuário for admin e a senha for pass:word, as credenciais serão admin:pass:word, que codifica para YWRtaW46cGFzczp3b3Jk. Ao decodificá-lo, deve-se dividir apenas nos primeiros dois pontos, fornecendo o nome de usuário admin e a senha pass:word. A divisão em cada dois pontos dividiria incorretamente a senha. O parâmetro charset em RFC 7617 indica que as credenciais são codificadas em UTF-8. Isso significa que caracteres não ASCII em nomes de usuário ou senhas são convertidos em UTF-8 bytes antes da codificação Base64.
Se o nome de usuário for café (e acentuado), os bytes UTF-8 são 0x63 0x61 0x66 0xC3 0xA9 (quatro bytes para letras ASCII mais dois para caracteres acentuados) e as credenciais completas café:password têm bytes para café, depois o byte de dois pontos 0x3A e depois a senha. A saída Base64 codifica todos os bytes fielmente. O decodificador deve saber interpretar bytes decodificados como texto UTF-8, não Latin-1.
Senhas contendo dois pontos, espaços e não ASCII — por que os primeiros dois pontos se dividem e para que serve o parâmetro charset
Um exemplo prático: comece com admin:s3cret. Converter em bytes UTF-8: a=0x61, d=0x64, m=0x6D, i=0x69, n=0x6E, :=0x3A, s=0x73, 3=0x33, c=0x63, r=0x72, e=0x65, t=0x74. Em decimal: (97, 100, 109, 105, 110, 58, 115, 51, 99, 114, 101, 116). Base64 codifica estes 12 bytes: agrupe em quatro grupos de três (produza quatro grupos de quatro caracteres Base64).
O valor codificado é YWRtaW46czNjcmV0. O cabeçalho de autorização é Autorização: Basic YWRtaW46czNjcmV0. O lado da senha pode conter outros dois pontos sem mover o primeiro limite. Espaços e texto não ASCII também sobrevivem quando ambos os pares concordam com a codificação do texto. ToolAcre pode verificar os bytes UTF-8 que emite, mas um servidor mais antigo que espera um conjunto de caracteres diferente continua sendo um problema de interoperabilidade fora da transformação Base64.
Por que isso não é seguro sem TLS — a decodificação mostra a senha para qualquer pessoa que veja o cabeçalho
Para decodificar o cabeçalho recebido, retire o básico, decodifique Base64 YWRtaW46czNjcmV0 para recuperar os bytes, interprete como texto UTF-8 para obter admin:s3cret, divida nos primeiros dois pontos para extrair o nome de usuário e a senha. Um erro comum é seguir a nova linha do eco. Se executar echo admin:s3cret | base64 no shell Unix, echo adiciona nova linha por padrão, então codifique admin:s3cret com nova linha (13 bytes em vez de 12).
A saída Base64 é diferente: YWRtaW46czNjcmV0Cg== (preenchimento e caracteres extras). O cabeçalho de autorização com este valor falhará porque a senha inclui caracteres de nova linha. A correção é usar echo -n ou passar por printf ou ferramenta que não acrescenta novas linhas. O codificador e decodificador Base64 evita isso: codifica exatamente o que você cola, sem novas linhas ocultas. TLS altera a ameaça de transporte, não o formato da credencial. Dentro de uma conexão protegida o cabeçalho é criptografado com o restante da solicitação; depois que o software a registra ou exibe, o valor Base64 expõe novamente a credencial reutilizável para qualquer pessoa capaz de decodificá-la. A redação ainda é importante em todos os pontos de observação.
Erros comuns - uma nova linha de echo, um prefixo 'Basic' ausente e codificação dupla do valor
Outro erro é a falta do prefixo básico. O valor do cabeçalho de autorização não é válido apenas para Base64; é o nome do esquema (Básico ou Portador ou outros) seguido de espaço e depois credencial. Alguns sistemas não reconhecem YWRtaW46czNjcmV0 como credencial, mas são bem-sucedidos com YWRtaW46czNjcmV0 básico. Se estiver depurando 401, verifique se o servidor está analisando o cabeçalho de autorização corretamente.
O esquema não diferencia maiúsculas de minúsculas no padrão HTTP, mas muitas implementações diferenciam maiúsculas de minúsculas; verifique a documentação API. A codificação dupla é outro modo de falha. Se a string de codificação Base64 já estiver codificada em Base64, a saída será uma string diferente. A codificação YWRtaW46czNjcmV0 produz WVdkbWFXNDZjek5qY3JldA== (completamente diferente). Alguns sistemas podem acidentalmente aplicar a codificação duas vezes: uma vez durante a configuração da credencial e novamente ao construir o cabeçalho. Uma nova linha de um comando shell é especialmente fácil de perder porque pode ser codificada como parte da credencial em vez de rejeitada como espaço em branco ao redor do Base64. O cabeçalho resultante é decodificado de forma limpa para uma senha com um byte extra, produzindo um 401 que parece uma falha de autenticação do lado do servidor.
O que isso não cobre – esquemas Digest e Bearer e solicitações de credenciais do navegador
O decodificador espera uma camada única de Base64, portanto, a codificação dupla causa incompatibilidade. É por isso que registrar valores de credenciais no formato Base64 (não em texto simples) pode ser confuso: se alguém aplicar a decodificação uma vez, verá o nome de usuário e a senha; se aplicado duas vezes, eles verão ofuscação. A autenticação Digest (RFC 7616) e a autenticação Bearer (para tokens OAuth) usam esquemas diferentes, cada um com formatos de credenciais diferentes.
O Digest exige que o servidor envie o nonce, o cliente para calcular o hash e o cabeçalho inclua o hash mais o nome de usuário, não a senha. O portador normalmente é JSON Web Token (JWT), que é codificado em Base64url, mas não prefixado com nome de usuário. A autenticação básica é mais simples que ambas, mas completamente insegura sem TLS porque as credenciais podem ser lidas no cabeçalho. Digest e Bearer usam o mesmo campo de cabeçalho de autorização, mas atribuem significados totalmente diferentes aos seus valores. Os prompts de credenciais do navegador adicionam interface do usuário e comportamento de cache além do Básico. Este artigo se concentra na construção e inspeção da carga útil da credencial Básica, em vez de comparar esses sistemas de autenticação.
Conclusão: autenticação básica é Base64, não proteção - como o codificador e decodificador Base64 permite verificar um valor de cabeçalho localmente sem enviar a credencial para qualquer lugar
Se API suportar vários esquemas de autenticação, escolha o mais seguro disponível. O codificador e decodificador Base64 pode ajudar a depurar falha de autenticação básica: cole a string de credencial (nome de usuário, dois pontos e senha) e a ferramenta produz o valor Base64 imediatamente. Compare o resultado com o envio do cabeçalho e a incompatibilidade é visível. Por outro lado, cole o valor do cabeçalho do log da rede, retire o prefixo básico e decodifique para ver o que o servidor viu.
Para aprender, cole admin:s3cret e observe a saída, depois modifique a senha para ver como o Base64 muda. Compreender como o cabeçalho é construído esclarece por que a decodificação requer o conhecimento do formato RFC e por que dois pontos é um elemento estrutural, não Base64. Uma verificação local deve usar uma credencial inventada, não uma senha ativa copiada da produção. Codifique o par, mova a saída de volta para o painel de entrada e decodifique-a. A pontuação correspondente e os caracteres finais exatos comprovam a representação de ida e volta antes que o cabeçalho seja enviado para qualquer lugar.