Das Muster „E-Mail ist Authentifizierung“

 (rubenerd.com)
4 Punkte von GN⁺ 2024-09-09 | 1 Kommentare | Auf WhatsApp teilen
  • Einige Nutzer verwenden statt des Merkens oder Verwaltens ihres Passworts jedes Mal den Ablauf „Passwort vergessen“ wie eine Anmeldemethode.
  • Der tatsächliche Ablauf besteht darin, auf der Login-Seite einen Wiederherstellungslink per E-Mail zu erhalten, ein temporäres Passwort einzugeben und beim nächsten Besuch denselben Prozess erneut zu durchlaufen.
  • Diese Gewohnheit ist weniger eine bewusste Sicherheitsstrategie als vielmehr ein über die Zeit verfestigtes erlerntes Verhalten.
  • Auch Verbesserungen wie Passwortmanager und Zwei-Stufen- bzw. Multi-Faktor-Authentifizierung können sich für Nutzer eher wie mehr Reibung als wie mehr Sicherheit anfühlen.
  • Systemdesign sollte vom wiederholten Verhalten der Nutzer ausgehen und sie dazu anleiten, sich auf natürliche Weise zu besseren Nutzungsweisen hin zu bewegen.

Passwort-Wiederherstellung als Login

  • Manche Nutzer geben beim Einloggen in Online-Konten kein Passwort ein, sondern wiederholen jedes Mal den Wiederherstellungsablauf.
    • Sie gelangen auf die Login-Seite.
    • Sie klicken auf „I forgot my password“.
    • Sie wechseln zu ihrer E-Mail.
    • Sie klicken auf den Wiederherstellungslink.
    • Sie geben ein temporäres Passwort ein, das sie sich nicht merken werden.
    • Danach wiederholen sie denselben Ablauf erneut.
  • Fragt man sie, warum sie das tun, können sie oft keine Antwort geben oder sagen, dass sie nie darüber nachgedacht haben.
  • Dieses Verhalten ist keine morgens festgelegte Login-Strategie, sondern eher ein über die Zeit verfestigter wiederholter Ablauf.

Reibung, die Sicherheitsverbesserungen für Nutzer erzeugen

  • Diese Methode funktioniert als lösung mit geringem Aufwand, bei der sich Nutzer keine Passphrase merken müssen.
  • Passwortmanager, Identitätsdiebstahl, Zwei-Faktor- und Multi-Faktor-Authentifizierung sowie die Überalterung des Nutzername/Passwort-Modells sind bereits breit diskutierte Themen.
  • Bessere Sicherheitsverfahren erhöhen oft Barrieren und Reibung, sodass Nutzer sie nicht ohne Weiteres natürlich annehmen.
  • Designer sollten das erlernte Verhalten der Nutzer berücksichtigen und Abläufe schaffen, die mit der Zeit zu besseren Nutzungsweisen führen können.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-09
