https URL mit Token Parameter: Wie sicher ist es?

Auf unserer Website bieten wir Benutzern eine Simulation basierend auf ihren privaten Informationen (über ein Formular angegeben). Wir möchten ihnen erlauben, später wieder auf ihre Simulationsergebnisse zurückzugreifen, ohne sie jedoch zu zwingen, ein Login / Passwort-Konto zu erstellen.

Wir haben darüber nachgedacht, ihnen eine E-Mail mit einem Link zu senden, über den sie ihre Ergebnisse zurückerhalten können. Aber natürlich müssen wir diese URL sichern, da es um private Daten geht.

Wir beabsichtigen daher, ein Token (wie eine Kombination aus Buchstaben und Ziffern mit 40 Zeichen oder einen MD5-Hash) in der URL zu übergeben und SSL zu verwenden.

Schließlich würden sie eine solche E-Mail erhalten:

Hallo, erhalten
Sie Ihre Ergebnisse auf https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn zurück

Was denkst du darüber? Ist es sicher genug? Was würden Sie mir für die Token-Generation raten? Was ist mit der Übergabe von URL-Parametern in einer https-Anfrage?

SSL schützt die Abfrageparameter während der Übertragung. Die E-Mail selbst ist jedoch nicht sicher, und die E-Mail kann auf einer beliebigen Anzahl von Servern übertragen werden, bevor sie an ihr Ziel gelangt.

Abhängig von Ihrem Webserver wird möglicherweise auch die vollständige URL in den Protokolldateien protokolliert. Abhängig davon, wie sensibel die Daten sind, möchten Sie möglicherweise nicht, dass Ihre IT-Mitarbeiter Zugriff auf alle Token haben.

Außerdem wird die URL mit der Abfragezeichenfolge im Verlauf Ihres Benutzers gespeichert, sodass andere Benutzer desselben Computers auf die URL zugreifen können.

Und was dies sehr unsicher macht, ist, dass die URL im Referer-Header aller Anforderungen für eine Ressource gesendet wird, auch für Ressourcen von Drittanbietern. Wenn Sie beispielsweise Google Analytics verwenden, senden Sie Google das URL-Token und alle an Google.

Meiner Meinung nach ist das eine schlechte Idee.

Ich würde dafür einen Cookie verwenden. Der Workflow sollte folgendermaßen aussehen:

1. Der Benutzer kommt zum ersten Mal auf Ihre Website.
2. Site setzt ein Cookie
3. Benutzer gibt Daten ein. Daten werden in der Datenbank mit einem Schlüssel gespeichert, der im Cookie gespeichert ist.
4. Wenn der Benutzer das Unternehmen verlässt, senden Sie ihm eine E-Mail mit einem https: -Link
5. Wenn der Benutzer zurückkommt, erkennt die Site das Cookie und kann dem Benutzer die alten Daten präsentieren.

Jetzt möchte der Benutzer einen anderen Browser auf einem anderen Computer verwenden. Bieten Sie in diesem Fall eine Schaltfläche "Übertragen" an. Wenn der Benutzer auf diese Schaltfläche klickt, erhält er einen "Token". Sie kann dieses Token auf einem anderen Computer verwenden, um das Cookie zurückzusetzen. Auf diese Weise entscheidet der Benutzer, wie sicher er das Token übertragen möchte.

SSL sichert den Inhalt der Daten während der Übertragung, aber ich bin mir über die URL nicht sicher.

Unabhängig davon besteht eine Möglichkeit, einen Angreifer, der dieses URL-Token wiederverwendet, zu verringern, darin, sicherzustellen, dass jedes Token nur einmal verwendet werden kann. Sie können sogar ein Cookie setzen, damit der legitime Benutzer den Link weiterhin verwenden kann. Nach dem ersten Zugriff funktioniert es jedoch nur für jemanden mit dem Cookie.

Wenn die E-Mail-Adresse des Benutzers kompromittiert ist und ein Angreifer zuerst den Link erhält, werden Sie abgespritzt. Der Benutzer hat aber auch größere Probleme.

E-Mail ist von Natur aus unsicher. Wenn jemand auf diesen Link klicken und zu den Daten gelangen kann, schützen Sie sie nicht wirklich.

Nun, das Token ist sicher, wenn es über SSL übertragen wird. Das Problem, das Sie haben werden, ist, dass es für Personen (diejenigen, für die es nicht bestimmt ist) verfügbar ist, indem sie die URL anzeigen können.

