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:
- Auf der Seite des Dienstes, in den ich mich einloggen möchte, gebe ich die E-Mailadresse ein, die zu meinem Konto gehört
- Der Dienst schickt an diese Adresse einen Link mit etwas ‚magischem‘, dazu im nächsten Absatz mehr
- Ich öffne den Link aus meinem Mailpostfach in meinem Webbrowser
- Der Dienst prüft den Link und erzeugt damit eine aktive Loginsitzung für mich
- 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:
- Nutzer*in verwendet die App und ist darin angemeldet
- In der App wird ein Link in eine logingeschützte Unternehmensanwendung geöffnet
- 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:
- 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
- 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 ✊🏻