In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

Will man auf einer Webseite einen Login mit Username und Passwort anbieten, gibt es zwei Techniken.

Die klassische HTTP-Authentifizierung nach RFC7617 und RFC7616 ist eine Sache zwischen Webserver und Browser und kann z.B. über eine .htaccess-Datei gesteuert werden. Üblicherweise betrifft der Schutz ein komplettes (Unter-)Verzeichnis mit allem, was da drin ist.

Die Übertragung des Passwortes erfolgt dabei in der Variante "Basic Authentication" (RFC7617) im Klartext (zur sauberen Übertragung von Sonderzeichen wird es lediglich Base64-codiert), gehört bei Verwendung von HTTPS aber zu den verschlüsselten Nutzdaten. Bei der "Digest Access Authentication" (RFC7616) kommt ein Challenge-Response-Verfahren zum Einsatz, dessen Grundprinzip hatte ich beim Thema VoIP/SIP REGISTER erklärt.

Vorteile dieses Standards:

• Es ist ein Standard. Entsprechend kann damit jeder Browser, jedes Endgerät, jedes Tool zum Verarbeiten von URLs/Webaufrufen (z.B. CURL) uvam. umgehen
• Es kommt ohne zusätzliche Komponenten (Cookies o.ä.) aus
• Es bietet eine grundlegende Sicherheit (s.o., Challenge Response-Verfahren)

Nachteile dieses Standards sind:

• Es gibt keine (vernünftige) Logout-Möglichkeit
• Jeder Browser und jedes Endgerät bestimmt selbst, wie es damit umgeht. Der Webdesigner hat keine Möglichkeit, den Login-Bereich zu stylen
• Techniken wie SingleSignOn oder 2FA müssen vom Webserver eingebunden werden (was zwar möglich ist, aber Mitarbeit des Server-Administrators voraussetzt), was bei klassischen Webspace-Angeboten teilweise wegfällt.
• Gleiches gilt für besondere Passwort-Regeln (z.B. "Zugang von bestimmten IP-Adressen aus ohne Passwort möglich") 
• Die Browser-eigene Passwort-Verwaltung kann derartige Zugänge speichern, aber gängige Passwort-Tools wie z.B. 1Password haben i.d.R. keinen Zugriff auf diese Autorisierung.

Update 08/2023: Geht nur mit Cookies!

Ein Leser weist mich darauf hin, dass die Aussage "Es kommt ohne zusätzliche Komponenten (Cookies o.ä.) aus" so in der Praxis nicht zu stimmen scheint, bei deaktivierten Cookies kommt gar keine Abfrage der Zugangsdaten, sondern der Zugang wird direkt verweigert. Ich konnte es nicht glauben, habe schnell auf einem Testserver einen solchen .htaccess-Passwortschutz aktiviert - und es stimmt.

Ich finde dazu keinerlei Hinweis, dass das in irgend einem RFC so vorgesehen sei. Im Gegenteil, ich finde Aussagen die fast wörtlich mit meiner o.g. übereinstimmen: Basic authentication kommt ohne Cookies aus. Darum kann ich nur spekulieren: Bei dieser Art der Autorisierung schickt der Browser im Header den Benutzernamen (plus bei Bedarf das Passwort bzw. die Challenge-Response) mit an den Webserver. Und zwar bei jedem Seitenaufruf. Und auf diese Weise kann der Server den Benutzer wiedererkennen und damit seinen Besuch nachverfolgen. Und weil es keine wirkliche Logout-Funktion gibt, bleibt der User "eingeloggt" so lange, bis er den Browser komplett schließt, d.h. in Zeiten von lediglich zugeklappten Notebooks kann es sein, dass auch in drei Wochen noch mein Browser immer wieder verrät, wer ich bin. 

Cookies kommen zum Einsatz, damit ein Webserver mich wiedererkennt und sich mein Surfverhalten merkt, um mir noch bessere tollere blinkende Werbung zu präsentieren. Und weil viele das nicht wollen, ist es irgendwie naheliegend, dass die Werbebanner-Mafia zu anderen technischen greift, z.B. folgendes: Man simuliert eine Passwort-geschützte Seite (die aber vielleicht nur mit einem Usernamen ohne Passwort auskommt), gibt mir direkt einen eindeutigen Usernamen mit auf den Weg, damit mein Browser den Inhalt abrufen kann ohne mich nach einem Passwort zu fragen, und fortan schicke ich immer brav diesen Usernamen mit und werde trackbar. Und dann ist es irgendwie logisch, dass ein "ich möchte keine Cookies zur Wiedererkennung"-Browser auch derartige andere Versuche einfach ebenfalls im Keim erstickt. 

Tatsächlich, wieder was gelernt: Die aktuellen Browser weichen da (aus gutem Grund) etwas vom RFC ab.

