- Magic Links, die einen Login-Link per E-Mail senden, können das Risiko von Passwort-Phishing und Lecks durch wiederverwendete Passwörter verringern. Wenn sie jedoch die einzige Option sind, wird die Reibung beim Login auf die Nutzer abgewälzt.
- Bei Nutzern mit mehreren Computern oder einer Trennung zwischen Arbeits- und Privatgeräten unterscheiden sich häufig das Gerät, das die E-Mail empfängt, und der Browser, in dem sie sich anmelden wollen, sodass der Ablauf leicht unterbrochen wird.
- Durch SMTP-Verzögerungen und den Prozess der Link-Weitergabe kann sich der Login von 2 Sekunden bis zu mehreren Minuten verzögern, und in In-App-Browsern sowie RSS-Reader-Apps kann auch die mobile Nutzbarkeit beeinträchtigt werden.
- Das direkte Eingeben eines per E-Mail oder SMS erhaltenen OTP ist ebenfalls umständlich, kann aber praktischer sein als ein Magic Link, wenn sich der Link nur schwer zwischen E-Mail-Client und Browser übertragen lässt.
- Selbst wenn Magic Links als Standard verwendet werden, sollten für technisch versierte und datenschutzbewusste Nutzer robuste Alternativen wie Passkeys mit angeboten werden.
Situationen, in denen Magic Links unbequem werden
- „Magic Links“ bezeichnete früher futuristische PDAs, heute meint der Begriff jedoch Login-Links in E-Mails, wie sie von Unternehmen wie Auth0 verwendet werden.
- 404 Media verteidigt Magic Links in „We Don’t Want Your Password“ und argumentiert, dass E-Mail-Links schwerer zu phishen seien als Passwörter, nicht direkt zu Passwortlecks führten und auch das Risiko der Wiederverwendung geleakter Passwörter reduzierten.
- Im Alltag mit nur einem Laptop und einem Mobilgerät wirkt das einfach, doch für Nutzer mit mehreren Geräten und Browsern wird die Komplexität unverändert weitergereicht.
- Beispiele für Unannehmlichkeiten:
- Mehrere Geräte: Nutzer, die auf ihrem Gaming-PC oder Arbeitslaptop keine private E-Mail eingerichtet haben, können den Login-Link nicht direkt öffnen.
- Geschwindigkeit: Durch SMTP-Verzögerungen und das Verschieben des Links in den richtigen Browser kann der Login von 2 Sekunden bis zu mehreren Minuten dauern.
- Mobil: Die Nutzung von In-App-Browsern wird erschwert, wodurch der Umgang mit lokalen Links in RSS-Reader-Apps unkomfortabel wird.
- Sicherheit: Ein Ablauf, der dazu verleitet, private E-Mails auf Arbeitsgeräten oder umgekehrt zu öffnen, ist kein Sicherheitsvorteil.
Alternativen und minimale Verbesserungen
- Ein passwortloses Verfahren mit direkter Eingabe eines per E-Mail oder SMS erhaltenen OTP ist ebenfalls unbequem, kann aber in Situationen praktischer sein, in denen sich ein Link nicht einfach vom E-Mail-Client in den Browser übertragen lässt, in dem der Login erfolgen soll.
- Stratechery bietet über Passport entweder das Klicken auf einen Link oder die Eingabe eines OTP an. Auch wenn dabei die Unannehmlichkeiten ohne Passkey-Implementierung weiterhin den Nutzern überlassen bleiben, berücksichtigt dies die jeweiligen Nutzungssituationen besser als ein reiner Magic-Link-Ansatz.
- Selbst wenn man auf Magic-/Tragic-Links als Standard besteht, ist es besser, robuste Alternativen wie Passkeys gemeinsam anzubieten.
- Ricky Mondellos Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over ist ein hilfreicher Referenzartikel dazu, wie sich dieses Problem mit Passkeys abmildern lässt.
1 Kommentare
Meinungen auf Hacker News
Probleme, die beim Bau einer App mit Magic Links auftraten: Da Nutzer sich möglicherweise auf Geräten anmelden müssen, auf denen der Zugriff auf E-Mail umständlich ist, sollte der Magic Link einen alternativen Login-Code enthalten.
Außerdem muss man Fälle behandeln, in denen E-Mail-Clients Links automatisch öffnen, um Vorschau-Screenshots zu erstellen, und auch E-Mail-Clients berücksichtigen, die Links statt im vom Nutzer bevorzugten Browser in einem In-App-Browser öffnen.
Zum Beispiel kann es iOS-Nutzern passieren, dass sie zwar Firefox Mobile bevorzugen, die E-Mail-App den Link aber erzwungen in einem Safari-basierten In-App-Browser öffnet.
Ich denke, ein Ansatz, der auf eine Seite zur Eingabe eines Einmalcodes führt, kann viele dieser Probleme vermeiden.
Kürzlich gab es das Problem, dass ein neues E-Mail-Konto automatisch verifiziert wurde und der Magic Link bereits ungültig war, als der Nutzer darauf klickte – weil Microsoft während der Prüfung zuerst über diesen Link eingeloggt war.
Nachdem McDonald's von E-Mail/Passwort auf Magic Links umgestellt hatte, war es wirklich schwierig, den Link in der McD-App zum Laufen zu bringen; meistens öffnete sich nur die McD-Website.
Wenn ich McD esse, bestelle ich zu etwa 98 % per App – wenn das nicht geht, esse ich dort eher nicht –, daher war das ziemlich nervig, und am Ende bin ich auf „Sign in With Apple“ (SIWA) umgestiegen.
Da ich keine Möglichkeit fand, SIWA zu meinem bestehenden McD-Konto hinzuzufügen, musste ich SIWA so nutzen, dass meine echte E-Mail-Adresse vor McD verborgen bleibt; dadurch wurde ein neues Konto erstellt und ich verlor die Reward-Punkte des alten Kontos, konnte aber wenigstens die McD-App wieder nutzen.
In der App gibt es jeden Freitag einen Deal „Free Medium Fries on Friday“ bei Bestellungen ab 1 Dollar. Deshalb mache ich mir freitags zum Mittag oft zu Hause ein Sandwich und hole mir bei McD einen Cookie und die kostenlosen Pommes dazu.
Also habe ich auf dem Firmenrechner den Magic Link empfangen und daraus einen QR-Code erstellt, aber das E-Mail-Quarantänesystem hatte den gesamten Link umgeschrieben, sodass ich erst den Original-Link extrahieren musste.
Damit war es nicht getan: Die Redirect-URL zurück zu Slack war wegen URL-Encoding kaputt, also musste ich sie manuell reparieren und dann den QR-Code erstellen.
Es würde reichen, in die ursprüngliche Magic-Link-E-Mail einfach einen QR-Code oder einen Code mit aufzunehmen.
Sobald man einen Code eingibt, verschwindet dieser Vorteil vollständig: Ein Angreifer muss nur eine gefälschte Website bauen, die nach dem Code fragt.
Bei Magic Links sollte man auf dem Gerät eingeloggt werden, auf dem man klickt, nicht auf dem Gerät, das die Login-Session angefordert hat.
Alles andere ist vielleicht etwas weniger lästig, aber es ist ein Sicherheitsproblem und sollte auch so behandelt werden.
Ich nutze seit Jahren Magic Links; in der MVP-Phase war ein Grund auch, die Sicherheitslast zu vermeiden, Nutzerpasswörter zu speichern. Das größte Problem ist, dass ein kleiner Teil der Nutzer, etwa 0,1 %, überhaupt keine E-Mails empfängt.
Wir haben eigene IPs, MailGun, PostMark und sogar sequenzielle Retry-Ansätze über mehrere Transactional-Mail-Tools ausprobiert, aber es gibt immer noch Menschen, die sich absolut nicht einloggen können.
Außerdem klicken Leute auf einen Magic Link von vor sechs Monaten und sind frustriert, weil „es nicht funktioniert“. Daher zeigen wir statt einer Fehlermeldung nun eine Seite wie bei Docusign, die die Situation erklärt und den Link erneut versendet.
Menschen tippen auch häufig ihre E-Mail-Adresse falsch ein und geben dann dem System die Schuld, wenn sie keinen Code erhalten.
Trotzdem habe ich das Gefühl, dass es deutlich weniger Support-Tickets gibt als bei E-Mail+Passwort, deshalb bevorzuge ich weiterhin Magic Links.
Magic Links habe ich noch nie genutzt, aber als wir vor ein paar Monaten Google Sign in zu unserem SaaS hinzugefügt haben, machte das über 90 % der neuen Registrierungen aus.
Und das, obwohl unsere Nutzerbasis aus Entwicklern besteht, also eher technikaffin und datenschutzsensibel ist; ich glaube nicht mehr, dass andere Methoden Priorität haben. Natürlich behalten wir E-Mail/Passwort weiterhin bei.
Benutzername+Passwort mit Passwortmanager oder Passkeys sind über HTTPS vermutlich eine der wenigen Möglichkeiten, Credentials Ende-zu-Ende-verschlüsselt auszutauschen und gleichzeitig der breiten Masse eine gute User Experience zu bieten.
Passwortmanager stellen sicher, dass Credentials nur auf der richtigen Domain verwendet werden.
Ich war ein treuer Kunde von Mercury, aber selbst nachdem ich ein sicheres Passwort, einen Passwortmanager und ein gültiges TOTP durchlaufen hatte, wurde bei jeder Änderung der IP-Adresse ein Magic Link als dritter Authentifizierungsfaktor erzwungen. Das brachte mich so weit, darüber nachzudenken, das Firmenkonto zu einer anderen Bank umzuziehen.
Ich könnte es verstehen, wenn ich mich von einem Ort oder ISP aus einlogge, den ich in den letzten fünf Jahren nicht genutzt habe. Aber wenn sich gegenüber dem Login von gestern nur das letzte Oktett der DHCP-Adresse geändert hat, ergibt das keinen Sinn.
Da ich E-Mails über SSH auf einem anderen Rechner als dem fürs Web-Browsing lese, ist es wirklich mühsam, einen Login-Link mit mehreren Hundert Zeichen zu kopieren und einzufügen.
In Emacs wird er über mehrere Zeilen angezeigt, sodass ich auch die
\an den Zeilengrenzen manuell entfernen muss.Wenn man bei jedem Login Reibung hinzufügt, färbt das auf den Eindruck aller anschließenden Interaktionen in der App ab und man möchte sie nicht mehr benutzen.
Wenn es sich um ein bereits verwendetes Gerät handelt, sollte keine Gerätebestätigung angefordert werden. Dafür speichern wir ein dauerhaftes Cookie, und bei derselben IP fordern wir sie ebenfalls nicht an. Ich frage mich, ob bei dir vielleicht Cookies regelmäßig gelöscht werden.
Diese Funktion haben wir eingeführt, nachdem Angreifer Kopien von http://mercury.com erstellt und sogar Google Ads dafür geschaltet hatten.
Wenn Kunden auf einer Phishing-Seite ihr Passwort und TOTP eingaben, loggte sich der Phisher mit diesen Zugangsdaten ein, erstellte virtuelle Karten und kaufte Kryptowährungen, Gold usw.; anschließend wurde der Nutzer zum echten Mercury weitergeleitet, in der Hoffnung, dass er es für einen vorübergehenden Fehler hält.
Der von uns gesendete Gerätebestätigungslink autorisiert die IP/das Gerät, auf dem der Link geöffnet wird, und mit diesem Ansatz konnten wir Phisher nahezu vollständig blockieren.
WebAuthn ist gegen solche Phishing-Angriffe immun; wenn man WebAuthn nutzt, verlangen wir daher keine Gerätebestätigung.
Wenn möglich, empfehle ich dringend TouchID/FaceID oder gerätespezifisches WebAuthn. Es ist bequemer und sicherer und kann hier hinzugefügt werden: https://app.mercury.com/settings/security
Allerdings diskutieren wir diesen Beitrag intern, und uns ist auch bewusst, dass sich IPs mit zunehmender Verbreitung von IPv6 deutlich häufiger ändern werden. Wir werden überlegen, ob wir die Einschränkung auf Übereinstimmung derselben IP lockern sollten.
Ich halte das für eine sehr gute Reaktion auf den 404-Beitrag von letzter Woche. Ich mag 404, aber aus denselben Gründen, die der Autor nennt, sind Magic Links nervig.
Der Beitrag[1], den Ricky Mondello letzte Woche geschrieben hat, erklärt gut, dass Passkeys zusammen mit Magic Links verwendet werden können, wie es am Ende des Artikels angedeutet wird; er ist lesenswert.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Wenn man sich im Store einloggen wollte, sollte man den per E-Mail gesendeten 2FA-Code eingeben; mehrere Minuten lang kam keine Mail, auch beim Anfordern eines neuen Codes kam nichts, und wenn man aufgab und etwas anderes machte, trafen 30 Minuten später beide Codes ein.
E-Mail ist im Grunde selbst unter besten Bedingungen schwer verlässlich zu machen. Sie kann im Spam-Ordner landen, der Spamfilter der Firma kann Links blockieren, oder das Postfach kann voll sein.
Bei mir persönlich ist E-Mail nur auf dem iPhone; auf dem Firmenlaptop oder dem Gaming-PC muss ich mich erst bei icloud.com anmelden, um sie zu sehen, was umständlich ist.
Ich wünschte, man ließe mich ein Passwort eingeben, einen QR-Code scannen wie bei Embedded-Geräten, oder böte zumindest irgendeine andere Option an.
Magic Links ermöglichen den Zugriff auf Passkeys, und Passkeys sind im Grunde eine verstärkte Version von „Diesen Computer merken“.
Ich bin immer noch an die Zeit gewöhnt, in der Leute von Apple öffentlich kaum in Erscheinung traten.
Vielleicht habe ich etwas missverstanden, aber Passkeys scheinen mir tatsächlich keine Alternative zu Magic Links zu sein.
Bei allen Passkey-Implementierungen, die ich bisher gesehen habe, wurde vorgeschlagen, einen Passkey zu erstellen, nachdem man bereits auf anderem Weg eingeloggt war.
Ich habe mich nicht extrem tief damit beschäftigt, aber aus Sicht der User Experience wirken Passkeys eher wie eine Alternative zum Button „Diesen Computer merken“ als wie eine Alternative zu Passwörtern insgesamt.
Auf irgendeine Weise muss der Dienst wissen, dass dieses neue Gerät autorisiert wurde.
Je nach Anbieter gibt es zwar Passkey-Synchronisierung, aber das löst nicht die Frage, wie die erste Authentifizierung erfolgt.
Die zentrale Erkenntnis von Magic Links ist, dass ein Sicherheitssystem nicht stärker sein kann als sein Wiederherstellungsmechanismus.
Eine Welt, in der Passkeys als einziges Authentifizierungsmittel behandelt werden, wird es nicht geben; es wird immer Wiederherstellungsmechanismen geben, und meistens wird das automatische Wiederherstellung per E-Mail sein.
Insofern sind Magic Links ehrlich, weil sie vereinfachen, ohne so zu tun, als gäbe es darüber noch eine sicherere Schicht.
Wenn man den Wiederherstellungsmechanismus zum primären Interaktionsmittel des Authentifizierungsflusses macht, ist man ehrlicher in Bezug auf das tatsächliche Sicherheitsniveau des Authentifizierungssystems.
Edit: filmgirlcw hat einen Link zu einem besseren Beitrag hinterlassen, der erklärt, wie sich die beiden Ansätze in der Praxis ergänzen: https://news.ycombinator.com/item?id=42628226
Magic Links haben zwar Vorteile, aber ich weiß nicht, ob es ein Vorteil ist, E-Mail zu einem stärkeren Angriffsvektor zu machen.
Für Menschen, die Passwortmanager nutzen, sind Magic Links eindeutig ein Reibungspunkt, und Passkeys können diesen deutlich verringern.
Auch bei der User Experience von Passkeys gibt es noch Raum für Verbesserungen, und sobald Export möglich ist, wird die Synchronisierung zwischen Systemen deutlich besser werden.
Einer der Gründe, warum ich 1Password als Standard-System für Passwörter und Passkeys nutze, ist die Passkey-Nutzung über Geräte hinweg; auch mein Unternehmen verwendet 1Password, sodass ich in privaten und geschäftlichen Konten angemeldet bin und mich bei Bedarf von privaten oder Arbeitsgeräten aus authentifizieren kann.
Wenn das von 404 definierte Problem allerdings ist, dass man keine Verantwortung für die Speicherung von Passwörtern oder Authentifizierungsdaten übernehmen möchte, dann halte ich Passkeys für manche Nutzer für besser als Magic Links.
Trotzdem denke ich wie Ricky, dass es nicht entweder das eine oder das andere sein sollte, sondern beides.
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Nur weil man Passkeys verwendet, heißt das nicht zwingend, dass es eine alternative Login-Methode geben muss, aber bisher ist noch kein Dienst vollständig auf ausschließlich Passkeys umgestiegen.
Nutzer älterer Betriebssysteme oder von Linux können Passkeys möglicherweise noch nicht erstellen und speichern, und viele Nutzer verwenden keinen plattformübergreifenden Credential Manager.
Wenn man zum Beispiel mit iCloud Passwords einen Passkey erstellt hat, gibt es derzeit keine Möglichkeit, sich unter Linux einzuloggen.
In ein paar weiteren Jahren werden wir meiner Meinung nach anfangen, Abläufe zu sehen, bei denen Dienste von Anfang an einen Passkey erstellen lassen und gar kein Passwort mehr erfassen.
Ich hoffe, dass die Spezifikation für Passkey-Portabilität implementiert wird und auch Gnome/KDE Passkey-Unterstützung umsetzen.
Wenn es schon mühsam ist, beim Besuch einer Website auf dem Arbeits-PC ein OTP vom Handy zu verwenden oder einen Link vom Handy zu kopieren, frage ich mich, wie viel einfacher und besser es sein soll, den Arbeitsrechner mit einem persönlichen Passkey von irgendwo wie einem Laptop zu koppeln.
Dienste, die zur Authentifizierung nur Magic Links unterstützen, nutze ich nicht. Das ist sehr nutzerfeindlich und aus Sicherheitssicht eindeutig schlechter als Passwörter zusammen mit einem Passwortmanager.
Das Schlimmste ist, dass es in meiner persönlichen Konfiguration überhaupt nicht funktioniert.
Denn aus Gründen der Sicherheit und Kontosicherheit greife ich auf Geräten, die ich zum Login nutze, nicht auf mein E-Mail-Konto zu.
Nur bei Anthropic mache ich eine Ausnahme, weil Claude das beste LLM ist, aber jedes Mal, wenn ich mich erneut anmelden muss, ist es extrem schmerzhaft, und ich habe mich schon mehrfach beschwert.
Immer wenn ich Magic Links sehe, denke ich: „Sollte man nicht von vornherein keine Links in E-Mails anklicken?“
Wenn ich an E-Mail-Links denke, denke ich automatisch auch an Phishing.
Ich hasse Magic Links wirklich.
Der Punkt ist, dass man keine verdächtigen Links anklicken soll. Wenn man weiß, dass ein Magic Link gesendet wurde, ist der Link nicht verdächtig.
Trotzdem mag ich Magic Links wegen der Verzögerung nicht.
Apples Ansatz zum E-Mail-Datenschutz klingt interessant. Apple lädt dabei immer alle Bilder; ich weiß nicht, ob es Nachteile gibt.
Die beste Implementierung, die ich gesehen habe: Man muss den Link auf dem Gerät anklicken, auf dem man die E-Mail erhalten hat, die Sitzung wird aber nicht auf dieses Gerät übertragen; stattdessen schließt man den Login auf dem Gerät ab, auf dem man den Login-Vorgang ursprünglich gestartet hat.
Die bessere Lösung ist, den Login nur auf dem Gerät zuzulassen, auf dem der Link geöffnet wurde, und für die Nutzung über Geräte hinweg zusätzlich einen OTP-Code bereitzustellen, den man auf dem empfangenden Gerät lesen und leicht auf dem ursprünglichen Gerät eingeben kann.
Oder man stellt ganz ohne Link nur einen OTP-Code bereit.
Es gibt nichts Schlimmeres, als wenn man in einem Browser arbeitet und beim Öffnen der E-Mail dann im Standardbrowser authentifiziert wird — oder, noch schlimmer, auf einem anderen Gerät, sodass man den Link dorthin weiterleiten und erneut öffnen muss.
Es ist auch kein völlig abwegiges Szenario, dass man auf einem bestimmten Gerät keinen Zugriff auf bestimmte E-Mails haben möchte.
Wenn eine Site ein OTP wie
crazy-pink-horse-3837schickt, das man kopieren und einfügen kann, ist das ein brauchbarer Mittelweg, falls eine Link-Implementierung zur Authentifizierung der ursprünglichen Anfrage zu schwierig ist.Das Problem bei der Implementierung war aber, dass der verschickte Magic Link in einen Click-Tracker verpackt war und dessen Domain von Tools wie Pi-hole blockiert wurde.
Dadurch konnte man die eigentliche Authentifizierungs-URL nicht erreichen und den Login-Vorgang nicht abschließen.
In-App-Browser sollten verschwinden. Besonders solche, bei denen man nicht „Im normalen Browser öffnen“ wählen kann; und ein RSS-Reader sollte diese Option selbstverständlich anbieten.
Alle Produktmanager, die Nutzern In-App-Browser aufzwingen, sollten ins Gefängnis.
Eine deutlich bessere Option sind Passkeys mit einem per E-Mail verschickten OTP-Code und Conditional Mediation UI.
Wenn sich der Nutzer auf einem Gerät anmeldet, auf dem bereits ein Passkey vorhanden ist, kann die CM UI ihn direkt auswählen lassen und sofort einloggen.
Auf einem Gerät ohne Passkey kann man eine User Experience gestalten, bei der der Nutzer den E-Mail-Code eingibt und nach Erfolg sofort einen Passkey einrichtet, sodass er sich beim nächsten Mal direkt anmelden kann.
So erhält man auf bestehenden Geräten die Sicherheit von Passkeys und auf neuen Geräten eine passwortlose Einrichtung samt Kontowiederherstellung.
Als Bonus vermeidet man auch den Vendor-Lock-in, bei dem ein Cloud-Anbieter alle Passkeys besitzt.