nicht angemeldet
Moin!
user@example.com meldet sich für einen Double-opt-in-Newsletter an. Daraufhin bekommt er eine Mail, in der einen Bestätigungslink klicken muss.
Dieser Link hat den folgenden Aufbau
http://www.example.com/optIn?eMail=user@example.com&randomId=238ujkvIm Grunde erhält er also mit dieser Mail eine Art Passwort, die ihn legitimiert. Soweit ich weiss, ist das Dank Sniffern zwar nicht hieb- und stichfest, sollte aber doch fuer diesen einmaligen Einsatz wohl in Ordnung sein.
Sofern die zufällige ID wirklich nicht vorhersagbar ist und ggf. auch ein begrenztes Zeitfenster für die Bestätigung dieser Aktion gilt, ist das Verfahren absolut in Ordnung.
Jetzt abonniert der User aber noch andere Newsletter (zu anderen Themen) von derselben Seite, die er alle mit obigem Verfahren bestätigt hat - in unserem Beispiel seien das mal 20 Stück.
Jeder Newsletter, den er nun bekommt, enthält auch einen Abmeldelink. Um es ihm zu ersparen, alle Newsletter einzeln abmelden zu müssen (vorrausgesetzt, er will sie alle loswerden), führt dieser Link zu einer Konfigurationsseite, wo er per Häkchen bequem angeben kann, welche er alle loswerden, und welche er behalten will.
Jetzt die Frage: auch der Abmeldelink könnte bereits seine RandomId enthalten, also bspw.
http://www.example.com/optOut?eMail=user@example.com&randomId=238ujkv
Die zufällige ID gehört nur dann individuell neu generiert, wenn eine den Status Quo verändernde Aktion bestätigt werden soll.
Der Link zum Abmelden führt auf eine Seite, die den Abmeldevorgang anstößt, indem eine Bestätigungsmail versendet wird, sofern der Mailempfänger bislang angemeldet war. Die Bestätigungsmail enthält eine neue zufällige ID, um diese Aktion zu bestätigen.
Ob es schlau ist, eine Auswahlseite anzubieten, auf der multiple Abonnements zusammengefaßt beeinflusst werden können, hängt vermutlich von bisher bestehender Infrastruktur ab, und natürlich vom Anspruch an die Realisierung. Der Zugriff auf diese Einstellungsseite gehört aber in jedem Fall passwortgeschützt gestaltet, und dieses Passwort hat mit der zufälligen ID nichts zu tun.
So eine Zentralseite würde also eine zusätzliche parallele Ebene der Authentifizierung bedeuten, sofern du nicht vorhast, den Benutzer zu zwingen, per Mail eine RandomID für den einmaligen, zeitlich befristeten Zugang zu dieser Seite anzufordern.
Änderungen, die er dann vornimmt, könnten ohne weitere Bestätigung direkt umgesetzt werden, da er sich ja bereits authentifiziert hat.
Nein, grundsätzlich sollte der Mechanismus der Mailbestätigung immer konsequenz bis zum Ende durchgeführt werden: Wer sich - egal auf welchem Wege - für einen Newsletter o.ä. anmeldet, kriegt eine Mail mit der Information, was er da bestellt hat, und dem Bestätigungslink. Ohne diese Bestätigung sollte sich nichts am Status Quo ändern.
Da die angegebene RandomId mehrfach verwendet werden kann, muss sie zumindest für einen gewissen Zeitraum persistent sein, ich kann sie also nicht bei jedem Vorgang neu setzen.
Das ist der Schwachpunkt deiner Idee. Die ID sollte dem jeweiligen Veränderungsvorgang zugeordnet sein, nicht dem Useraccount insgesamt.
Dummerweise könnten auch Fremde mit dieser ID Unsinn treiben. Darum zwei Fragen:
- Wie leicht können Mails von Fremden abgegriffen werden? Und geht das auch gezielt?
Mails werden in der Regel unverschlüsselt übertragen (zumindest kann man das provozieren, auch wenn mittlerweile viele Mailserver SMTP im TLS-Tunnel übertragen, also gegenüber mithörenden Dritten verschlüsseln - dieser Vorgang ist keine Garantie), also könnte man durch Manipulationen grundsätzlich Kenntnis vom Mailinhalt erlangen.
Das funktioniert aber in der Regel nicht so einfach, wie es sich vielleicht in Hollywoodfilmen darstellt. Deine größte Sorge sollte sich auf die Generierung nicht erratbarere Zufalls-IDs richten.
- Haltet ihr das Verfahren generell für geeignet oder seht ihr da eher riesige Probleme?
Die Absegnung von Mailbestellungen durch Zurücksenden eines nicht ratbaren Authentifizierungsstrings ist absolutes Standardverfahren.
- Sven Rautenberg