Outils de développement · Encodeur et décodeur Base64
Comment l'en-tête d'authentification HTTP Basic est construit et décodé avec Base64
· Comment ça marche
base64 sécurité
L'en-tête Authorization: Basic est simplement un nom d'utilisateur: un mot de passe exécuté via Base64. Cet article montre comment la valeur est construite, comment en décoder une à partir d'un journal de requêtes et pourquoi l'encodage ne cache rien.
Le 401 qui persiste même si les informations d'identification sont correctes - une valeur d'en-tête qui décode en une chaîne subtilement erronée
Une API HTTP renvoie 401 Unauthorized et attend un en-tête Authorization: Basic. La valeur est le mot de schéma Basic, un espace et une chaîne Base64. Un préfixe manquant, un préfixe codé ou une nouvelle ligne inaperçue modifie ce que le serveur reçoit même lorsque le nom d'utilisateur et le mot de passe visibles semblent corrects.
Décodez cette chaîne et elle lit username:password (littéralement deux points entre deux). Les octets nom d'utilisateur: mot de passe sont codés UTF-8 puis codés en Base64, produisant une valeur d'en-tête. Si les informations d'identification sont admin:s3cret, les octets UTF-8 sont 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (lettres ASCII plus deux-points), le codage Base64 produit YWRtaW46czNjcmV0 et l'en-tête est Autorisation : Basique YWRtaW46czNjcmV0.
La recette de RFC 7617 : 'user:pass', UTF-8, Base64 — les étapes exactes et le rôle des deux points
Il s'agit du schéma d'authentification HTTP Basic complet défini dans la RFC 7617. Il est simple, standardisé et n'offre aucune sécurité en soi : toute personne lisant l'en-tête peut immédiatement le décoder pour lire le mot de passe. C'est pourquoi HTTPS est obligatoire pour l'authentification de base. Le codage est une exigence de transport et non une fonction de sécurité. Le mot de passe voyage sur UTF-8 octets, comme toute autre donnée ; Base64 n'est qu'une notation utilisée dans le protocole HTTP.
Si vous avez besoin de décoder l'en-tête Basic du journal réseau, le processus est simple : supprimez Basic, le reste du décodage Base64 et vous obtenez le nom d'utilisateur : mot de passe. Deux points sont le délimiteur entre le nom d'utilisateur et le mot de passe. RFC 7617 spécifie que les informations d'identification sont l'identifiant utilisateur : mot de passe et les premiers deux-points sont un séparateur. Si le mot de passe contient deux points, le deuxième deux-points n'est qu'un autre caractère du mot de passe. Le côlon est structurel car le récepteur a besoin d’une frontière sans ambiguïté. Il recherche le premier deux-points après décodage ; tout ce qui précède identifie l'utilisateur et tout ce qui suit est le mot de passe. Un deux-points manquant indique donc une paire d'informations d'identification mal formée, et non un problème d'alphabet Base64.
Exemple pratique : encodage de admin:s3cret et décodage d'un en-tête à partir d'un journal – dans les deux sens, y compris un bug de nouvelle ligne de fin
Si le nom d'utilisateur est admin et le mot de passe est pass:word, les informations d'identification sont admin:pass:word, qui code en YWRtaW46cGFzczp3b3Jk. Lors du décodage, il doit être divisé uniquement sur les premiers deux-points, en donnant le nom d'utilisateur admin et le mot de passe pass:word. Le fractionnement sur chaque deux-points diviserait incorrectement le mot de passe. Le paramètre charset dans la RFC 7617 indique que les informations d'identification sont codées en UTF-8. Cela signifie que les caractères non-ASCII dans les noms d'utilisateur ou les mots de passe sont convertis en UTF-8 octets avant l'encodage Base64.
Si le nom d'utilisateur est café (e accentué), UTF-8 octets sont 0x63 0x61 0x66 0xC3 0xA9 (quatre octets pour les lettres ASCII plus deux pour les caractères accentués) et les informations d'identification complètes café:password contiennent des octets pour café, puis l'octet deux-points 0x3A, puis le mot de passe. La sortie Base64 code fidèlement tous les octets. Le décodeur doit savoir interpréter les octets décodés comme du texte UTF-8, et non comme du latin-1.
Mots de passe contenant des deux-points, des espaces et des caractères non-ASCII – pourquoi les premiers deux-points se divisent et à quoi sert le paramètre charset
Un exemple concret : commencez par admin:s3cret. Convertir en UTF-8 octets : a=0x61, d=0x64, m=0x6D, i=0x69, n=0x6E, :=0x3A, s=0x73, 3=0x33, c=0x63, r=0x72, e=0x65, t=0x74. En décimal : (97, 100, 109, 105, 110, 58, 115, 51, 99, 114, 101, 116). Base64 encode ces 12 octets : regroupez-les en quatre groupes de trois (produisez quatre groupes de quatre caractères Base64).
La valeur codée est YWRtaW46czNjcmV0. L’en-tête d’autorisation est Autorisation : Basique YWRtaW46czNjcmV0. Le côté mot de passe peut contenir un autre deux-points sans déplacer cette première limite. Les espaces et le texte non-ASCII survivent également lorsque les deux pairs s'accordent sur le codage du texte. ToolAcre peut vérifier les octets UTF-8 qu'il émet, mais un serveur plus ancien qui attend un jeu de caractères différent reste un problème d'interopérabilité en dehors de la transformation Base64.
Pourquoi cela n'est pas sécurisé sans TLS : le décodage montre le mot de passe à toute personne voyant l'en-tête
Pour décoder l'en-tête reçu, supprimez Basic, Base64 décode YWRtaW46czNjcmV0 pour récupérer les octets, interprétez comme du texte UTF-8 pour obtenir admin:s3cret, divisé sur les premiers deux-points pour extraire le nom d'utilisateur et le mot de passe. Une erreur courante consiste à suivre la nouvelle ligne depuis echo. Si vous exécutez echo admin:s3cret | base64 dans le shell Unix, echo ajoute une nouvelle ligne par défaut, donc encodez admin:s3cret avec une nouvelle ligne (13 octets au lieu de 12).
La sortie Base64 est différente : YWRtaW46czNjcmV0Cg== (remplissage et caractères supplémentaires). L'en-tête d'autorisation avec cette valeur échouera car le mot de passe inclut un caractère de nouvelle ligne. Le correctif consiste à utiliser echo -n ou à passer par printf ou un outil qui n'ajoute pas de nouvelles lignes. L'encodeur et le décodeur Base64 évite cela : encode exactement ce que vous collez, pas de nouvelles lignes cachées. TLS modifie la menace de transport, pas le format des informations d'identification. Dans une connexion protégée, l'en-tête est chiffré avec le reste de la requête ; une fois que le logiciel l'enregistre ou l'affiche, la valeur Base64 expose à nouveau les informations d'identification réutilisables à toute personne capable de les décoder. La rédaction compte toujours à chaque point d’observation.
Erreurs courantes : une nouvelle ligne de echo, un préfixe 'Basic' manquant et un double codage de la valeur
Une autre erreur manque le préfixe de base. La valeur de l’en-tête d’autorisation n’est pas valide en Base64 seul ; il s'agit du nom du schéma (Basic ou Bearer ou autres) suivi d'un espace puis des informations d'identification. Certains systèmes ne parviennent pas à reconnaître YWRtaW46czNjcmV0 comme identifiant, mais réussissent avec Basic YWRtaW46czNjcmV0. Si vous déboguez 401, vérifiez si le serveur analyse correctement l’en-tête d’autorisation.
Scheme n'est pas sensible à la casse dans la norme HTTP, mais de nombreuses implémentations sont sensibles à la casse ; consultez la documentation de l'API. Le double codage est un autre mode de défaillance. Si une chaîne encodée en Base64 est déjà codée en Base64, la sortie est une chaîne différente. Le codage YWRtaW46czNjcmV0 produit WVdkbWFXNDZjek5qY3JldA== (entièrement différent). Certains systèmes peuvent accidentellement appliquer le codage deux fois : une fois lors de la configuration des informations d'identification et une autre fois lors de la construction de l'en-tête. Une nouvelle ligne provenant d'une commande shell est particulièrement facile à manquer car elle peut être codée dans le cadre des informations d'identification plutôt que rejetée comme espace autour du Base64. L'en-tête résultant se décode proprement en un mot de passe avec un octet supplémentaire, produisant un 401 qui ressemble à un échec d'authentification côté serveur.
Ce que cela ne couvre pas : schémas Digest et Bearer, et invites d'identification du navigateur
Le décodeur attend une seule couche de Base64, donc le double encodage provoque une incompatibilité. C'est pourquoi la journalisation des valeurs d'identification sous forme Base64 (et non en texte brut) peut prêter à confusion : si quelqu'un applique le décodage une fois, il voit le nom d'utilisateur et le mot de passe ; s'ils sont appliqués deux fois, ils voient une obscurcissement. L'authentification Digest (RFC 7616) et l'authentification Bearer (pour les jetons OAuth) utilisent des schémas différents, chacun avec des formats d'informations d'identification différents.
Digest nécessite que le serveur envoie un nom occasionnel, que le client calcule le hachage et que l'en-tête inclut le hachage plus le nom d'utilisateur, pas le mot de passe. Le porteur est généralement un jeton Web JSON (JWT), qui est codé en Base64url mais sans préfixe du nom d'utilisateur. L'authentification de base est plus simple que les deux mais totalement non sécurisée sans TLS car les informations d'identification sont lisibles dans l'en-tête. Digest et Bearer utilisent le même champ d'en-tête Authorization mais attribuent une signification totalement différente à leurs valeurs. Les invites d'identification du navigateur ajoutent une interface utilisateur et un comportement de mise en cache en plus de Basic. Cet article s'arrête à la construction et à l'inspection de la charge utile des informations d'identification de base plutôt qu'à la comparaison de ces systèmes d'authentification.
À retenir : l'authentification de base est Base64, pas la protection – comment l'encodeur et le décodeur Base64 vous permettent de vérifier une valeur d'en-tête localement sans envoyer les informations d'identification nulle part
Si l'API prend en charge plusieurs schémas d'authentification, choisissez le plus sécurisé disponible. L'encodeur et le décodeur Base64 peuvent aider à déboguer l'échec d'authentification de base : collez la chaîne d'informations d'identification (nom d'utilisateur, deux points et mot de passe) et l'outil produit immédiatement la valeur Base64. Comparez le résultat à l'envoi de l'en-tête et une incompatibilité est visible. À l'inverse, collez la valeur d'en-tête du journal réseau, supprimez le préfixe Basic, décodez pour voir ce que le serveur a vu.
Pour apprendre, collez admin:s3cret et observez le résultat, puis modifiez le mot de passe pour voir comment Base64 change. Comprendre comment l'en-tête est construit clarifie pourquoi le décodage nécessite de connaître le format RFC et pourquoi les deux points sont un élément structurel, et non Base64. Une vérification locale doit utiliser un identifiant inventé, et non un mot de passe réel copié depuis la production. Encodez la paire, déplacez la sortie dans le panneau de saisie et décodez-la. La ponctuation correspondante et les caractères de fin exacts prouvent l'aller-retour de la représentation avant que l'en-tête ne soit envoyé n'importe où.