Wenn es sich um private Informationen wie SSN handelt, würde ich wahrscheinlich keine URL per E-Mail senden. Ich möchte lieber, dass sie einen Benutzernamen und ein Passwort für die Site erstellen. Es ist zu einfach, eine E-Mail mit solchen Informationen zu kompromittieren, die für Sie und für sie auf dem Spiel stehen. Wenn jemandes Konto komprimiert ist, wird es in Frage gestellt, wessen Schuld es wirklich ist. Je sicherer Sie sind, desto besser sind Sie vom CYA-Standpunkt aus.

Ich würde das wirklich nicht als sicher genug für eine Situation betrachten, in der es ernsthafte Datenschutzprobleme gibt. Die Tatsache, dass Sie die URL in einer (vermutlich Klartext-) E-Mail senden, ist bei weitem das schwächste Glied. Danach besteht das Risiko von Brute-Force-Angriffen auf die Token, die (ohne die Struktur eines echten Authentifizierungsmechanismus) wahrscheinlich anfälliger sind als eine gut aufgebaute Einrichtung für Benutzernamen und Kennwörter.

Übrigens gibt es überhaupt keine Probleme mit den Parametern in einer https-Anfrage.

So wie es ist, wäre es eine schlechte Idee. Sie werden die Sicherheit durch einfache Bedienung verbessern. Wie bereits erwähnt, schützt SSL nur die Übertragung von Informationen zwischen Server und Client-Browser und verhindert nur den Middle-Man-Angriff. E-Mails sind sehr riskant und unsicher.

Am besten wäre eine Authentifizierung mit Benutzername und Passwort, um auf die Informationen zuzugreifen.

Ich mag die Cookie-Idee mehr oder weniger. Sie sollten auch die Cookie-Informationen verschlüsseln. Sie sollten das Token auch mit Salt und Schlüsselphrase sowie $ _SERVER ['HTTP_USER_AGENT'] generieren, um die Wahrscheinlichkeit eines Angriffs zu begrenzen. Speichern Sie so viele nicht sensible Informationen über den Client im Cookie, dass Sie sie überprüfen können.

Der Schlüsselbegriff kann zur einfachen Verwendung im Cookie gespeichert werden. Beachten Sie jedoch, dass auch Cookies gestohlen werden können = (.

Lassen Sie den Kunden besser die von ihm angegebene Schlüsselphrase eingeben, die zusammen mit seinen Daten auch in der Datenbank gespeichert ist.

Der Schlüssel kann auch verwendet werden, wenn die Person einen anderen Computer verwendet, der sich in den Parametern $ _SERVER ['HTTP_USER_AGENT'] unterscheidet oder einfach das Cookie übersieht. So kann der Cookie übertragen oder gesetzt werden.

Stellen Sie außerdem sicher, dass vertrauliche Daten in der Datenbank verschlüsselt sind. Man weiß nie ;)

Sie wissen, dass, wenn ein Hacker Zugriff auf Ihre Datenbank erhält, viele persönliche Informationen frei gegeben werden können?

Danach würde ich sagen, dass dies als Idee nicht schlecht ist. Ich würde MD5 oder SHA1 nicht verwenden, da sie für das Hashing nicht sehr sicher sind. Sie können ganz einfach "entschlüsselt" werden (ich weiß, dass es keine Verschlüsselung ist).

Andernfalls würde ich möglicherweise eine zweite Information verwenden, die nicht per E-Mail gesendet wird. Der Grund ist ganz einfach: Wenn jemand Zugriff auf die E-Mail des Benutzers erhält (ganz einfach mit Hotmail, wenn Sie Ihre Sitzung nicht beenden), hat er Zugriff auf alle Informationen, die der Benutzer gesendet hat.

Beachten Sie, dass das HTTPS Daten schützt und verschlüsselt, die von Ihrer Site an den Endbenutzer gesendet werden. Nichts anderes, nimm es als sicheren Tunnel. Nichts mehr, nicht weniger.

Nach meinem Verständnis Ihrer Idee könnte theoretisch jemand eine zufällige 40-Zeichenfolge oder einen MD5-Hash eingeben und andere Details abrufen. Dies ist zwar höchst unwahrscheinlich, muss aber nur einmal geschehen.

Eine bessere Lösung könnte darin bestehen, dem Benutzer ein Token zu senden und ihn dann aufzufordern, einige Details wie Name, Postleitzahl, SSN oder eine Kombination davon einzugeben.