Hacker-News-Kommentare

  • E-Mail-Konten sind der allgemeinste gemeinsame Nenner für Online-Authentifizierung. Mobiltelefone sind ebenfalls konkurrenzfähig, können aber verloren gehen, und Telefonnummern sind noch verbreiteter und langlebiger, haben aber ein deutlich niedrigeres Sicherheitsniveau als Konten bei großen E-Mail-Anbietern.
    Wenn man ein „ausgedachtes Authentifizierungssystem für das Internet“ entwerfen will, sollte man zuerst auf die Kontowiederherstellung schauen. Wenn die Antwort beim Verlust eines schicken Authenticators „Dann kommt man eben nicht mehr rein“ oder „Ein Gremium von Kollegen bürgt für die Identität“ lautet, dann funktioniert das System nicht für Menschen, sondern nur für imaginäre intelligente Lebensformen als Nutzer

    • Das ist seit Jahren mein Hauptgrund, gegen Blockchain/Kryptowährungen zu sein. Das Modell „Schlüssel verloren, Wallet verloren“ passt grundlegend nicht zu realen Nutzern.
      Menschen müssen sich von Fehlern erholen können
    • Staatlich ausgestellte digitale Identitäten könnten viele Teile dieses Problems lösen. Sie hätten ihre eigenen Probleme, aber die persönliche Identifizierung dem Staat zu überlassen wirkt wertvoller und weniger riskant als eine Kontosperrung durch Unternehmen wie Google
    • Leider ist auch bei großen E-Mail-Anbietern wie Google „Dann kommt man eben nicht mehr rein“ ein häufiges Muster. Menschen, die nach Verlust oder Diebstahl ihres Telefons dauerhaft aus ihrem Konto ausgesperrt wurden, zeigen das deutlich
    • Selbst bei „E-Mail-Konten großer Anbieter“ gilt der Zusatz: „Das Konto wurde ohne Grund gesperrt, es gibt keine Möglichkeit zum Einspruch, und man erfährt nicht einmal, warum es gesperrt wurde“
    • Ein Modell, bei dem ein Gremium von Kollegen für die Identität einer Person bürgt, ist ein interessantes Designproblem. Wenn es ein gemeinsames System gäbe, in dem passend verteilte Authentifizierungsgeheimnisse auf Anweisung der beteiligten Parteien wieder zusammengesetzt werden könnten, ließe sich das ziemlich elegant umsetzen.
      Könnte man es so bauen, dass es auch für gewöhnliche Menschen funktioniert? Ich denke, wir haben genug gestalterische Kreativität dafür

  • Unser Dienst ist geschäftlich eher leichtgewichtig, daher nutzen die Anwender ihre Konten nur aus Bequemlichkeit. Wir sind bei folgender Methode gelandet: Der Nutzer gibt seine E-Mail ein, wir senden einen Bestätigungscode per E-Mail, der Nutzer gibt den Code ein, und dann stellen wir ein sehr langlebiges Cookie aus, das praktisch unbegrenzt eingeloggt bleibt.
    Ob bereits ein bestehendes Konto vorhanden ist, spielt keine Rolle; bei einer neuen E-Mail wird einfach ein neues Konto angelegt. Gelegentlich erstellen Nutzer mit mehreren E-Mail-Adressen versehentlich ein neues Konto, aber die Conversion bei Registrierung und Login wurde so viel besser, dass sich der Kompromiss lohnt. Für Gültigkeitsdauer und Anzahl der Versuche beim Code braucht man eine Risikoanalyse, und wenn möglich sollte man einen Sperrmechanismus verwenden. Wenn der Dienst nicht besonders kritisch ist, würde ich diese Strategie empfehlen. iOS Mail unterstützt das inzwischen ähnlich wie die Einmalcode-Funktion in Messages, was es für manche Nutzer ziemlich bequem macht

    • Nach den Daten, die ich gesehen habe, ist diese Methode überwältigend gut darin, den E-Commerce-Umsatz zu maximieren.
      Man sollte Käufer nicht zu einem Konto zwingen, sondern nur nach den Details fragen. Der Browser füllt sie ohnehin automatisch aus. Danach schickt man einen Link zur Bestellverfolgung per E-Mail und fragt bei der nächsten Bestellung einfach erneut nach der E-Mail. Zusätzliche Reibung verursacht mehr Umsatzverlust, als der Vorteil „registrierter Nutzer“ wert ist
    • Ich betreibe eine kleine B2C-App, bei der sich Nutzer nur mit ihrer E-Mail-Adresse registrieren und es überhaupt kein Passwortfeld gibt. Das Konto wird erstellt, und auf diesem Gerät bleibt man dauerhaft eingeloggt.
      Nur wenn man sich auf einem anderen Gerät anmelden muss, kann man ein neues Passwort anfordern. So sinken die Hürden bei der Registrierung und schwache Passwörter. Die meisten müssen sich ohnehin fast nie auf einem anderen Gerät anmelden
    • Ich habe diese Login-Methode mehrfach umgesetzt; sie ist aus der Erfahrung entstanden, dass man unzählige Annahmen darüber entfernen muss, was ein „Nutzerkonto“ eigentlich ist. Tatsächlich braucht es diese Vereinfachung, damit der Funnel so funktioniert, wie beide Seiten es wollen.
      Wenn man nicht in einem Bereich arbeitet, in dem Anonymität gewahrt werden muss, kann man das so machen und später Passkeys integrieren. Der Nachteil ist, dass sich Passwörter dann nicht teilen lassen, weshalb man früher darüber nachdenken muss, wie mehrere Nutzer unter einem Konto verwaltet werden. Wenn man das bewusst angeht, werden Funnel und Nutzererfahrung am Ende aber besser. Außerdem ist die Sicherheit dann an das durchschnittliche Sicherheitsniveau der E-Mail-Anbieter der Nutzer gebunden, was in der Regel besser ist als erforderlich. Passwörter kann man später als zweiten Faktor einsetzen, wenn sie nötig werden, oder weitere Faktoren ergänzen; bei B2B kann man direkt zu SAML oder OIDC gehen. Bei B2B oder D2C hat das immer gut funktioniert, und die Sonderfälle waren wegen der Vorteile bei der Nutzergewinnung die Mühe wert
    • Ich habe diese Login-Art schon gesehen, aber könnte man nicht einfach einen Link per E-Mail schicken, der zur Startseite der App führt und einen dabei bereits eingeloggt hat?
      Das Kopieren des Codes, das Suchen des noch offenen Tabs mit der Login-Seite und das Einfügen sind umständlich
    • Ich habe diese Methode in einer kleinen CRUD-App verwendet, die fast nur aus einem einzelnen Formular besteht, und während der Kampagne gab es fast keine Supportanfragen, daher war es absolut lohnend

  • Wäre es an diesem Punkt nicht besser, per E-Mail einfach einen Einmal-URL-Link zu senden und mit einem Klick anzumelden? Er könnte nach 10 Minuten ablaufen und nach einmaliger Nutzung verworfen werden.
    Natürlich kann dann jede Person mit dem ersten Link auf das Konto zugreifen, aber erreichbar ist er ja ohnehin nur über die E-Mail. Jedes Sicherheitsgefühl oberhalb des E-Mail-Kontos geht dabei verloren, aber realistisch gesehen sind wir ohnehin schon an diesem Punkt. Wenn man bei SMS ein Muster wie „Zum Bestätigen des Logins klicken: www.someurl.com?p=134234535“ verwendet, erhält man Zwei-Faktor-Authentifizierung, ohne stumpf einen Code eintippen zu müssen

    • Ich nutze diese Methode in mehreren Web-Apps, aber für Nutzer ist sie verwirrend („Warum habe ich schon ein Konto? Ich habe mich doch nie registriert!“), sie kostet Geld (E-Mails zu versenden ist nicht kostenlos) und sie ist langsam.
      E-Mails landen im Spam, oder wegen Greylisting kann man sich stundenlang nicht einloggen, oder sie kommen erst nach einer Minute an und selbst das fühlt sich schon zu lang an. Ich bin nicht sicher, ob ich sie empfehlen würde
    • Ich hasse es wirklich, wenn Seiten, die nur diese Methode anbieten, es nicht schaffen, die E-Mail innerhalb von 30 Sekunden zu senden.
      Bei „Zum Bestätigen des Logins klicken“ per Handy sollte man sowohl Code als auch Link anbieten. Das Gerät, auf dem man sich einloggt, ist nicht immer das Handy, daher sollte es „1234 eingeben oder klicken“ heißen
    • Manche Seiten wie Netdata machen das so.
      Aber es ist langsamer, als wenn ein Passwortmanager automatisch Benutzername und Passwort einträgt, weil man auf die E-Mail warten und den Link anklicken muss
    • Ich baue gerade eine Web-App mit genau diesem Login-Ablauf, und auf Mobilgeräten gab es Probleme. Apps wie Gmail erlauben es nicht, einen Link ohne Vorschau in den Browser zu kopieren, und diese Vorschau verbraucht den Link bereits (next.js auth).
      Ich will mich nicht im In-App-Browser von Gmail anmelden, sondern im normalen Browser, und das ist ziemlich lästig
    • Dann kann man auch gleich ganz auf Single Sign-On setzen.
      95 % der Nutzer verwenden ohnehin Gmail, Outlook oder Apple. Ein Button „Mit Google anmelden“ ist besser als „Link per Mail senden“, und Tracking ist in beiden Fällen möglich

  • Die Vorstellung, dass Menschen sich für jeden noch so unbedeutenden Dienst ein Passwort ausdenken und merken, ist nicht realistisch. Noch ein passwortbasiertes Authentifizierungssystem zu bauen, kommt fast einer Art Rollenspiel gleich.
    Passwörter werden meist auf eine von zwei Arten genutzt: entweder mit einem Passwort-Manager, der durch ein einziges echtes Passwort geschützt ist, oder als dasselbe Passwort, das für jeden Dienst wiederverwendet wird. Da fast alle Dienste eine Wiederherstellung per E-Mail anbieten, ist E-Mail in Wirklichkeit das Authentifizierungsmittel. Die persönliche E-Mail-Adresse ändert man selten, teilt sie nicht und verwendet sie auch nicht mehrfach. Wahrscheinlich nutzt man die persönliche E-Mail-Adresse länger als eine Telefonnummer. Während ich meine aktuelle E-Mail-Adresse nutze, hat sich meine Telefonnummer mindestens fünfmal geändert, und diese Nummern werden jetzt von anderen Menschen verwendet

    • Es gibt auch abgeleitete Passwörter, eine Art Mischform. Das kann ein Muster sein, das sich jemand merkt, oder ein Verwaltungstool, das sie pro Domain berechnet
      Und die Funktion „Passwort vergessen“ informiert zumindest den Besitzer der Adresse über jeden Versuch. Passwortbasierte Logins schicken nicht immer eine E-Mail, wenn man sich von einem neuen Ort anmeldet
    • Apple hat den Vorgang „Warum kann ich nicht einfach mein 1Password-/Keychain-Passwort eingeben, sondern muss stattdessen per E-Mail genervt werden?“ deutlich verbessert. Zumindest dann, wenn E-Mails oder SMS erkannt und die Codes automatisch eingetragen werden

  • Die Antwort ist einfach. Meist hat sie mit Reibung zu tun, die der Dienstanbieter für den Nutzer eingebaut hat. In diesem Fall scheint es klar: Sitzungen beim E-Mail-Anbieter enden normalerweise praktisch nie und bleiben angemeldet, solange man nicht den Browser-Cache löscht
    Man sollte die Authentifizierungs-Tokens des eigenen Dienstes genauso langlebig machen wie bei Gmail und als Alternative Login per Einmalpasswort bei jedem Mal erlauben. Aber mit blasphemischen Praktiken wie Authentifizierungs-Tokens, die nur 12 Stunden gelten, muss Schluss sein. Dann würden sich Nutzer nie wieder per Passwort-Wiederherstellung anmelden

    • Der eigentliche Grund könnte sein, dass diese Websites einfach nicht richtig funktionieren
      Früher hatte ich Probleme mit Epic- und Spotify-Konten. Man erstellt ein Konto, nutzt es eine Woche lang, dann läuft die Sitzung ab und Spotify wirft einen raus. Wenn man sich wieder anmelden will, heißt es, das Passwort sei falsch, obwohl es im Passwort-Manager gespeichert ist, also eigentlich unmöglich. Am Ende bleibt nur das Zurücksetzen per E-Mail. Die ersten paar Male kam die E-Mail noch und nach dem Zurücksetzen wiederholte sich dasselbe Muster, und nach dem dritten oder vierten Mal kam nicht einmal mehr eine E-Mail, sodass ich ein neues Konto anlegen musste. Inzwischen melde ich mich bei Spotify mit meinem Google-Konto an und habe bisher keine Probleme. Aber mit einer normalen E-Mail-Adresse funktioniert ihr Authentifizierungssystem einfach nicht
    • Ich denke, das ist ein Hinweis, der näher an der Wahrheit liegt. Viele „Hochsicherheitsorganisationen“ wie Gmail und Cloudflare haben sehr lange Authentifizierungs-Sitzungen. Der Grund ist, dass die Wahrscheinlichkeit, dass jemand Zugriff auf den PC eines Nutzers hat und dieser noch eingeloggt ist, tatsächlich sehr gering ist. Die meisten Hacks zielen aus der Ferne auf schwache Passwörter
      Das Problem ist, dass eine konsistente Sprache fehlt, um Risiken zu bewerten und zu entscheiden: „Braucht diese Website wirklich Zwei-Faktor-Authentifizierung?“ oder „Sind 30 Minuten Sitzungsdauer vernünftig?“ Wenn aktuelle Antivirensoftware vorhanden ist, wollen die meisten wahrscheinlich eingeloggt bleiben. Wurde man jemals gebeten, zur Behebung eines Website-Problems alle Cookies zu löschen? Meine Antwort ist immer nein. Ich habe einmal gehört: „Das Konto gehört dir, und wenn du das Risiko eines Hacks in Kauf nehmen willst, um eingeloggt zu bleiben, dann ist das dein Risiko und nicht das des Dienstbetreibers“, und ich stimme dem zunehmend zu. Wenn jemand mit einem eingeloggten Laptop alle EC2-Instanzen gelöscht hat, dann ist das deine Schuld und nicht die von AWS, weil sie dich nicht früher ausgeloggt haben. AWS könnte das tun, aber warum sollten sie? Es gibt keinen Grund, eine Million Menschen zu nerven, um eine unvorsichtige Person zu schützen
    • Stimmt. Ich bin es leid, dass Plattformen mit Sitzungsbegrenzungen und erzwungener Zwei-Faktor-Authentifizierung bevormundend auftreten. Es reicht, einfach einen Schalter in den Einstellungen anzubieten

  • Ich habe Websites gesehen, die den Schritt „Passwort vergessen“ abgeschafft oder das Passwort selbst ganz entfernt haben. E-Mail ist die Authentifizierung
    Man gibt eine E-Mail-Adresse ein, bekommt eine E-Mail mit einem Code und gibt den Code ein, um sich anzumelden. Ich verstehe, warum man das so macht, aber als jemand, der mehrere E-Mail-Adressen nutzt, mag ich das überhaupt nicht. Ich musste E-Mail-Adressen und Notizen im Passwort-Manager hinterlegen, um mich daran zu erinnern, welche ich verwenden muss, und es bleibt wie ein Eintrag ohne Passwort zurück

    • Die Reibung bei Magic Links war für mich schon so groß, dass ich auf solchen Websites kein Geld ausgegeben und stattdessen nach Alternativen gesucht habe
      Wenn sie nicht einmal ein ordentliches Login-System bauen können, fehlt ihnen wahrscheinlich auch die Kompetenz, die versprochenen Funktionen bereitzustellen. Magic Links sind inzwischen nicht nur lästig, sondern ein Filter geworden
    • Im B2B-SaaS-Bereich wird dieser Ansatz genutzt. Einzelne Nutzer loggen sich vielleicht nur ein- oder zweimal in sechs Monaten ein, daher ist passwortloser Login im Vorteil
      Man muss sich nicht merken, welches Passwort man für einen selten genutzten Dienst hatte, und auch das Onboarding in Unternehmen wird einfacher. Lädt ein Unternehmen eine Nutzer-CSV hoch, können die Nutzer sofort loslegen, ohne erst ein Passwort zu erstellen, zu bestätigen und irgendwelche Regeln zu erfüllen. E-Mail-Links bevorzuge ich nicht. Vorschauen in mobilen Apps oder Unternehmens-Virenscanner „klicken“ diese Links nämlich oft an
    • Ein großer Teil der nichttechnischen Verbraucher wird keinen Passwort-Manager verwenden. Wenn man nur Passwort-Registrierung anbietet und keine Magic Links oder Codes, macht man das Leben für die meisten Verbraucher schwerer
      Selbst wenn man beides anbietet, dürfte mehr Abbruch im Anmeldeprozess entstehen, wenn man ein Passwort verlangt und zusätzlich noch die E-Mail bestätigen lässt. Außerdem ist der Code viel einfacher, wenn man nicht sowohl Passwörter als auch mehrere E-Mail-Login-Flows unterstützen muss
    • Diese Methode wurde bei „Gast-Login“-Websites zum Einlösen von Gutscheinen angeboten, und ich halte das für einen sinnvollen Anwendungsfall für Menschen, die vielleicht kein Konto erstellen wollen
      Da der Gutschein mit einer E-Mail verknüpft werden musste, musste der Besitz per Link-Klick bestätigt werden, falls später Support-Probleme wegen eines verlorenen Gutscheins auftreten. Wenn man danach ein Konto erstellt, kann man auch die zuvor erhaltenen Gutscheine sehen
    • Es bedeutet, dass die Website mein Passwort nicht speichert, also gibt es eine Sorge weniger

  • Erst nach dem Lesen dieses Artikels ist mir klar geworden, dass ich bei Best Buy genau diese Methode verwende
    Nicht absichtlich. Ich weiß, dass das Passwort korrekt ist, weil es in 1Password gespeichert ist, aber immer wenn ich auf bestbuy.com etwas kaufen will, greift irgendein Schutz gegen Kontoübernahme und behauptet fälschlich, das Passwort sei falsch. Ich halte es durchaus für möglich, dass das Problem auf meiner Seite liegt. Es könnte an einem Werbeblocker oder lokalem DNS-Blocking liegen. Aber nach ein paar Versuchen verliere ich die Lust aufs Debugging und nehme einfach den Weg des geringsten Widerstands

    • Ist es vielleicht ein Mismatch bei der maximalen Länge? Es kommt sehr häufig vor, dass das maxlength im Feld zum Ändern des Passworts und auf der Login-Seite unterschiedlich ist
      Zum Beispiel setzt man beim Ändern des Passworts ein 60 Zeichen langes Passwort, aber auf der Login-Seite liegt die maximale Länge bei 40 Zeichen, und dann heißt es beim Anmelden „Passwort falsch“. Deshalb speichere ich inzwischen die maximale Länge in den Anwendungseinstellungen und lasse sie in alle Passwortfelder übernehmen. Beim Nachsehen zeigt sich tatsächlich ein Längen-Mismatch. Im Formular zum Setzen des Passworts ist maxlength 54, auf der Login-Seite gibt es kein maxlength. Wenn das Passwort also länger als 54 Zeichen ist und 1Password das gespeicherte Passwort nicht automatisch auf 54 Zeichen kürzt, kann man sich nicht anmelden

  • Für die meisten Menschen besteht Computerarbeit darin, stumpf so lange etwas zu versuchen, bis es irgendwie klappt. Software wird von Leuten gebaut, die die zugrunde liegenden Systeme im Detail verstehen, ist aber für Menschen gedacht, die dieses Verständnis nicht haben
    Nutzer bleiben bei einem Muster, sobald es einmal funktioniert. Da inzwischen viele Schulen Tablets im Unterricht einsetzen, wird diese Tendenz noch stärker. Man bekommt kaum ein Gefühl dafür, wie Computer eigentlich funktionieren. Die meisten denken nicht tiefer darüber nach. Es ist einfach da, und weil ohnehin alles irgendwie kaputt ist, machen ein paar zusätzliche Klicks auch nichts mehr aus

    • Unter Softwareentwicklern verstehen vermutlich nur etwa 10 % wirklich tief, was sie tun. Gerade weil Entwickler oft nicht richtig verstehen, was sie da machen, müssen normale Menschen miserable Software durch wiederholtes Probieren irgendwie benutzen

  • Überspitzt gesagt ist der Login-Ablauf derselbe
    A) Man geht auf die Website, kopiert über den Passwortmanager eine Zufallszeichenfolge hinein und bekommt zur Identitätsprüfung eine per E-Mail kommende TOTP-Anfrage. Oder B) man geht auf die Website, klickt auf „Passwort vergessen“, bekommt einen Login-Link und gibt danach eine Zufallszeichenfolge ein. In vielen Fällen ist B tatsächlich schneller und fast nie langsamer. Das Kontrollkästchen „Angemeldet bleiben“ bringt nichts

    • Wer kopiert denn in einem Passwortmanager etwas per Copy-and-paste?
      Meiner Meinung nach ist mein Ablauf besser als beides. Ich gehe auf die Website, Safari schlägt Autofill vor, ich nutze TouchID/FaceID und werde nach dem Zwei-Faktor-Code gefragt. Wenn er per SMS oder E-Mail kommt, schlägt Safari Autofill vor. Selbst bei TOTP füllt Safari ihn automatisch ein. Das ist sehr einfach. Passkeys sind noch einfacher, weil der zweite Schritt und das Warten auf SMS/E-Mail entfallen
    • TOTP ist nichts, was per E-Mail verschickt wird. Der Kern von TOTP ist gerade, dass man den Authentifizierungscode anhand der aktuellen Zeit und eines vorher geteilten Geheimnisses selbst erzeugen kann
    • Mit Greylisting kann der Ablauf B gut 10 Minuten dauern
    • Methode B funktioniert überall dort, wo man Zugriff auf seine E-Mail hat, und hängt nicht davon ab, ob man eine App oder sein Telefon zur Hand hat
    • Merkt sich der Browser das Passwort nicht?

  • Die Motivation ist sofort nachvollziehbar. Wenn man „Passwort vergessen“ verwendet, muss man sich kein Passwort merken. Und die Kontosicherheit wird dadurch auch nicht schwächer. Dieser Weg stand Angreifern ohnehin bereits offen
    Manche Websites machen das sogar zum Standardablauf und behaupten damit implizit, dass ein Passwort an sich bedeutungslos ist, wenn man jemandem zum Einloggen eine E-Mail schicken kann. Mir persönlich gefällt das nicht. Ich vertraue E-Mail nicht und möchte auch nicht, dass sie zum Single Point of Failure für Dutzende Konten wird. Wenn man sich allein mit dem zweiten Faktor anmelden kann, ist das keine Zwei-Faktor-Authentifizierung. Ich würde gern per Passwort einloggen können, ohne Reset-Option, aber die Realität ist anders

    • Wenn man E-Mail mit Zwei-Faktor-Authentifizierung schützt, ist es wieder Zwei-Faktor-Authentifizierung