In dem Security Now Podcast kam in den letzten Wochen – wenigstens bis Folge 965 – getrieben von Hörerkommentaren immer wieder ein Thema hoch: Was ist von ‚passwortlosen‘ Logins per E-Mail zu halten? Der Begriff ‚passwortlos‘ wird im Kontext der zunehmenden Verbreitung von Passkeys gerade oft gebraucht, so gibt es etwa bei Google eine Seite mit dem Titel Passwordless login with passkeys.

Aber wäre es da nicht interessant ein passwortloses Loginschema zu haben, das ohne komplizierte Kryptografie und ohne Abhängigkeit zu den großen Betriebssystemanbietern oder Passwort-Managern auskommt? Die Idee ein Verfahren wie E-Mail, das aus der Steinzeit des Internets kommt, gegen eine hochmoderne Idee für Loginverfahren antreten zu lassen, hat dabei einen eigenen Reiz, und am Ende könnte es hier auch im Umfeld von modernen Anwendungen auf Smartphones ein Anwendungsszenario geben:

Wie funktioniert das Verfahren

Mir ist so ein Verfahren zum ersten Mal bei Slack begegnet, dort gab es schon vor Jahren die Loginoption des ‚magischen Links‘. Der Ablauf ist dabei grundsätzlich so:

1. Auf der Seite des Dienstes, in den ich mich einloggen möchte, gebe ich die E-Mailadresse ein, die zu meinem Konto gehört
2. Der Dienst schickt an diese Adresse einen Link mit etwas ‚magischem‘, dazu im nächsten Absatz mehr
3. Ich öffne den Link aus meinem Mailpostfach in meinem Webbrowser
4. Der Dienst prüft den Link und erzeugt damit eine aktive Loginsitzung für mich
5. So lange das Sitzungstoken gültig ist bin ich in diesem Webbrowser eingeloggt

Passwortreset – umdefiniert

Das Verfahren des ‚magischen‘ Link Logins hat große Ähnlichkeiten mit den Verfahren, die man für einen Passwortreset per E-Mail implementiert und vielleicht sind die ersten entsprechenden Loginverfahren auch daraus entstanden:

Bei einem Passwortreset wird ein Link zugeschickt mit einem kaum zu erratenden Bestandteil wie einer ausreichend langen, zufälligen Zeichenkette. Sobald Nutzer*innen diesen Link aufrufen muss das Resetverfahren prüfen ob der Link bekannt und noch gültig ist und zu welchem Account er gehört. Nach dieser Prüfung wird die Option angeboten ein neues Passwort zu setzen und Logins damit in Zukunft erfolgreich durchführen zu können.

Aus Sicht der Nutzer*innen ist das durchaus umständlich, vor allem wenn ich nach dem Passwortreset erst noch das komplette Login mit dem neuen Passwort durchführen muss um endlich in den gewünschten Dienst rein zu kommen. Vielleicht ist hier schon die Idee entstanden, den Nutzer*innen nach dem Passwortreset das erneute Login zu ersparen und sie gleich als angemeldet zu betrachten.

Von da war es dann nur noch ein kurzer Weg dazu den Schritt zum Setzen des neuen Passworts ganz auszulassen und gleich zur Durchführung des Logins zu springen. Bei Diensten wie Slack ist so ein Login dann sehr langlebig.

Absicherung des Verfahrens

Wie kann man so ein Verfahren absichern? Die Überlegungen dazu gelten in sehr ähnlicher Weise für eine Passwortresetfunktion per E-Mail:

Abhängigkeit von der Sicherheit des (externen) Postfachs

Ein Punkt muss bei allen Verfahren, die Sicherheitsfunktionen an E-Mail hängen, bewusst sein: Man macht die Sicherheit des eigenen Dienstes vollständig abhängig von der Sicherheit der Mailpostfächer seiner Nutzer*innen.

Je nach Anwendungsszenario kann das eine Entlastung sein, siehe dazu den Abschnitt zu den Vorteilen einer solchen Lösung für Dienstbetreiber. Gerade bei Einsatzszenarien in Diensten des eigenen Unternehmens wirft es aber sehr stark die Frage nach der Sicherheit des Mailsystems auf. Wenn dieses in Sicherheitshinsicht Defizite hat, so übertragen sich diese auf die angebundenen Dienste.

Die Sinnhaftigkeit der folgenden Überlegungen zu Absicherungen muss dann in einem Gesamtkontext betrachtet werden, damit sie nicht leerer Aufwand oder gar Sicherheitstheater werden:

Linkssicherheit 1: Schutz gegen Erraten

Die Sicherheit des Verfahrens hängt ganz grundsätzlich an der Art der verwendeten Links. Diese dürfen sich nicht erraten oder vorhersagen lassen. So wäre es keine gute Idee, wenn der ‚geheime‘ Teil eines solchen Links aus einem auf dem Server laufenden, immer wieder erhöhten Zähler gebildet würde. So ein Muster wäre einfach zu erkennen und zukünftige, gültige Links könnten vorhergesagt werden.

