Eddie: Sicherheit: Bestätigungslinks einfach und sicher

Hallo allerseits,

bei folgendem bekannten Problem würde mich eure Meinung interessieren:

===================================

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=238ujkv

Im 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.

Erste Einwände?

===================================

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

Änderungen, die er dann vornimmt, könnten ohne weitere Bestätigung direkt umgesetzt werden, da er sich ja bereits authentifiziert hat.

Und wäre das nicht toll und einfach?!?

===================================

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.
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?

  • Haltet ihr das Verfahren generell für geeignet oder seht ihr da eher riesige Probleme?

Danke für eure Hilfe,
Eddie

--
Old men and far travelers may lie with authority.
    • Wie leicht können Mails von Fremden abgegriffen werden? Und geht das auch gezielt?

    solange das "password" geheimgehalten wird, nein

    • Haltet ihr das Verfahren generell für geeignet oder seht ihr da eher riesige Probleme?

    riesige probleme

    ggf. hilft dir dieser thread auf die sprünge

    1. Hallo suit,

      ggf. hilft dir dieser thread auf die sprünge

      Nicht wirklich, soweit war ich auch schon. Interessant ist allerdings die Anmerkung, dass die RandomId (bisher erzeugt mit uniqid()) nicht rein zeitabhängig sein sollte. Werde ich ändern, z.B. in  md5(uniqid (rand())).

      Eddie

      --
      Old men and far travelers may lie with authority.
      1. Nicht wirklich, soweit war ich auch schon.

        wenn du schon so weit warst, was ist dann das eigentliche problem?

        Interessant ist allerdings die Anmerkung, dass die RandomId (bisher erzeugt mit uniqid()) nicht rein zeitabhängig sein sollte. Werde ich ändern, z.B. in  md5(uniqid (rand())).

        das ganze rein zeitabhängig zu machen ist insofern uncool, da man das ganze dann erraten kann

        ich registriere mich mit 2 mail adressen (zuerst mit meiner) dann vergleiche ich meinen hash mit meinem registrierzeitpunkt und schließe so auf den timestamp zurück - aus dem kann ich mir die differenz zwischen lokaler zeit und serverzeit ausrechnen - nun kann ich eine registrierung mit einer mailadresse durchführen die garnicht mir gehört und so den hash erraten und brauche wahrscheinlich nur ein paar versuche bis ich den richtigen habe

        nachdem ich jetzt einen account mit "nicht meiner" mailadresse besitze, kann ich damit wahrscheinlich dinge anstellen, die für den besitzer der eigentlichen adresse sehr uncool sind (was, wüsste ich zwar nicht, aber dinge gibts sicher genug)

  1. Hello,

    • Wie leicht können Mails von Fremden abgegriffen werden? Und geht das auch gezielt?

    Mailkonten können angegriffen werden per Wörterbuchattacke
    In üblichen Mail-Dialogen steht das Passwort für den Mailzugang nur im Klartext drin.
    Ein Mailaccount eines Users könnte durch Verlust der Domain verloren gehen und jemand anderes grabbt die Domain, schon kann er 'legal' Zugriff auf die Zone nehmen (lassen) und die Mails zu sich umleiten.

    Ich würde daher in eMails niemals Passwort und Loginnamen versenden.
    Ich würd auch den Loginnamen daher niemals als Anrede verwenden. Der gehört nur in den HTTPs-Dilaog mit dem User, wenn _der_ ihn eingibt.

    Für den Mailverkehr selber würde ich TLS aktivieren, dann ist auch die Gefahr des Aufbrechens eines geschützen eMail-Relays wesentlich reduziert, da der Anmeldedialog mit dem SMTPd dann auch im Tunnel stattfindet. Die üblichen Mailclients können das alle.

    Liebe Grüße aus Syburg bei Dortmund

    Tom vom Berg

    --
    Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de
  2. 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=238ujkv

    Im 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

    1. Die Absegnung von Mailbestellungen durch Zurücksenden eines nicht ratbaren Authentifizierungsstrings ist absolutes Standardverfahren.

      wichtig ist eben dabei die "nicht erratbarkeit" - aus dem grund auch in meinem thread die angesprochene "nicht nur an die zeit binden" geschichte - wenn die "zufallszahl" lediglich der hash des aktuellen timestamps ist, kann man das eben sehr sehr schnell erraten