Implementierung einer sicheren, einzigartigen "single-use" - Aktivierung URLs in ASP.NET (C#)

Habe ich ein Szenario Iuno Benutzer von einer Website, die ich am Gebäude müssen die Möglichkeit haben, geben Sie einige grundlegende Informationen in einer Web Form-ohne Anmeldung. Die Website ist entwickelt mit ASP.NET/C# und MSSQL 2005 für Ihre relationalen Daten.

Den Benutzer gesendet werden eine E-Mail von der Website, indem Sie Ihnen einen eindeutigen link, um geben Sie die spezifischen Informationen, die Sie benötigt. Die E-Mail sehr ähnlich zu den Stil der email, die wir alle erhalten bei der Registrierung für sites wie Foren, enthält eine zufällig generierte, eindeutige URL-Parameter insbesondere in Bezug auf einen einzigen Zweck (z.B. überprüfen von E-Mail-Adresse für ein forum).

Meine Fragen sind in Bezug auf die sichere Implementierung dieses Problems. Ich überlegte, mit einer GUID als eindeutige Kennung, bin aber unsicher, seine Auswirkungen auf die security world.

  1. Eine GUID ist ausreichend lang, so dass die Werte nicht leicht zu erraten ist (oder brute-gezwungen, im Laufe der Zeit)?

  2. Ist .NET-GUID-Implementierung ausreichend zufällig in dem Sinne, dass es eine gleiche chance der generation, die die möglichen Werte in dem "key space"?

  3. Wenn Sie eine GUID ist ein akzeptabler Ansatz, sollte die Seite dann umleiten, um die Informationen über URL-rewriting oder indem die Daten in eine datatable mit der GUID als Referenz?

  4. Wird die Verwendung einer URL-rewriting verbergen die wahre Quelle der Daten?

  5. Sollte ich in Betracht ziehen mithilfe der TSQL-SELECT NEWID() als GUID-generator über die .NET-Implementierung?

  6. Bin ich völlig falsch mit meinem Ansatz zu diesem problem?

Vielen Dank,

Carl

InformationsquelleAutor Tyst | 2009-06-02
  1. 11
    1. Ja, 2128 ist lang genug.
    2. Nein, GUID-Implementierungen sind entworfen, um zu generieren einzigartige GUIDs eher als zufällige diejenigen. Sollten Sie eine kryptografisch sichere random number generator (z.B. RNGCryptoServiceProvider) zu erzeugen, das 16 zufällige bytes und initialisiert ein Guid Struktur mit, dass.
    3. Ja, es ist ein akzeptabler Ansatz, insgesamt. Beide arbeiten werden.
    4. Ja, wenn Sie nicht geben Sie alle anderen Hinweise
    5. Nein, goto 2
    6. Nein, es ist ziemlich OK. Sie müssen nur verwenden Sie einen kryptographisch sicheren Zufallszahlengenerator, der zum generieren der GUID.
    • Sorry, aber das ist eigentlich falsch und irreführend - GUIDs sind nicht gut für diese Art der Sache, siehe meine Antwort unten.
    • Die GUID ist im Sinne der eindeutige Kennung ist nicht wirklich geeignet (wie ich bereits in #2). Aber es gibt nichts zu verhindern, dass Sie mit Ihnen als eine 128-bit-Zahl.
    • Aber die Sache ist, dass Sie nicht wirklich 128 bit-zahlen (auch wenn Sie es nicht 128 bit um Sie zu speichern). Wieder zu viel davon ist entweder statisch, oder einfach guessable. GUIDs haben keine Verwendung im secure-IDS. Was der OP braucht ist etwas sicherer, und lang genug, im Sinne von "128 bits des Zufalls", die GUIDs sind nicht, auch nicht in der Nähe.
    • Die Sache ist die, Sie verwenden keine Guid.NewGuid() und NEWID() als ich sagte ausdrücklich. Verwenden Sie eine CSRNG zu generieren 16 zufällige bytes und erhalten Sie einen GUID-Darstellung von ihm.
    • Ah, sehen Sie - CRNG tun nicht erzeugen von GUIDs. Ein GUID hat eine ganz bestimmte Struktur, das ist nicht zufällig, nur ein kleiner Teil davon ist.
    • Oh, und solange wir es zu erwähnen - 16 bytes an Zufallsdaten NICHT übersetzen zu 16 Zeichen lang sein - da gibt es eine Menge bytes, vertreten sein werden, die von nicht-druckbaren Zeichen, müssen Sie base64-codieren. So erhalten Sie eine längere Ausgabe-string, der mehr als 24 Zeichen... aber nochmal, das ist nicht 24 bytes im Wert von Zufälligkeit, nur 16.
    • GUID ist nicht 16 ASCII-Zeichen. Es sind 32 hex-Ziffern = 16 bytes, die Sie füllen mit 16 bytes of random data. Ich sehe nicht, eine Beziehung hier.
    • GUID ist nicht 16 bytes an Zufallsdaten, es hat eine ganz bestimmte Struktur, von denen das erste paar (die meisten) bytes sind NICHT zufällig. Das zufällige element ist nur in den letzten paar bytes.
    • Ich habe nie gesagt, Sie würden eine GUID generiert durch den Aufruf Guid.NewGuid. Alle I-Sorgfalt über die GUID-format. Erzeugen Sie 16 beliebige bytes mit einem random number generator und pack es in einen GUID-format. Ja, es kann nicht dienen als "Globally Unique Identifier", aber das spielt keine Rolle. GUID format ist nur ein zweckmäßiges format.

    InformationsquelleAutor Mehrdad Afshari
  2. 14
    1. Keine GUIDs sind nicht vollständig zufällig, und die meisten bits sind entweder statisch oder leicht guessable.
    2. Nein, Sie sind nicht zufällig finden 1. Es ist eigentlich eine sehr kleine Anzahl von bits, die sind wirklich zufällig, und nicht kryptografisch starken zufälligen an.
    3. Es nicht, siehe 1 und 2.
    4. Sie können, aber nicht müssen... siehe meine Lösung am Ende.
    5. Nein, siehe 1 und 2
    6. Ja.

    Was Sie verwenden sollten, anstatt eine GUID ist eine kryptographisch starke Zufallszahlen-generator - Verwendung System.Sicherheit.Die Kryptographie.RNGCryptoServiceProvider, erzeugen lange (sagen wir mal 32 Byte) string-Daten, dann base64-Kodieren, dass.

    Auch, vorausgesetzt, es ist eine Art Registrierung mit sensiblen Daten, die Sie wollen, um die Frist der Gültigkeit des Links, sagen, 60 Minuten oder 24 Stunden - hängt von Ihrem Standort.

    Halten Sie eine Zuordnung dieser Werte zu bestimmten Benutzern. Dann können Sie automatisch, ihm die richtige form, wie gebraucht. Brauchen nicht zu tun, url-rewriting, nur für die Verwendung der Benutzer-id (auf dieser Seite).

    Natürlich, vergessen Sie nicht, dieses URL HTTPS...

    Btw, nur ein Hinweis - die gute Praxis zu setzen irgendeine form von text in der E-Mail erklärt, dass Nutzer nicht auf links klicken, die in anonymen E-Mails, und in der Regel Ihre Website nicht senden, und Sie sollten niemals Ihr Kennwort eingeben, nach einem Klick auf blablabla....

    Oh, fast vergessen - ein weiteres Problem, sollten Sie überlegen, was passiert, wenn der Benutzer möchte mehrere E-Mails geschickt, um ihn, z.B. trifft register mehrfach. Kann er dies tun, immer und immer wieder, und bekommen viele gültige URLs? Ist nur das Letzte gültig? Oder vielleicht den gleichen Wert bekommt, ärgern sich immer und immer wieder? Natürlich, wenn ein anonymer Benutzer kann in einer Anforderung für das E-Mail, dann DoS kann zu einem Problem werden... nicht zu erwähnen, dass, wenn er führt seine eigene E-Mail -, er kann in jeder beliebigen Adresse auch überschwemmungen, einige schlechte shmuck Posteingang und verursacht möglicherweise Ihre E-mail-server auf schwarze Liste...

    Keine richtige Antwort, aber berücksichtigt werden muss, im Kontext Ihrer Anwendung.

    InformationsquelleAutor AviD
  3. 4

    Es wäre des guten zuviel, aber das könnte man hash-Ihre E-Mail-Adresse mit SHA1 mit dem guid (NewGuid ist in Ordnung) als hash-Salz und Ort, die in der URL. Dann, wenn Sie kommen zu Ihrer Seite, könnten Sie Sie bitten, Ihre E-Mail-Adresse abrufen der guid und berechnen den hash zu validieren. Auch wenn jemand zu wissen, was E-Mail-Adressen, um zu versuchen, Sie würde nie in der Lage sein zum generieren einer hash-Kollision, ohne zu wissen, die guid, die Sie gesalzen mit (oder es würde Ihnen noch ein verdammt lange Zeit :). Natürlich müssten Sie speichern Ihre E-Mail-und der hash-Salz-guid in der Datenbank.

    • Obwohl die oben technisch beantwortet meine Fragen direkt, ich Liebe deine Umsetzung der Idee. Nach einiger überlegung habe ich expaneded auf einige: "URL" = SHA1(E-Mail + randomPass + Salz) serverHash = SHA1(E-Mail + randomPass) Tabelle Spalten: serverHash (primary key) Salz Der randompass würde auch gesendet werden, mit der url in die E-Mail und verwendet die original-URL die Berechnung dann verworfen. Ich glaube, dass in dieser Implementierung keine sensiblen Informationen werden in der Datenbank gespeichert. Also selbst wenn der Rohstoff datatable ausgesetzt waren, konnten Sie nicht generieren die URL, um brute-force der E-Mail-Adresse
    • Froh zu helfen. Eine Anmerkung zu deiner Lösung, Sie selbst zu öffnen, um einen neuen Anwendungsfall, da Sie nicht erstellen Sie die E-Mail. Das heißt, die user-Anfragen und E-Mails, hat nichts mit es, Anforderungen andere und klickt dann auf den link in der ersten E-Mail (wie ich bin sicher, Sie wissen, die Nutzer machen sowas 🙂 Also, Sie haben zu verfallen, jedes ServerHash, indem das Datum, an dem Sie die E-Mail geschickt in der DB und gibt dem Benutzer eine angemessene Frist, um zu reagieren.
    • Yup, danke. Ich weiß, dass es. Die E-Mails und URLs generiert werden, sind sehr individuelle und erstellt, um den Benutzer in der Regel sparen Sie sich etwas Geld, so sollten Sie wahrscheinlich verwenden Sie Sie, aber ich werde mit der Umsetzung einiger Handhabung auch.
    • Die meisten Salzen Vorschläge, die ich gelesen habe empfehlen, hinzufügen von Salz an den Anfang als gegen das Ende.
    InformationsquelleAutor JP Alioto
  4. 4

    Ich würde empfehlen, nur mit einem einfachen zufällige Zahl, z.B. bytes aus RNGCryptoServiceProvider.GetBytes . GUIDs sind nicht dazu gedacht völlig zufällig zu sein. Sie haben Feste bits, und einige Versionen verwenden Sie Ihre MAC-Adresse. GetBytes gibt Ihnen auch die Möglichkeit, mehr als 128 bit (obwohl, die sollte reichlich).

    Ich denke, es ist besser, nicht zu den Benutzerdaten in einer url. Obwohl HTTPS schützen kann es im transit, kann es immer noch im browser des Benutzers Geschichte oder so. Es ist besser, POST -, und ordnen Sie die zufällige Zahl mit einer Zeile der Datenbank.

    InformationsquelleAutor Matthew Flaschen
  5. 1

    Erste, wenn möglich sollte man die Grenze von brute-force, durch die Begrenzung der Durchsatz der Abfrage (z.B. eingeschränkte versucht pro IP pro Sekunde, und die begrenzte Gesamtzahl der versuche pro Sekunde).

    Je nach der GUID-Generierung Algorithmus, dies möglicherweise keine gute Idee. Während die aktuellen Implementierungen sollten "gut genug" in der Regel", es kann eine Menge von Vorhersagbarkeit der Werte. Neuere Implementierungen, die man verwendet .NET anwenden einer hash, sonst haben Sie eindeutig identifizierbar Felder für MAC-Adresse, und die Zeit seit Booten. Allerdings sind die möglichen Werte beschränkt sind, so dass Sie nicht haben wahr, 128 random bit.

    Wenn die Sicherheit ist die oberste Priorität, ich würde wählen Sie eine kryptografisch starken Zufallszahlengenerator und bauen einen string aus zufälligen Zeichen. Dies macht auch oyu unabhängig von einer leicht guessable Algorithmus (als guid.ToString() ist leicht als solche identifiziert), für die ein Angriff entdeckt werden könnte in der nahen Zukunft.

    Wenn diese Kriterien erfüllt sind, sehe ich kein problem, mit den Schlüssel in der Abfrage-string.

    InformationsquelleAutor peterchen
  6. -1

    erstellen Sie eine Tabelle in der Datenbank mit einem linkID und ein Datesent Spalte, an der Erzeugung des link senden insert DateTime.Nun in die Tabelle und kehren linkId, legen Sie die linkID als querystring-parameter auf die activationLink. Auf die Belastung des Aktivierungs-Seite ermittelt werden die linkId, und verwenden Sie es, um zu erinnern an eine gespeicherte Prozedur, die zurückkehren wird das Datum übergeben, die correspondin linkId als parameter, wenn Sie das Datum zurück, die Sie hinzufügen können, wie lange der link aktiv bleibt, indem mit der .AddDays()/."AddMonths" diese sind C# - Methoden für datetime. dann vergleichen Sie das Datum, an dem Sie zurück kam, mit dem heutigen Datum. wenn es bestanden hat, deren Länge in Tagen oder Monaten eine Fehlermeldung geben oder anders weiter und Anzeige der Inhalte auf der Seite. Ich sugest Sie halten den Inhalt der Seite in einem panel und legen Sie es vissible = "false" dann nur das panel visible="true", wenn das Datum ist immer noch in Reichweite.

    InformationsquelleAutor Spegah
Schreibe einen Kommentar