Auch sollten die Links nicht unnötig interne Strukturen der Architektur wie Schlüssel von Datensätzen nach außen geben oder gar als wesentlichen Bestandteile der Echtheitsprüfung der Links enthalten. Zum einem, um keine potentiell sicherheitsrelevanten Informationen nach außen zu geben und zum anderen, weil solche Strukturen oft wieder auf vorhersagbaren Zählern gebildet werden. Auch eine UUID ist hier nicht unbedingt eine gute Wahl, da sie viele vorhersagbare Bestandteile hat.

Am saubersten ist hier immer noch ein genügend langer, (pseudo)zufälliger String. Zusammen mit einer Begrenzung der Zugriffsraten auf den Endpunkt, den der Link aufruft, und einer begrenzten Lebensdauer sorgt dies für eine ausreichend geringe Wahrscheinlichkeit, dass so ein Link jemals erraten werden kann.

Linkssicherheit 2: Schutz gegen Replay

Zusätzlich zu einer begrenzten Lebensdauer sollten diese Links nach der ersten Verwendung ‚verbraucht‘ sein, sich also nicht erneut aufrufen lassen. Damit schützt man sich vor Angreifern, denen es irgendwie gelingt ebenfalls an diesen Link zu kommen.

Nicht ganz klar ist mir hier ob es Mailanbieter gibt, die in eintreffenden Mails enthaltene Links generell scannen und dabei aufrufen. Dann würde diese Schutzfunktion den Link invalidieren und faktisch wäre das Verfahren dann mit so einem Mailanbieter nicht nutzbar. Denkbar wäre es hier vielleicht die Anzahl der erlaubten Nutzungen auf 2 oder mehr zu erhöhen, was aber weitere Komplexität und ein potentielles Schlupfloch bringt.

Eine Variante in der Implementierung könnte es daher sein, dass Nutzer*innen nach dem Aufruf des Links den Vorgang explizit durch Anklicken eines Buttons abschließen und erst dieser Vorgang das Login durchführt und den Link invalidiert.

Linksicherheit 3: Bindung an den auslösenden Webbrowser

Die Frage, wie man den Missbrauch eines zum Beispiel beim Mailversand abgefangenen Links möglichst verhindert, war auch Teil der Diskussionen im Podcast. Abgesehen von Szenarien, bei denen Angreifer eine Rolle spielen, kann dies aber auch zur Begrenzung der meist nicht gewollten, bewussten Weitergabe von Logins durch die Nutzer*innen selbst beitragen, da sich Loginlinks dann nicht so einfach weiterleiten lassen:

Die Idee besteht darin den Loginlink nur in dem Webbrowser funktionsfähig zu machen, der den Vorgang initiiert hat. Wird er in einer anderen Umgebung aufgerufen wird keine Loginsitzung angelegt und im Idealfall der Link gleich ungültig gemacht. Welche Mittel kann es dazu geben?

Grundsätzlich sind die hier angestellten, umfangreichen Überlegungen dazu, wie man Logincookies gegen Diebstahl sichern kann, auch hier anwendbar. So wäre es ja zum Beispiel schon etwas verdächtig, wenn der magische Link von einem Rechner in Europa angefordert, aber aus einer Infrastruktur im Russland dann eingelöst werden soll.

Es gibt hier aber eine einfachere Möglichkeit: Sofern sich das Formular, in dem die Zustellung des magischen Links angefordert wird, unter der gleichen Domäne befindet wie das Formular, in dem dann der magische Link eingelöst wird, kann hier bei der Linkanforderung ein Cookie mit einem weiteren (zufälligen) Wert platziert werden. Serverseitig wird gemerkt, welches Cookie zu dem magischen Link gehört. Der Abschluss des Logins wird dann vom Vorhandensein des dazugehörenden Cookies abhängig gemacht. Das Cookie darf natürlich nicht das Geheimnis enthalten, welches im magischen Link steckt.

Diese Vorkehrung schützt allerdings nicht davor, dass Angreifer von einem unter ihrer Kontrolle stehenden System aus die Linkzustellung anstoßen und das Opfer per Social Engineering dazu bringen ihnen den Link weiterzuleiten.

Schutz vor automatisiertem Nerven der Nutzerschaft

Es muss ein Schutz eingebaut werden, der eine Belästigung der eigenen Nutzer*innen durch permanentes Auslösen der Reset / Loginfunktion unterbindet. Da das Webformular grundsätzlich ‚offen‘ sein muss um seinen Zweck zu erfüllen, kann es leicht über Scripte bedient und damit beliebig oft von Unbefugten angestoßen werden.

Hier sind clientseitige Funktionen wie ein Captcha denkbar, und serverseitige Begrenzungen, die Zähler führen zur Anzahl der von einer einzelnen IP-Adresse angestoßenen Vorgänge. Im einfachsten Fall kann so eine Schutzfunktion auf den Server bzw. den Endpunkt aufgesattelt werden, wie es z. B. mit dem Anti-DoS-Valve möglich ist.

Ein komplexerer Schutz könnte Mindestabstände bei der Mailzusendung auf einzelnen Nutzer*innen definieren und durchsetzen (‚Nur ein magischer Link alle 30 Minuten‘).

