Eine der grundlegenden Funktionen jeder Webanwendung mit Login ist die Möglichkeit, dem Nutzer bei der Anmeldung wieder auf die Sprünge zu helfen, wenn er sein Passwort vergessen haben sollte (und wenn der Login nicht über OpenID o.ä. erfolgt). Dafür gibt es verschiedene Strategien, von denen manche mehr, manche weniger benutzerfreundlich oder sicher sind.
Strategie 1: Vergessenes Passwort per E-Mail zusenden
Eine der häufigsten Varianten, dabei aber eine, die ich sofort ausschließen würde. Denn: um dem User das Passwort zusenden zu können, muss man es im Klartext gespeichert haben. Dafür gibt es aber außer diesem Punkt absolut keinen weiteren Grund, niemand benötigt Klartext-Passwörter. Eher im Gegenteil, sie stellen ein erhebliches Sicherheitsrisiko dar. Beispiele für geknackte Websites/Datenbanken mit tausenden geklauter Datensätze inkl. Passwort gibt es viele, und was passiert, wenn man, wie üblich, bei vielen Websites das gleiche oder nur leicht variierte Kennwort benutzt, und dieses jemandem in die Finger fällt, kann man sich selbst ausrechnen.
Strategie 2: Neues Passwort auf Anforderung generieren und per E-Mail zusenden
Sicher eine für den Benutzer bequeme und relativ sichere Variante. Problem: Das Passwort wird per Mail im Klartext durchs Netz geschickt und liegt dann auch im Posteingang, worauf schlimmstenfalls Dritte (später) zugreifen können. Man kann es allerdings natürlich nach dem Versand gehasht und somit sicher abspeichern. Problem Nummer zwei könnte eine Aktion eines Scherzkeks sein, der die eigenen Login-Daten verwendet und das System dazu bringt, ein neues Kennwort einzugeben, was für mich als Nutzer dann sehr nervig ist, da ich dieses Kennwort wieder ändern muss.
Strategie 3: "Aktivierungs-Key" erzeugen und per Mail zusenden
Diese Version nutze ich bisher in fast allen meinen Anwendungen. Auf Anforderung wird im Benutzerprofil ein "Aktivierungs-Key" hinterlegt, meist eine Guid, und diese dem Benutzer per E-Mail zugesendet. Dort kann er dann auf einen Link klicken bzw. den Key kopieren und gelangt anschließend auf eine Seite, in der er sich selbst ein neues Passwort vergeben und sich damit anschließend wieder einloggen kann.
Vorteile: das Passwort wird niemals unverschlüsselt und im Klartext durchs Netz geschickt, idealerweise ist die Zielseite zum Erzeugen des Kennworts SSL-gesichert. Außerdem hat der Account-Inhaber bei "Scherzanfragen" nichts weiter zu tun, als die Mail zu ignorieren oder zu löschen, denn sein Kennwort ändert sich ja erst durch sein aktives Handeln.
(Zwischen-) Fazit
Aus Perspektive der besten Sicherheit ist sicherlich die dritte Variante zu bevorzugen. Bequemer, sowohl für Nutzer als auch Entwickler (weil weniger zeitaufwendig), ist sicherlich die zweite Variante. Die Frage ist, ob man die Bequemlichkeit hier nicht ignorieren und den Aufwand in Kauf nehmen sollte, da es schließlich um die Sicherheit geht.
Was meint ihr?
