Erzeuge einen HTTP-Basic-Authentifizierungs-Header aus Benutzername und Passwort, erhalte ein direkt einfügbares curl-Kommando und decodiere ein bestehendes Basic-Token zurück zu den Anmeldedaten.
Erstelle einen HTTP-Basic-Authentifizierungs-Header oder decodiere einen. Gib einen Benutzernamen und ein Passwort ein, um den Authorization-Header, das rohe base64-Token und ein curl-Kommando zu erhalten, das du direkt in ein Terminal einfügen kannst. Der Decoder unten kehrt ein bestehendes Token um.
Ein bestehendes Token decodieren
Alles wird in deinem Browser berechnet und nichts wird übertragen. Stelle dennoch sicher, dass du keine Produktions-Anmeldedaten in eine Webseite einfügst, einschließlich dieser hier.
Wie HTTP-Basic-Authentifizierung tatsächlich funktioniert
Der Mechanismus
Die Basic-Authentifizierung, definiert in RFC 7617, ist das einfachste Schema in HTTP. Der Client verbindet Benutzername und Passwort mit einem Doppelpunkt, codiert das Ergebnis als base64 und sendet es in einem Header:
Authorization: Basic YWxpY2U6czNjcjN0
Wenn ein Server Anmeldedaten verlangt, antwortet er mit 401 Unauthorized samt einem WWW-Authenticate: Basic realm="..."-Header, und der Browser zeigt seinen nativen Anmeldedialog. Es gibt keinen Handshake, keinen Nonce und kein Ablaufdatum – jede Anfrage trägt denselben Header.
Base64 ist keine Verschlüsselung
Das ist der Punkt, den jeder verinnerlichen muss. Base64 ist eine umkehrbare Transportcodierung ohne Schlüssel und ohne Geheimnis. Jeder, der den Header sieht, kann ihn sofort decodieren – genau das macht der Decoder auf dieser Seite. Basic-Auth bietet daher für sich allein keinerlei Vertraulichkeit und darf nur über HTTPS verwendet werden, wo TLS die gesamte Anfrage schützt. Über einfaches HTTP entspricht es dem Versand des Passworts im Klartext.
Die Doppelpunkt-Regel
Der Benutzername darf keinen Doppelpunkt enthalten, weil der erste Doppelpunkt das Trennzeichen ist. Das Passwort darf so viele enthalten, wie es möchte – ein Decoder teilt am ersten und behandelt den Rest als Passwort. Wenn dein Benutzername wirklich einen Doppelpunkt braucht, ist Basic-Auth nicht nutzbar und du benötigst ein anderes Schema.
Zeichencodierung
Die ursprüngliche Spezifikation war vage bezüglich allem außerhalb von ASCII, was historisch dazu führte, dass nicht-ASCII-Passwörter zwischen Clients und Servern brachen. RFC 7617 fügte den Parameter charset="UTF-8" hinzu, damit ein Server seine Erwartung angeben kann, und in der Praxis verwendet jeder moderne Stack UTF-8. Dieses Tool codiert vor dem base64 in UTF-8-Bytes, was dem aktuellen Browserverhalten entspricht.
Wo es noch Sinn ergibt
Basic-Auth bleibt eine vernünftige Wahl für Maschine-zu-Maschine-Aufrufe in internen Netzwerken, für den schnellen Schutz einer Staging-Umgebung hinter nginx oder Apache, für CI-Jobs, die eine einfache Anmeldeinformation benötigen, und als Transport für API-Schlüssel, wobei der Schlüssel ins Benutzername-Feld kommt und das Passwort leer gelassen oder auf einen Platzhalter wie x gesetzt wird. Mehrere Zahlungs- und E-Mail-APIs verwenden genau dieses Muster.
Es ist eine schlechte Wahl für die Endnutzer-Anmeldung auf einer öffentlichen Seite. Es gibt keinen Logout, der Browser zwischenspeichert die Anmeldedaten für die Sitzung, der Dialog lässt sich nicht gestalten, und es gibt keine Möglichkeit, Multi-Faktor-Authentifizierung oder Ratenbegrenzung pro Sitzung hinzuzufügen. Verwende stattdessen ein token- oder sitzungsbasiertes Schema.
Praktische Vorsichtsmaßnahmen
Anmeldedaten, die in eine URL eingebettet sind – user:pass@example.com – sind veraltet und werden von den meisten Browsern blockiert oder entfernt, weil sie in den Verlauf, Protokolle und Referrer-Header auslaufen. Das Übergeben von -u user:pass an curl zeichnet das Passwort ebenfalls im Shell-Verlauf und in der Prozessliste auf, wo andere Benutzer auf dem Rechner es sehen können; verwende lieber -u user und lasse curl fragen, oder lies den Wert aus einer Umgebungsvariablen.
FAQs
Ist Basic-Auth sicher?
Nur über HTTPS. Die base64-Codierung bietet überhaupt keinen Schutz – sie ist trivial umkehrbar. Mit TLS werden die Anmeldedaten auf dem Transport wie alle anderen Anfragedaten geschützt; ohne TLS sind sie effektiv Klartext.
Warum base64, wenn es keine Verschlüsselung ist?
Der Zweck ist Transport-Sicherheit, nicht Geheimhaltung. Base64 stellt sicher, dass die Anmeldeinformation nur header-sichere ASCII-Zeichen enthält, sodass ein Doppelpunkt, ein Leerzeichen oder ein nicht-ASCII-Byte im Passwort den Header nicht verfälschen kann.
Kann der Benutzername einen Doppelpunkt enthalten?
Nein. Der erste Doppelpunkt trennt Benutzername vom Passwort, sodass ein Doppelpunkt im Benutzernamen die Anmeldeinformation mehrdeutig macht. Passwörter dürfen eine beliebige Anzahl von Doppelpunkten enthalten.
Wie logge ich mich aus Basic-Auth aus?
Es gibt keinen ordentlichen Mechanismus. Browser speichern Anmeldedaten für die Sitzung zwischen, und die üblichen Umgehungen sind, den Browser zu schließen oder an einem speziellen Endpunkt eine 401 zurückzugeben. Diese Einschränkung ist ein Grund, warum Basic-Auth für die Endnutzer-Anmeldung ungeeignet ist.
Läuft das Token ab?
Niemals. Derselbe Header ist gültig, bis das Passwort geändert wird, weshalb ein geleaktes Basic-Token so ernst zu nehmen ist wie ein geleaktes Passwort. Rotiere die Anmeldedaten, falls eines jemals offengelegt wird.
Werden meine Anmeldedaten irgendwohin gesendet?
Nein. Die Codierung und Decodierung laufen vollständig in deinem Browser. Dennoch ist es gute Praxis, niemals echte Produktions-Anmeldedaten in eine Webseite einzufügen.