Schutz vor Datenabfluss

Auch dies ist keine einzigartige Aufgabe, die nur in diesem Kontext entsteht, aber trotzdem sollte es für potentielle Angreifer nicht zu einfach sein über diesen Weg herauszufinden, welche E-Mailadressen ein Konto bei einem Anbieter haben.

Vermutlich gibt es kaum einen anderen Weg dafür als auf jede eingetragene E-Mailadresse gleich zu reagieren, egal ob sie mit einem Konto verbunden ist oder nicht oder ob sie gerade auf Grund von zu zahlreichen Anfragen nicht mehr bedient wird.

Der Preis ist eine hohe Intransparenz aus Sicht der Nutzer*innen, denen nicht einmal angezeigt werden kann, dass sie ihre E-Mailadresse falsch eingetragen haben.

Vorteile für einen Dienstbetreiber

Wie die Überlegungen im vorherigen Abschnitt zeigen ist es also insgesamt durchaus ein komplexes Unterfangen ein ‚magisches‘ Link Login aufzubauen und sicher zu gestalten. Trotzdem kann dies für einen Dienstbetreiber eine Vereinfachung darstellen:

(Fast) Keine Geheimnisse

Da keine Passworte oder andere Geheimnisse wie TOTP Secrets vorhanden sind müssen diese nicht geschützt werden und lassen sich damit auch nicht stehlen. Komplexe Überlegungen wie etwa zum richtigen Passwort Hashverfahren braucht es nicht, ebenso wenig zur Wahl des richtigen Zwei-Faktor-Loginverfahrens.

Auch die entsprechenden Funktionen zur Benutzerkontenverwaltung, sowohl in der internen Administration, wie aber auch für die Nutzer*innen selbst, entfallen weitgehend und sparen Entwicklungsaufwände. Bzw. die teilweise enormen Kosten, die spezialisierte Dienstleister hier berechnen. Und auch ein Loginformular braucht es nicht. Vermutlich reduzieren sich auch Supportaufwände, da es hier nicht viel zu erklären gibt.

Wenn die Abhängigkeit von der Sicherheit der von den Nutzer*innen eingesetzten E-Mailkonten kein Problem darstellt, dann entlastet man sich hier von sehr vielen Aufgaben beim Aufbau und Betrieb des eigenen Dienstes und das faktisch ohne dauerhafte Kosten.

Es gibt eigentlich nur ein Geheimnis, welches geschützt werden muss, und das sind die Sitzungscookies, die durch die magischen Links produziert werden. Im Fall eine Kompromittierung könnte man die aber einfach komplett löschen und die Nutzer*innen würden sich dann – wie sie es schon gewohnt sind – erneut per Mail einloggen.

Weniger Reibung bei der Kontoerstellung

Zumindest bei der Erstanlage eines Kontos ist dieser Weg der reibungsfreiere, denn nach der Eingabe der eigenen E-Mailadresse und dem Anklicken des Links ist man bereits handlungsfähig. Kein Nachdenken über ein neues Passwort hält die Kontenerstellung auf.

Gerade für Services, die mit einer hohen Anzahl von spontanen, vielleicht nur selten wiederkehrenden Nutzer*innen zu tun haben, kann dies ein entscheidender Punkt sein.

Ein Stolperstein können hier nur die generellen Probleme mit E-Mail sein, wie eine Klassifizierung der E-Mails als Spam und damit ein vergebliches Warten der Nutzer*innen auf ihren Link.

Aus Sicht der Nutzer*innen

Schon in früheren Folgen des Security Now Podcasts kam bei Diskussionen um die Wahl eines guten Passworts bzw. der Frage ob man noch ohne Passwortmanager ‚leben‘ kann hin und wieder der Hinweis von Hörer*innen, dass sie bei manchen Diensten nur noch irgendwas in das Passwortfeld eintippen und sich nicht merken, nur um dann im Fall des Falls den Passwortreset zu verwenden. So ein Nutzungsmuster wird durch das Login per Link perfekt unterstützt.

Unpraktisch ist es aber in allen Szenarien, in denen häufige Logins notwendig sind. Das Passwort ist hier ein gewisser Weise ein Login Beschleuniger. Gerade bei Szenarien im Unternehmensumfeld wäre es vermutlich keine gute Idee, wenn man seinen Nutzer*innen jeden Tag so ein Loginverfahren zumuten würde. Gangbar könnte es dann sein, wenn es mit sehr langlebigen Logins verknüpft wird und das Mailkonto gut gesichert ist.

Fazit: Eine relevante Technologie mindestens für Nischen

Ich finde die Idee eines Logins per Link durchaus spannend, es bietet eine Bandbreite von Umsetzungsmöglichkeiten, zum Beispiel bei der Lebensdauer der dadurch erzeugten Loginsitzungen. Eine Variante könnte es auf dem Smartphone sein diese Links per SMS/RCS oder Chatanwendung zuzustellen. Oder direkt aus einer eigenen App und zwar in diesem Szenario:

Nahtloser Übergang von einer nativen App in eine Webanwendung

Ein Unternehmen hat eine native App, in der sich die Nutzer*innen normalerweise eingeloggt bewegen. Nicht alle Funktionen der Unternehmensanwendungen sind allerdings in der App erreichbar, an manchen Stellen werden Links in Webanwendungen angeboten.

Wenn die Webanwendungen über eine Integration in eine Single Sign-on Lösung verfügen, die in der Lage ist Logins per Link zu bedienen, könnte ein aus Sicht der Nutzer*innen nahtloser Übergang von nativer App in die Webanwendungen so aussehen:

1. Nutzer*in verwendet die App und ist darin angemeldet
2. In der App wird ein Link in eine logingeschützte Unternehmensanwendung geöffnet
3. Die App holt sich vor dem Öffnen des Webbrowsers über eine entsprechende API aus dem Loginsystem einen Loginlink bzw. die ‚magischen‘ Bestandteile dieser Links wie das zufällige Token. Die App gestaltet den Aufruf des Webbrowsers mit der Adresse der Zielanwendung dann in dieser Weise:
4. Der Aufruf wird über das Loginsystem gelenkt, welches das mitgegebene ‚magische‘ Token auswerten und damit das Login durchführen kann. Das Loginsystem macht dann die Weiterleitung an die jeweilige Webanwendung
5. Die Webanwendung macht ggf. nochmal eine Schleife über das Loginsystem, per SSO gelingt der Zugriff dann aber ohne erneutes Login

Das komplexe technische Wechselspiel ist dabei vor den Nutzer*innen komplett verborgen und wirkt damit nahtlos. Aus Sicherheitsgründen können die Lebensdauern von so erzeugten Loginsitzungen ggf. stark begrenzt werden, da die App beim nächsten Aufruf wieder ein neues Token generieren kann. In diesem Konzept bleibt vom ‚passwortlosen Login per E-Mail‘ letztlich nur das geheime Token übrig, welches nun zwischen den beteiligten Systemkomponenten ausgetauscht wird, ohne das eine Nutzerinteraktion notwendig ist.

PS.

Die in diesem Artikel verwendeten Bilder wurden mit Midjourney generiert und sollten das Thema des ’steinzeitlichen‘ Mittels E-Mail aufgreifen, welches im Vergleich zu State of the Art Technologien wie Passkeys fast wie Höhlenmalerei wirkt. Aber einfach nicht totzukriegen ist ✊🏻

Beim Aufbau eines zeitgemäßen, webbasierten Loginsystems konzentriert man sich oft zunächst auf den Teil, der bis zum erfolgreichen Login stattfindet: Wie lege ich Passworte sicher ab im System? Wie baue ich eine 2-Faktor-Authentifizierung auf? Wie verhindere ich massenhafte Passwortrateversuche? Kann ich die Resistenz gegen Phishing ausbauen?

In diesem Post geht es aber darum den Teil, der danach passiert, gegen Angriffsszenarien abzusichern und das ist der Teil, in dem sich das Loginsystem dann ‚merkt‘, dass ein erfolgreiches Login durchgeführt wurde und dann nach eigenen Regeln entscheidet, wann es Nutzer*innen erneut nach ihren Logindaten fragt. In Bezug auf das Loginsystem wird im weiteren vom Identity Provider (IdP) gesprochen.

Wie merkt sich ein IdP ein früheres Login

Ein Identity Provider sitzt im Mittelpunkt einer Systemarchitektur, er hat die Aufgabe allen angeschlossenen Systemen die Loginprüfung und Benutzervalidierung abzunehmen und ist damit der singuläre Punkt, in den zur Verbesserung der damit verbundenen Sicherheitsaspekte investiert werden muss. Diese Graphik stammt aus einer Präsentation, die im BIS Kontext einmal gezeigt wurde um diese Struktur zu visualisieren:

Gleichzeitig ist der IdP die Stelle, die ein Single Sign-on umsetzt: Nach dem ersten Login in eine der angeschlossenen Anwendungen kann das Login in die nächste Anwendung ohne für die Nutzer*innen spürbaren, erneuten Loginvorgang erfolgen. Dazu muss der Identity Provider ein Mittel haben um sicher feststellen zu können, dass es bereits so ein erfolgreiches Login gab, zu welcher Nutzerin es gehört und ob es noch gültig und integer ist.

Da es hier um webbasierte Anwendungen geht wird im Weiteren von Cookies gesprochen. Denn für die folgenden Betrachtungen ist es mehr oder weniger unerheblich, ob hier tatsächlich Cookies eingesetzt werden, versteckte Formularfelder oder andere cookie-lose Techniken wie JWTs. Auch ob der Inhalt aus umfangreichen Informationen über die Nutzer*innen und ihre Berechtigungen besteht, oder nur aus einem zufälligen String, spielt keine wesentliche Rolle, denn letztlich geht es immer um ein Informationspaket, welches dem IdP vom Webbrowser präsentiert wird:

Login Cookies als Einfallstor für Angriffe

