Entwicklertools · Base64-Encoder und -Decoder
Wie der HTTP-Basic-Authentifizierungsheader mit Base64 erstellt und dekodiert wird
· Wie es funktioniert
base64 Sicherheit
Der Authorization: Basic-Header besteht nur aus Benutzername:Passwort, das über Base64 ausgeführt wird. Dieser Beitrag zeigt, wie der Wert erstellt wird, wie man ihn aus einem Anforderungsprotokoll dekodiert und warum die Kodierung nichts verbirgt.
Der 401, der bestehen bleibt, obwohl die Anmeldeinformationen richtig sind – ein Header-Wert, der in eine subtil falsche Zeichenfolge dekodiert wird
Eine HTTP-API gibt 401 Unauthorized zurück und erwartet einen Authorization: Basic-Header. Der Wert besteht aus dem Schemawort Basic, einem Leerzeichen und einer Base64-Zeichenfolge. Ein fehlendes Präfix, ein codiertes Präfix oder ein unbemerkter Zeilenumbruch verändert das, was der Server empfängt, selbst wenn der sichtbare Benutzername und das Passwort korrekt aussehen.
Dekodieren Sie diese Zeichenfolge und sie lautet Benutzername:Passwort (wörtlich: Doppelpunkt zwischen zwei). Bytes Benutzername:Passwort werden UTF-8 und dann Base64-codiert, wodurch ein Header-Wert entsteht. Wenn die Anmeldeinformationen admin:s3cret lauten, sind UTF-8 Bytes 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (ASCII-Buchstaben plus Doppelpunkt). Die Base64-Kodierung erzeugt YWRtaW46czNjcmV0 und einen Header ist Autorisierung: Basic YWRtaW46czNjcmV0.
Das Rezept aus RFC 7617: 'user:pass', UTF-8, Base64 – die genauen Schritte und die Rolle des Doppelpunkts
Dies ist das vollständige HTTP-Basic-Authentifizierungsschema, das in RFC 7617 definiert ist. Es ist einfach, standardisiert und bietet an sich keine Sicherheit: Jeder, der den Header liest, kann ihn sofort entschlüsseln, um das Passwort zu lesen. Aus diesem Grund ist HTTPS für die Basisauthentifizierung obligatorisch. Die Verschlüsselung ist eine Transportanforderung, kein Sicherheitsmerkmal. Das Passwort wird wie alle anderen Daten als UTF-8 Byte übertragen. Base64 ist lediglich eine Notation, die im HTTP-Protokoll verwendet wird.
Wenn der Basic-Header aus dem Netzwerkprotokoll dekodiert werden muss, ist der Vorgang unkompliziert: Basic entfernen, Base64-Rest dekodieren, und Sie haben Benutzername:Passwort. Der Doppelpunkt ist das Trennzeichen zwischen Benutzername und Passwort. RFC 7617 gibt an, dass die Anmeldeinformationen Benutzer-ID: Passwort sind und der erste Doppelpunkt ein Trennzeichen ist. Wenn das Passwort einen Doppelpunkt enthält, ist der zweite Doppelpunkt nur ein weiteres Zeichen im Passwort. Der Doppelpunkt ist strukturell, da der Empfänger eine eindeutige Grenze benötigt. Nach der Dekodierung wird nach dem ersten Doppelpunkt gesucht. alles davor identifiziert den Benutzer und alles danach ist das Passwort. Ein fehlender Doppelpunkt weist daher auf ein fehlerhaftes Anmeldeinformationspaar und nicht auf ein Base64-Alphabet-Problem hin.
Bearbeitetes Beispiel: Kodierung von admin:s3cret und Dekodierung eines Headers aus einem Protokoll – beide Richtungen, einschließlich eines Trailing-Newline-Fehlers
Wenn der Benutzername admin und das Passwort pass:word ist, lauten die Anmeldeinformationen admin:pass:word, was zu YWRtaW46cGFzczp3b3Jk kodiert. Bei der Dekodierung muss nur der erste Doppelpunkt geteilt werden, wobei der Benutzername „admin“ und das Passwort „pass:word“ angegeben werden müssen. Bei einer Aufteilung nach jedem Doppelpunkt würde das Passwort fälschlicherweise geteilt. Der Zeichensatzparameter in RFC 7617 gibt an, dass Anmeldeinformationen UTF-8 codiert sind. Dies bedeutet, dass Nicht-ASCII-Zeichen in Benutzernamen oder Passwörtern vor der Base64-Codierung in UTF-8 Bytes konvertiert werden.
Wenn der Benutzername Café ist (mit Akzent e), sind UTF-8 Bytes 0x63 0x61 0x66 0xC3 0xA9 (vier Bytes für ASCII-Buchstaben plus zwei für Akzentzeichen), und die vollständigen Anmeldeinformationen café:password haben Bytes für Café, dann Doppelpunktbyte 0x3A, dann Passwort. Die Base64-Ausgabe kodiert alle Bytes originalgetreu. Der Decoder muss dekodierte Bytes als UTF-8-Text und nicht als lateinischen 1 interpretieren können.
Passwörter, die Doppelpunkte, Leerzeichen und Nicht-ASCII enthalten – warum der erste Doppelpunkt geteilt wird und wozu der Zeichensatzparameter dient
Ein funktionierendes Beispiel: Beginnen Sie mit admin:s3cret. In UTF-8 Bytes konvertieren: a=0x61, d=0x64, m=0x6D, i=0x69, n=0x6E, :=0x3A, s=0x73, 3=0x33, c=0x63, r=0x72, e=0x65, t=0x74. In Dezimalzahl: (97, 100, 109, 105, 110, 58, 115, 51, 99, 114, 101, 116). Base64-Codierung dieser 12 Bytes: Gruppieren Sie sie in vier Gruppen zu je drei (erzeugen Sie vier Gruppen zu je vier Base64-Zeichen).
Der codierte Wert ist YWRtaW46czNjcmV0. Der Autorisierungsheader lautet Autorisierung: Basic YWRtaW46czNjcmV0. Die Passwortseite kann einen weiteren Doppelpunkt enthalten, ohne die erste Grenze zu verschieben. Leerzeichen und Nicht-ASCII-Text bleiben ebenfalls bestehen, wenn sich beide Partner auf die Textcodierung einigen. ToolAcre kann die ausgegebenen UTF-8-Bytes überprüfen, aber ein älterer Server, der einen anderen Zeichensatz erwartet, bleibt außerhalb der Base64-Transformation ein Interoperabilitätsproblem.
Warum dies ohne TLS nicht sicher ist – durch die Dekodierung wird das Passwort jedem angezeigt, der den Header sieht
Um den empfangenen Header zu dekodieren, entfernen Sie Basic, Base64 dekodieren Sie YWRtaW46czNjcmV0, um Bytes zurückzubekommen, interpretieren Sie ihn als UTF-8 Text, um admin:s3cret zu erhalten, teilen Sie ihn im ersten Doppelpunkt auf, um Benutzername und Passwort zu extrahieren. Ein häufiger Fehler ist das Anhängen einer neuen Zeile an echo. Wenn Sie echo admin:s3cret | ausführen base64 in der Unix-Shell fügt Echo standardmäßig eine neue Zeile hinzu, also codieren Sie admin:s3cret mit einer neuen Zeile (13 Bytes statt 12).
Base64-Ausgabe ist anders: YWRtaW46czNjcmV0Cg== (Auffüllen und zusätzliche Zeichen). Der Autorisierungsheader mit diesem Wert schlägt fehl, da das Kennwort ein Zeilenumbruchzeichen enthält. Die Lösung besteht darin, echo -n oder Pipe durch printf oder ein Tool zu verwenden, das keine Zeilenumbrüche anhängt. Der Base64-Encoder und -Decoder vermeidet dies: Codiert genau das, was Sie einfügen, keine versteckten Zeilenumbrüche. TLS ändert die Transportbedrohung, nicht das Anmeldeinformationsformat. Innerhalb einer geschützten Verbindung wird der Header mit dem Rest der Anfrage verschlüsselt; Sobald die Software sie protokolliert oder anzeigt, macht der Base64-Wert die wiederverwendbaren Anmeldeinformationen erneut für jeden verfügbar, der sie entschlüsseln kann. Die Schwärzung ist immer noch an jedem Beobachtungspunkt wichtig.
Häufige Fehler – eine neue Zeile von echo, ein fehlendes „Basic“-Präfix und eine doppelte Kodierung des Werts
Bei einem weiteren Fehler fehlt das Basispräfix. Der Wert des Autorisierungsheaders ist nicht gültig. Base64 allein; Es handelt sich um den Namen des Schemas (Basic oder Bearer oder andere), gefolgt von einem Leerzeichen und dann einem Berechtigungsnachweis. Einige Systeme erkennen YWRtaW46czNjcmV0 nicht als Anmeldeinformationen, sind aber mit Basic YWRtaW46czNjcmV0 erfolgreich. Überprüfen Sie beim Debuggen von 401, ob der Server den Autorisierungsheader korrekt analysiert.
Beim Schema wird im HTTP-Standard die Groß-/Kleinschreibung nicht beachtet, aber bei vielen Implementierungen wird die Groß-/Kleinschreibung beachtet; Überprüfen Sie die API-Dokumentation. Doppelte Codierung ist ein weiterer Fehlermodus. Wenn eine Base64-codierte Zeichenfolge bereits Base64-codiert ist, ist die Ausgabe eine andere Zeichenfolge. Die Codierung von YWRtaW46czNjcmV0 erzeugt WVdkbWFXNDZjek5qY3JldA== (völlig anders). Einige Systeme wenden die Codierung möglicherweise versehentlich zweimal an: einmal während der Einrichtung der Anmeldeinformationen und noch einmal beim Erstellen des Headers. Ein Zeilenumbruch aus einem Shell-Befehl ist besonders leicht zu übersehen, da er als Teil der Anmeldeinformationen codiert werden kann und nicht als Leerzeichen um Base64 herum abgelehnt wird. Der resultierende Header dekodiert sauber in ein Passwort mit einem zusätzlichen Byte und erzeugt einen 401, der wie ein serverseitiger Authentifizierungsfehler aussieht.
Was hiervon nicht abgedeckt wird: Digest- und Bearer-Schemata sowie Eingabeaufforderungen für Browser-Anmeldeinformationen
Der Decoder erwartet eine einzelne Base64-Schicht, daher führt die doppelte Codierung zu einer Nichtübereinstimmung. Aus diesem Grund kann das Protokollieren von Anmeldedatenwerten im Base64-Format (nicht im Klartext) verwirrend sein: Wenn jemand die Dekodierung einmal anwendet, sieht er Benutzername und Passwort; Bei zweimaliger Anwendung sehen sie eine Verschleierung. Die Digest-Authentifizierung (RFC 7616) und die Bearer-Authentifizierung (für OAuth-Tokens) verwenden unterschiedliche Schemata mit jeweils unterschiedlichen Anmeldeinformationsformaten.
Digest erfordert, dass der Server Nonce sendet, der Client den Hash berechnet und der Header den Hash plus Benutzernamen und kein Passwort enthält. Träger ist in der Regel das Web-Token JSON (JWT), das Base64-URL-codiert ist, dem jedoch kein Benutzername vorangestellt ist. Die Basisauthentifizierung ist einfacher als beide, aber ohne TLS völlig unsicher, da die Anmeldeinformationen im Header lesbar sind. Digest und Bearer verwenden dasselbe Authorization-Header-Feld, weisen ihren Werten jedoch eine völlig unterschiedliche Bedeutung zu. Browser-Anmeldeinformationsaufforderungen fügen zusätzlich zu Basic eine Benutzeroberfläche und ein Caching-Verhalten hinzu. In diesem Artikel geht es nur um die Erstellung und Überprüfung der Nutzlast für Basis-Anmeldeinformationen und nicht um den Vergleich dieser Authentifizierungssysteme.
Fazit: Die Basisauthentifizierung ist Base64, kein Schutz – wie Sie mit dem Base64-Encoder und -Decoder einen Header-Wert lokal überprüfen können, ohne die Anmeldeinformationen irgendwohin zu senden
Wenn die API mehrere Authentifizierungsschemata unterstützt, wählen Sie das sicherste verfügbare Schema. Der Base64-Encoder und -Decoder kann beim Debuggen von Basic-Authentifizierungsfehlern helfen: Fügen Sie die Anmeldeinformationszeichenfolge (Benutzername, Doppelpunkt und Passwort) ein, und das Tool erzeugt sofort einen Base64-Wert. Vergleichen Sie das Ergebnis mit dem gesendeten Header. Es ist eine Abweichung erkennbar. Fügen Sie umgekehrt den Header-Wert aus dem Netzwerkprotokoll ein, entfernen Sie das Basispräfix und dekodieren Sie, um zu sehen, was der Server gesehen hat.
Zum Lernen fügen Sie admin:s3cret ein und beobachten die Ausgabe. Ändern Sie dann das Passwort, um zu sehen, wie sich Base64 ändert. Wenn man versteht, wie Header aufgebaut sind, wird klar, warum für die Dekodierung die Kenntnis des RFC-Formats erforderlich ist und warum Doppelpunkte ein Strukturelement und nicht Base64 sind. Für eine lokale Prüfung sollten erfundene Anmeldeinformationen verwendet werden, kein Live-Passwort, das aus der Produktion kopiert wurde. Kodieren Sie das Paar, verschieben Sie die Ausgabe zurück in das Eingabefeld und dekodieren Sie sie. Passende Satzzeichen und exakte nachgestellte Zeichen beweisen den Darstellungs-Roundtrip, bevor der Header irgendwohin gesendet wird.