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?
-
Björn schrieb am Montag, 1. Februar 2010 15:32:00 Uhr:
Ich finde die 3. Möglichkeit am besten. Oder eine Mischung aus 2 und 3. Der Benutzer klickt auf einen Aktivierungslink und bekommt ein neues Passwort zu gesendet.
Gruß
Björn
-
Robert Mühsig schrieb am Montag, 1. Februar 2010 15:38:00 Uhr:
Man könnte bei Variante 2 ein Passwort/Hash/Irgendwas generieren welches man auf einer speziellen "Passwort-Vergessen" Seite eingeben muss. Wenn das richtige Passwort eingegeben wurde muss der Benutzer zwingend ein neues Passwort eingeben.
Solange auf der "Passwort-Vergessen" Seite die Kombination aus Loginname und Hash nicht stimmt, ändert sich das alte Passwort auch nicht.
Im Prinzip wäre es dann ja ähnlich deiner 3. Strategie, oder täusch ich mich?
-
schrieb am Montag, 1. Februar 2010 15:41:00 Uhr:
Nee, das entspricht ziemlich genau der 3. Strategie.
1. Anfrage - Hash/Guid wird im Profil gespeichert
2. Mail-Versand
3. User klickt Link bzw. Ruft seite auf
4. Eingabe des Hashs/Guid
5. -> Zuordnung zum Profil über diese ID möglich
6. Eingabe eines neuen Kennworts
7. Fertig
-
Sven Sönnichsen schrieb am Montag, 1. Februar 2010 16:36:00 Uhr:
Passwörter sollten nie im Klartext über das Netz gehen bzw. gespeichert werden. Daher ist Variante 3 zu bevorzugen. Gibt es nicht sogar die Möglichkeit, dass man die IP Adresse einschränken kann? Das z.B. also die Eingabe des neue Passwortes nur über dieselbe IP Adresse erfolgen kann, mit der auch die Aktivierungsmail erstellt wurde?
Weiterhin könnte man die Zeitdauer, die der Aktivierungskey gültig ist, einschränken.
Gruß, Sven
-
schrieb am Montag, 1. Februar 2010 17:44:00 Uhr:
Das Einschränken der IP geht natürlich prinzipiell. Aber zum einen kann das für den Benutzer zum Problem werden, wenn er bsp. das Passwort im Büro anfordert und dann nach Hause fährt (zumal er den Zusammenhang auch nicht verstünde, den ich so auch nicht offen legen würde). Zum anderen bringt es keinen Schutz, denn wenn ich mir Zugriff auf dein Webmailkonto verschafft habe und das Passwort zurücksetzen möchte, greife ich im Zweifelsfall auch über die gleiche IP auf Webmail und Webapp zu, d.h. die Wirkung verpufft.
Würde ich also nicht machen.
Eine Einschränkung der Zeitdauer kann man machen, aber um nicht das gleiche Problem wie oben geschrieben zu bekommen, müsste man den Zeitraum schon relativ weit fassen, und dann lässt die Wirkung natürlich auch nach.
Letztendlich bleibt der Schutz auf jeden Fall nur so stark, wie er es beim Mail-Anbieter auch ist, denn das ist der Schlüssel zum Zugriff auf Alles.
-
Istvan Palfy schrieb am Montag, 1. Februar 2010 17:48:00 Uhr:
Sowieso die Dritte Variante, ist ja auch nicht sooo schwierig. Das löst sogar das Problem von Benutzern die zusätzlich zum Kennwort auch noch ihren Benutzernamen nicht mehr wissen - Sowas kann passieren, wenn der Benutzername nicht zwingend eine E-Mail-Adresse sein muß.
"Zweite Variante" ist ok, wenn 1. das generierte Kennwort "freundlich" ist. z.B. "Friede-Freude-Eierkuchen" (natürlich per Zufall gemischt), 2. sofort ein neues Kennwort eingegeben werden muss und das Alte sofort danach verfällt und 3. das generierte Kennwort nur ein paar Stunden gilt.
-
Sven Sönnichsen schrieb am Montag, 1. Februar 2010 18:05:00 Uhr:
Das mit der Aktivierungsmail ohen zeitlich Einschränkung kann aber auch nach hinten los gehen, wenn ein Mailkonto geknackt wird und da noch Mails von vor einem Jahr drin liegen - viele löschen Mails nicht mehr im Zeitalter der Gigabyte Mailkonten. Dann ist es schon ärgerlich, dass man die Aktivierungsmail nicht zeitlich eingeschränkt hat.
-
schrieb am Montag, 1. Februar 2010 18:07:00 Uhr:
Wobei da noch die Voraussetzung für den Missbrauch dazu kommt, dass man sich eben kein neues Passwort erstellt hat und einem das alte wieder eingefallen ist. Denn nach erfolgreichem "resetten" setze ich den Key wieder zurück.
Aber du hast Recht, man kann ihn wenigstens nach einer Woche o.ä. grundsätzlich auslaufen lassen. Womit die ganze Sache hier schonmal was gebracht hat .-)
-
Ilker Cetinkaya schrieb am Mittwoch, 3. Februar 2010 23:25:00 Uhr:
Ganz deutlich die dritte Variante.
Du erwähnst hier die GUID als Activation-Key. Bei einem solchen Verfahren braucht wendet man öfters eine Datenbank-Tabelle oder ähnliches um die Keys zu den Usern zuzuordnen. Ausnahmefall wäre dann, wenn die Aktivierungs-GUID gleich der User-GUID wäre. Empfehlenswert ist dies allerdings nicht.
Ich schließe mich Sven an und empfehle eine Expiration-Policy. Im klassischen Ansatz (also mit Hilfe der schon erwähnten "Activation"-Tabelle) gibt man dort einfach das Anfragedatum mit an.
Es gibt aber auch Systeme, die Activation-Keys erstellen, ohne eine Tabelle oder sonstigen Speicher anzuwenden. Die Technik ist etwas "abgehoben" (gerade für Deinen beschriebenen Passwort-Vergessen-Fall), aber bei High-Volume-Systemen sicher eine Überlegung wert: Statt einer GUID als Activation-Key wird ein symmetrisch verschlüsselter Key angewendet, der bei Entschlüsselung Nutzerkennung und Anfragedatum auslesbar macht.
Im Regelfall ist man mit Variante 3 und der GUID ziemlich gut aufgestellt.
-
schrieb am Mittwoch, 3. Februar 2010 23:33:00 Uhr:
Ja. Das Problem der Guid ist erfahrungsgemäß ein ganz simples, praktisches: Sie enthält Bindestriche und wird deshalb von vielen Mailclients ggf. umgebrochen, wenn man sie als GET-Parameter an eine URL anhängt, was sich ja anbietet.
Aber dafür kann man sich Lösungen einfallen lassen, im einfachsten Fall entfernt man die Bindestriche aus der Guid einfach.