Da das Login Cookie ausreicht, um die entsprechenden Nutzer*innen gegenüber den IdP zu repräsentieren, ist es ein Weg um den Systemzugriff zu erhalten ohne die eigentlichen Logindaten zu besitzen. Auf diese Weise sind selbst Zugriffe auf Konten möglich, die mit ansonsten komplett diebstahlsicheren Logins etwa über FIDO Keys ausgestattet sind. Der erfolgreiche Angriff auf den Identitätsdienst Okta in diesem Jahr ist hier ein interessantes Beispiel:

Wenn man die beiden Posts, die Okta am 3. November und am 29. November 2023 veröffentlicht hat, nach vollzieht, so konnten die Angreifer Zugriff auf das Kundensupportsystem von Okta erhalten und daraus sogn. HAR-Dateien extrahieren und aus diesen wiederum Login Cookies. Diese HTTP-Archive enthalten alles, was der Webbrowser in Bezug auf eine Webseite kennt, der Warnhinweis auf Googles HAR-Analysetool ist daher entsprechend deutlich:

HAR-Dateien enthalten vertrauliche Daten:

• den Inhalt der Seiten, die Sie während der Aufzeichnung herunterladen
• Ihre Cookies, mit denen jeder, der Zugriff auf die HAR-Datei hat, Ihr Konto mit Ihrer Identität nutzen könnte
• alle während der Aufzeichnung übermittelten Informationen: personenbezogene Daten, Passwörter, Kreditkartennummern usw.

Warnhinweis aus dem HAR-Analysetool von Google

Die Art des Angriffs auf Okta war besonders komplex, aber auch jede Person, die kurz an einem fremden Rechner sitzt, ist prinzipiell in der Lage die Cookies aus einem Webbrowser zu holen, ebenso jede Schadsoftware, die sich im PC oder im Webbrowser eingenistet hat:

Das Risiko wird dabei um so größer, je langlebiger die Cookies sind. Aber wie kann man einen Diebstahl verhindern?

Den Diebstahl kann man nicht verhindern

Generell gibt es für Webanwendungen wie einen Identity Provider heute keine Möglichkeit, die eigenen Geheimnisse perfekt zu schützen. Natürlich muss man dafür sorgen, dass die Cookies nicht einfach für andere Webseiten/-anwendungen auslesbar sind und sie nur verschlüsselt zu übertragen sollte heute eine Selbstverständlichkeit sein.

Genauso wenig darf es möglich sein gültige Cookies ‚aus dem Nichts‘ zu erschaffen, zum Beispiel in dem laufende Nummerierungen vorhergesagt oder die Inhalte bekannt gewordener Cookies modifiziert und zum Beispiel in ihrer Lebensdauer verlängert werden.

Im einfachsten Fall ist das Login Cookie etwas mit diesen Eigenschaften:

• Der Inhalt ist einfach ein langer Zufallsstring
• Die Zuordnung dieses Strings zu den konkreten Nutzer*innen erfolgt im IdP z. B. durch eine Datenbankabfrage
• Auch die Prüfung der Lebensdauer / Gültigkeit erfolgt auf Serverseite auf Basis einer sicheren Informationsquelle wie einer Datenbank mit den bekannten Login Cookies

Dieser Ansatz ist nicht für jede Architektur geeignet, aber er ist einfach ein simples Konstrukt, auf dem sich im weiteren aufbauen lässt. Generell enthält dieses Modell noch nichts, was einen Diebstahl unterbinden oder auch nur erschweren würde, jede Person, die in ihrem Webbrowser dieses Cookie einsetzt wird danach vom IdP als die ursprüngliche Nutzerin akzeptiert und kann in ihrem Namen arbeiten.

Wenn sich ein Diebstahl aber nicht sicher verhindern lässt, dann bleibt nur der Versuch ihn möglichst schnell zu erkennen. Danach können dann Maßnahmen umgesetzt werden, darunter die sofortige Invalidierung des Cookies, potentiell gefolgt von einer Untersuchung, ob es sich wirklich um einen echten Angriff gehandelt hat.

Indicators of compromise

In der IT-Forensic wird ein Artefakt, welches auf eine Kompromittierung hindeutet, als Indicator of compromise (IoC) bezeichnet. So ein Artefakt ist dabei oft nicht für sich allein genommen hilfreich, erst die Betrachtung über mehrere Vorgänge hinweg und dabei beobachtete Veränderungen der verschiedenen Indikatoren können dann Auslöser sein. Aber welche brauchbaren Indikatoren haben wir überhaupt bei Loginvorgängen zur Verfügung:

IP-Adresse

Eine generell vorhandene Information ist die Adresse des Geräts, von dem aus ein Zugriff erfolgt. In der strengsten Auslegung würde ein Login Cookie dann verworfen, wenn es von einer anderen IP-Adresse geliefert wird, als bei der Erstellung verwendet wurde. Das ist aber abgesehen von Fällen, in denen Nutzer*innen immer fixe Adressen haben, keine vernünftige Lösung. Bzw. sie würde im Effekt darauf hinauslaufen, dass ein Single Sign-on faktisch nicht mehr erfolgt und Nutzer*innen sich oft neu anmelden müssen.