Die Alternative dazu sind "selbst gebaute" Logins innerhalb der Webanwendung: Ein Formular mit Username und Passwort, und die Anwendung (z.B. ein PHP-Script dahinter) werden diese Daten aus. Technisch ist das ein normales Formular, d.h. man kann es als Webentwickler stylen, man kann per JavaScript damit arbeiten (z.B. schon vor dem Absenden prüfen, ob überhaupt was eingegeben wurde), und der User kann über Formular-Ausfüllhilfen oder Passwort-Manager auch den Inhalt der Formularfelder speichern.

Die Webanwendung dahinter erhält das eingegebene Passwort als Formular-Inhalt (i.d.R. "POST-Request") und wertet es in eigenem Ermessen aus. Dinge wie SSO und 2FA können einfach innerhalb der Webanwendung entwickelt werden (und erfordern keine Zuarbeit des Server-Administrators), und auch Sonder-Regeln (Login ohne Passwort, wenn man von einer bestimmten IP-Adresse kommt) kann der Entwickler selbst konfigurieren. 

Sobald der Login erfolgt ist, ist es Aufgabe der Webanwendung, den User beim weiteren Verlauf der Sitzung wiederzuerkennen. Meist wird dafür eine z.B. PHP-Session angelegt mit einem Sitzungs-Cookie.

Nachteile dieser Technik sind:

• Außerhalb von Browsern ist der Login deutlich erschwert. Ruft man per Script (CURL o.ä.) eine solche Seite auf, kann man meist nicht direkt die Zugangsdaten übergeben, sondern muss mehrstufig den Login "nachspielen" und dabei auch das Session-Cookie mitspeichern usw.
• Der Weg über die Session-Cookies ist komplexer (und mehr Komplexitität sorgt für mehr zu berücksichtigende Sicherheitsaspekte, z.B. können Session-Cookies per XSS o.ä. geklaut und damit eine Session übernommen werden)
• Die konkrete Sicherheit obliegt ausschließlich dem Webentwickler. Von "das Passwort wird im Klartext übertragen und im Klartext in der Datenbank gesucht" bis "im Browser erfolgt bereits eine Vorverschlüsselung per JavaScript, und auf dem Server wird nur mit sicheren Hashes gearbeitet" gibt es da quasi alles.

Bei einer HTTP-Authentifizierung nach RFC7616 / 7617 kann man (von den meisten Endgeräten/Browsern unterstützt) Zugangsdaten in der URL übergeben.

Der Seitenaufruf hat dann das Format http(s):// + Username + Passwort + @ + Servername/, also man hängt Username:Passwort@ vor die URL, fertig. Hat man ein Telefon mit Display (Yealink-Tischtelefon, AVM FritzFon Schnurstelefon, ...) und eine Video-Türsprechanlage (z.B. meine Doorbird), dann kann das Telefon einfach die Zugangsdaten zum Aufruf des Kamerabildes mitschicken und da Bild auf dem Telefondisplay anzeigen.

Eine Zeitlang wurden @-Domains von einigen Webhosting-Anbietern so vermarktet, dass jedes Familienmitglied seine eigene Webseite passend zur Mail-Adresse bekommen kann: Also peter@mueller.de hat seine persönliche Webseite, die man so im Browser eingeben kann. Technisch überträgt der Browser damit "peter" als Username (ohne Passwort) an den Server mueller.de - und der wertet diese "freiwillige" Authenzifierung und ruft dann die passende Unterseite auf. Hat sich nicht durchgesetzt.

@-Domains spielten zumindest früher eine Rolle beim Phishing. Man lockt das Opfer auf eine URL im Format

https + // + secureportal.login.deutschepost.de|login-fuer-packstationskunden|$LANG=DE&login-provider@secureportal.j7t.de  

die auf den ersten Blick wie eine Webseite der Deutschen Post aussieht - aber wenn man sie sich die URL anguckt, dann ist es ein unglaublich langer Username, der einfach an die Webseite "secureportal.j7t.de" übertragen wird. Der Benutzer landet auf einer ganz anderen Seite, als er zuvor dachte. Die Methode hat zu lange zu gut funktioniert, so dass inzwischen gilt:

• sobald vor dem @ etwas kommt, was wie ein Hostname aussieht, wird der auch benutzt. Deshalb beginnt mein Beispiel auch mit ...deutschepost.de|login-fuer... statt mit ...deutschepost.de/login-fuer..., denn dann hätte der Browser vermutet, dass ich auf den Post-Server zugreifen will
• sobald ich auf eine solche URL verlinke, werden die "Zugangsdaten" ausgeblendet. Im Mouseover-Effekt sieht man dann nur noch den richtigen Hostnamen.

Dennoch: Durch neue Domain-Endungen wie ".zip", durch die es noch schwieriger wird, eine Domain als solche zu erkennen, ist diese Methode wieder etwas in Mode gekommen, wie in diesem YouTube-Video mal jemand erklärt hat.