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.

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.