IP-Adressbereiche

Interessanter kann eine Prüfung auf Adressbereiche sein: Wenn sich ein Login Cookie nur in den Subnetzen verwenden lässt, in denen es erstellt wurde, ist das Diebstahlspotential deutlich verringert, zumindest wenn man externe Angreifer betrachtet.

Allerdings kann es in einer Universität damit ebenfalls bei weiten Teilen der Nutzerschaft zu einem faktischen Verlust des Single Sign-ons kommen: Nutzungsgruppen wie Studierende wechseln regelmäßig mit ihren Geräten zwischen den Funknetzen der Mobilfunkbetreiber und dem WLAN der Universität und bewegen sich dort in deutlich unterschiedlichen Netzen.

ASN Ebene

Eine noch höhere Ebene sind die AS – die Autonomous Systems – des Internets und die ihnen zugeordneten Nummern, die ASNs. Okta beschreibt in seinem späteren Post dieses Sicherheitsfeature:

Admin Session Binding: As communicated in the Security Incident RCA, customers can now enable an Early Access feature in Okta that requires admins to reauthenticate if their session is reused from an IP address with a different ASN (Autonomous System Number). Okta strongly recommends customers enable this feature to further secure admin sessions.

Quelle: Okta

Da die AS eine so große Struktur im Internet sind, ist dies ein vermutlich ein für viele Anwendungen interessantes Level, welches Zugriffe aus ganz anderen Teilen der Welt aufzeigt, aber nicht so übersensibel ist, wie die vorherigen Ansätze.

Ein Problem ist hier offenbar, dass sich die Zuordnung von IP-Adressen zu ASNs nicht kostenfrei erhalten lässt. Zumindest gibt es Dienstleister wie IP-Info, die mit ASN Datenbanken handeln.

Geolokation

Der Ort, von dem ein Zugriff kam, ist ebenfalls ein interessanter Indikator. Allerdings lässt sich der Zusammenhang zwischen einer IP-Adresse und der physischen Lokation nur ungefähr ermitteln und hier braucht es in jedem Fall einen Dienstleister, wie z. B. die schon zuvor genannte IP-Info, die auch so ein Produkt im Angebot hat.

Auch wenn die Geolokation nicht wirklich sicher zu bestimmen ist kann sie insbesondere dann interessant sein, wenn es darum geht die Nutzer*innen bei fragwürdigen Zugriffen einzubinden: Diese können mit der Information, dass ein Zugriff mit ihren Kontodaten aus irgendeinem IPv6 Netz erfolgt ist, nichts anfangen. Aber die Aussage, dass ein Login auf der anderen Seite der Welt erfolgt ist, könnte sie doch zum Handeln bewegen.

Für die automatisierte Beurteilung, ob ein Zugriff verdächtig erscheint, sind dann aber noch weitere Fragen zu klären. Insbesondere die, ab welcher Distanz ein Zugriff als verdächtig einzustufen ist. Wenn man von Bielefeld ausgeht, wäre dann München Ok, aber London schon nicht mehr? Was ist, wenn ein Nutzer sein Login Cookie in Ägypten angelegt hat, und damit nach Bielefeld zurückkehrt? Und was ist mit Nutzer*innen, die regelmäßig VPN-Dienste verwenden, die sie an wechselnden Punkten der Welt im Internet auftauchen lassen?

Browser Kennzeichen

Auch der Webbrowser, für den ein Cookie ursprünglich ausgestellt wurde, ist ein Merkmal, welches sich nicht vollständig ändern sollte in der normalen Nutzung. Das einfachste Merkmal ist der User Agent String. Mein Chrome Browser gibt sich beim Verfassen dieses Textes so gegenüber Webservern aus:

Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Das Chrome hier etwas von Mozilla, Apple, KHTML und Safari nennt hat mit der langen Entwicklung der Webbrowser zu tun. Abgesehen davon gibt es zwei Schwierigkeiten:

1. Ein Angreifer kann eine Webbrowser Kennung leicht fälschen, gerade im Fall eines Diebstahls von HAR-Dateien wie bei Okta liegen alle dazu notwendigen Daten vor. Selbst wenn diese Informationen nicht vorliegen sollten lassen sie sich erraten, denn es gibt nicht viele Möglichkeiten
2. Die schnelle Weiterentwicklung von Webbrowsern ändert diese Signaturen spätestens alle paar Wochen. Dies kann man allerdings auch als Sicherheitsfeature sehen und als externen Trigger für die Invalidierung eines Login Cookies nehmen

Ein guter Indikator für einen Diebstahl wäre es, wenn ein Cookie mit einem komplett anderen Webbrowsertyp verwendet würde, oder auf einem anderen Betriebssystem. Aber auch, wenn bei dem verwendeten Webbrowser ein Versionsrückschritt stattfinden würde. Für die Verarbeitung der User Agent Strings gibt es Pakete, zum Beispiel ua_parser.

Generell lässt sich ein Webbrowser auch noch anders identifizieren, die Werbeindustrie ist hier nicht müde Merkmale für ein Fingerprinting zu sammeln, welches Nutzer*innen gegen ihren Willen verfolgen kann. Aber solche Mittel sind für diesen Zweck vermutlich nicht wirklich relevant.

Browser Fingerprinting

Nachtrag: Mein Kollege Nico hat die kurze Abhandlung des Themas Fingerprinting hier kritisiert, daher will ich den Absatz noch etwas ausbauen: Es gibt Angebote wie Fingerprint.js, die zahlreiche Faktoren aus einem Webbrowser extrahieren um damit einen eindeutigen Identifikator zu erstellen. Das Versprechen ist es hier Besucher*innen einer Webseite selbst dann tracken zu können, wenn diese in ein Inkognito-Tab wechseln. Allerdings setzen die Schöpfer*innen dieses Pakets die Zuverlässigkeit eher niedrig ein:

Since FingerprintJS processes and generates the fingerprints from within the browser itself, the accuracy is limited (40% – 60%).

Für die hier diskutierten Zwecke ist das zu wenig, im Durchschnitt wäre dann ja ca. jeder zweite Fingerprint nicht verlässlich. Wobei noch unklar ist, in welcher Richtung: Wird beim gleichen Benutzer immer mal wieder ein abweichendes Ergebnis geliefert? Das wäre besonders ungünstig, da es die Rate der Fehlalarme hoch treiben würde. Oder geht es eher in die andere Richtung, werden für viele Nutzer*innen die gleichen Identifikatoren errechnet? Das würde den Effekt entsprechend relativieren.

Allerdings ist es in gemanagten Umgebungen, in denen zahlreiche Nutzer*innen sehr ähnliche bis völlig identische Umgebungen verwenden, vermutlich sowieso schwierig unterschiedliche Identifikatoren zu erzeugen.

Ea gibt von diesem Anbieter auch eine serverseitige Lösung, bei der eine 99,5% Akkuratesse versprochen wird. Die dabei laut Werbetext verwendeten Verfahren gehen dann aber weit in den Bereich eines Verhaltensfingerprintings:

Fingerprint Identification is able to achieve 99.5% accuracy, because it processes the browser attributes on the server and also analyzes vast amounts of auxiliary data (e.g. IP addresses, time of visit patterns, URL changes, etc.).

Insgesamt erscheint mir so ein Ansatz wie eine Mischung aus schwer zu kalkulierender Verlässlichkeit gepaart mit einem potentiell massiven Datenschutzproblem, zumindest wenn man so ein Fingerprinting bei einem externen Dienstleister stattfinden lässt.

Führen eines Verwendungszählers

Mit der Erkenntnis des vorherigen Abschnitts, wonach sich die Versionsnummer des verwendeten Webbrowsers nicht zurückentwickeln kann, lässt sich eine Funktion implementieren, die zumindest bei einem in aktiver Benutzung befindlichen Login Cookie den längerfristigen Missbrauch sicher verhindern kann:

Wenn man den Zufallsstring, der im Cookie steckt, mit einem Verwendungszähler kombiniert, der bei jedem Aufruf größer wird, fällt die Nutzung des Cookies an zwei unterschiedlichen Stellen direkt auf:

Einer der beiden Nutzer wird ein Cookie mit einer Version liefern, die schon abgelaufen ist, und so ein Ereignis wäre ein sehr deutlicher Indikator für eine Kompromittierung. Im Fall des Okta Hacks wären mit so einer Konstruktion möglicherweise alle gestohlenen Cookies wertlos gewesen, da schon die erste Verwendung zu ihrer Invalidierung geführt hätte.

Der IdP müsste dazu das Login Cookie bei jeder Verwendung aktualisieren und in der Datenbank einen Zähler führen, der immer weiter erhöht wird. Varianten bei der Implementierung können dabei darin bestehen, dass man den Zähler bei ‚1‘ beginnen lässt und dann immer um eins erhöht, oder beide Werte mit einer Zufallskomponente belegt, um Vorhersagen zu erschweren.

Generell scheint dieser Ansatz eine hohe Sicherheit zu bieten, sofern sich das Cookie in aktiver Verwendung befindet. Keinen Schutz würde er bieten, wenn die Nutzerin das Cookie selbst gar nicht mehr im Webbrowser hat bzw. den Webbrowser lange nicht nutzt. Was zum nächsten Punkt führt:

Cookies ohne Verwendung schneller invalidieren

Auch in einem System, in dem die Login Cookies generell langlebig sein sollen, macht es Sinn offenbar nicht mehr verwendete Cookie schneller zu löschen, um die Angriffsfläche zu reduzieren. Um solche Cookies zu finden müssen Zeitstempel für die Nutzung der Cookies gehalten werden. Auswertungen darauf können dann offenbar inaktive Cookies in der Datenbank finden und entfernen.

Dieser Inaktivitätszeitraum bis zur Löschung kann dann vielleicht nur eine oder zwei Wochen lang sein. Lang genug, um ein verlängertes Wochenende zu überleben, aber nicht viel länger.

Nutzer*innen die Invalidierung von nicht mehr benötigten Cookies ermöglichen

Auch die Nutzer*innen selbst einzubinden kann ein weiterer Faktor sein, um abhanden gekommene Cookies schadlos zu machen. Hier würde eine Anzeigeseite benötigt, die alle aktiven Cookies auflistet mit weiteren Informationen dazu, damit Nutzer*innen entscheiden können, ob sie noch relevant sind. Die Nutzer*innen brauchen dann eine Möglichkeit nicht mehr notwendige Cookies zu löschen.

Generelles Nutzerverhalten

Schließlich kann auch das Verhalten der einzelnen Nutzer*innen Indikatoren bieten: Ist eine Person normalerweise nie am Wochenende im System unterwegs oder an Feiertagen? Und dann immer zwischen 9 und 17 Uhr? Dann kann der Zugriff außerhalb solcher Zeiten zumindest dazu führen, dass das Login erneut vorgenommen werden muss.

Solche Auswertungen müssen aber, zumindest wenn sie personenscharf gemacht werden und nicht aus generellen Regeln entspringen, in datenschutz- und personalrechtlicher Hinsicht geprüft und abgesichert werden. Hier gerät man ggf. tief in das Spannungsfeld zwischen IT Sicherheit, die möglichst viele Daten sammeln will, und anderen Regelungen, die genau das Gegenteil verlangen.

Fazit

Es gibt also eine ganze Reihe von denkbaren Indikatoren, die man – wenn schon nicht zum Schutz vor Diebstahl – dann wenigstens zur Abmilderung seiner Schadfolgen einführen kann. Meine Favoriten sind dabei diese:

1. Nutzer*innen müssen sehen, welche Cookies für ihren Account aktiv sind, und sie bereinigen können
2. Inaktive Cookies schneller bereinigen als aktive
3. Der Verwendungszähler bei Cookies ist einfach zu implementieren und bietet zugleich einen hohen Schutz
4. User Agent String des Webbrowsers: Hier könnte man zunächst die ganz einfache Implementierung testen, die bei jeder Änderung dieser Kennzeichnung das Cookie invalidiert
5. ASN und Geolokation, da insbesondere die Geolokation weitere Anwendungen hat, z. B. bei der Information von Nutzer*innen über Logins von neuen Geräten

Grundsätzlich braucht es für alle diese Vorgehensweisen eine Datenbank der aktiven Login Cookies, die die entsprechenden Informationen wie den Zeitpunkt der letzten Verwendung, den User Agent String, etc. aufnimmt und damit für vergleichende Auswertungen zugänglich macht.

Umgang mit anschlagenden Indikatoren

Wenn wir nun einen IdP haben, der alle diese Indikatoren hat, eine umfangreiche Datenbank mit dem Verlauf dieser Indikatoren führt und vielleicht sogar automatisierte Auswertungen machen kann, die über einzelne Nutzer*innen hinweg gehen um ein Gesamtbild zu erhalten, wie gehen wir dann damit um, dass einer oder mehrere Indikatoren anschlagen? Hier ist eine große Spannbreite vorstellbar:

• Stilles Löschen des verdächtigen Cookies und Neulogin der Nutzer*innen: Hier würde der IdP das vom Webbrowser kommenden Cookie nicht mehr akzeptieren und aus seiner Datenbank entfernen und aus Sicht der Nutzer*innen einfach ein erneutes Login verlangen. Diese Vorgehensweise erzeugt im IT Betrieb keine weitere Arbeit, würde aber einen erfolgten, zumindest teilweise erfolgreichen Angriff nicht weiter auffallen lassen
• Information an die Nutzer*innen: Hier würde eine Information an die Nutzer*innen beim Loginvorgang stattfinden, die auf ‚ungewöhnliche Aktivitäten‘ in ihrem Konto hinweist und sie auffordert eine Prüfung durchzuführen. Für so eine Prüfung müsste es allerdings eine Grundlage geben wie z. B. die Auswertung der Zugriffsprotokolle samt entsprechender Informationen. Dieses Vorgehen hat aber vermutlich wenig Zweck: Nutzer*innen würden erfahrungsgemäß die Hinweise entweder ignorieren, oder sich aufgeschreckt an den IT Support mit dem Wunsch wenden, diese Prüfungen für sie durchzuführen
• Hintergrundauswertungen mit Information an die Systemadministration: Hier würden aus den Indikatoren generierte Alarme zunächst an die zuständige IT Administration gegeben, die sie bewerten müsste. Wenn der IT Betrieb entsprechend aufgestellt ist könnte dies die Reaktionszeit bei echten Vorfällen deutlich verkürzen und es könnte eine übergreifende Sichtweise eingenommen werden. Auf der anderen Seite dürften die Indikatoren und die ausgelösten Alarme dann nicht so sensibel sein, dass es hier zu häufigen Fehlalarmen und damit zur Ermüdung der zuständigen Personen kommt. Ein SIEM System könnte aber vielleicht ein guter Abnehmer für solche Signale sein und sie dann mit Indikatoren aus anderen Systemen zusammenführen