Hey, zuerst, lass mich sagen, ich frage nicht nach Dingen wie md5 (md5 (..., es gibt bereits Themen darüber.
Meine Frage ist das:
Wir erlauben unseren Kunden, ihre Passwörter lokal zu speichern. Natürlich möchten wir nicht, dass sie im Plantext gespeichert werden, also werden sie lokal gespeichert, bevor sie gespeichert und / oder gesendet werden. Nun, das ist in Ordnung, aber wenn dies alles ist, dann hätte der Server den gespeicherten hmac, und da der Client nur das hmac und nicht das Klartextpasswort senden muss, könnte ein Angreifer die gespeicherten Hashes vom Server verwenden um auf ein Konto zuzugreifen (in dem katastrophalen Szenario, in dem jemand natürlich einen solchen Zugriff auf die Datenbank erhalten würde).
Unsere Idee war also, das Passwort auf dem Client einmal über hmac zu verschlüsseln, es an den Server zu senden und dort ein zweites Mal über hmac zu codieren und es mit dem gespeicherten, zweifach hmac-geschützten Passwort abzugleichen. Dies würde sicherstellen, dass:
Natürlich gelten auch alle anderen Dinge (starke Passwörter, Doppelsalz, usw.), sind aber für die Frage nicht wirklich relevant.
Die eigentliche Frage lautet: Klingt das nach einem soliden Sicherheitsdesign? Haben wir irgendwelche Fehler übersehen, wenn wir die Dinge so gemacht haben? Gibt es vielleicht ein Sicherheitsmuster für so etwas?
Nachtrag: Der Grund, warum wir das Passwort nicht im Klartext auf dem Client speichern möchten, liegt darin, dass viele Leute immer noch dasselbe Passwort für mehrere Dienste verwenden, um das "echte" Passwort zu erhalten eine größere Sicherheitsverletzung für den Benutzer sein, als sein Hash gestohlen zu bekommen.
Wie andere schon gesagt haben, wenn Sie den Client und Ihr System isoliert betrachten, kauft Ihnen das wirklich nichts - der erste Hash wird einfach zum Passwort.
Der Wert kommt, wenn (wie es wahrscheinlich ist) der Client dasselbe Passwort auf anderen Systemen verwendet. Sollte in diesem Fall der Client-Computer kompromittiert sein, erlaubt zumindest die lokale Kopie des Hash-Passworts dem Angreifer keinen Zugriff auf andere Systeme. Offensichtlich wird der Angreifer des Clients jetzt in der Lage sein, auf Ihren Server zuzugreifen - sie haben schließlich das Passwort erhalten.
Ein Angreifer, der Zugriff auf den Wert mit doppeltem Hashwert auf dem Server hat, kauft ihnen nichts, da er dies nicht rückgängig machen kann, um den einzelnen Hash (d. h. das "Passwort") zu erhalten. Wenn der Angreifer in der Lage ist, Ihre Sicherheitsdatenbank zu lesen, habe ich natürlich den Verdacht, dass andere Angriffsvektoren verfügbar sind:)
Auch, wie ein anderes Plakat sagte, stellen Sie sicher, dass Sie ein Salz auf beiden Hashes verwenden. Ohne dies zu tun, kann das Umkehren der Hashes tatsächlich ziemlich einfach sein, wenn die Passwörter nicht stark sind.
BEARBEITEN - tatsächlich, darüber nachdenkend, da Sie einen Hash als Passwort verwenden, müssen Sie nicht wirklich eine Salz auf dem Server verwenden. Niemand wird in der Lage sein, eine Regenbogen-Tabelle zu erstellen, die effektiv ist :) Immer noch eine auf dem Client.
Ich renne aus der Tür, aber der Skeet hat gepingert und du machst dich nicht mit dem Skeet an.
Was Sie tun, ist ein Passwort durch einen anderen konstanten Wert zu ersetzen. Sie erhalten hier nichts, die einzige Sicherheit, die Sie haben, ist, dass das Klartext-Passwort auf dem Client-Rechner nicht gefunden werden kann.
Was Sie dann zu tun scheinen, ist die Behandlung des HMAC (sind Sie sicher, dass Sie HMAC meinen? Wenn ja, wo kommt der Schlüssel her und wird gespeichert?) des Passworts als das Passwort selbst - Sie senden es vom Client an der Server, auf dem es zur Authentifizierung verwendet wird. Der zweite HMAC oder Hashing ist bedeutungslos - Sie vergleichen mit dem Wert gesendet - es ist ein Passwort mit einem anderen Namen. Also muss ich als Angreifer, anstatt das Passwort zu stehlen, nur den HMAC stehlen, der auf dem Client-Rechner gespeichert ist. Hier wird überhaupt nichts gewonnen.
Vorbehalt: Ich bin kein Sicherheitsexperte. Ich werde blowdart pingen, um zu sehen, ob er Lust hat mitzumachen.
Wenn der Client nur den Hash speichert und effektiv etwas nur basierend auf dem Hash überträgt, dann speichert er effektiv und speichert ihn im Klartext. Der einzige Vorteil, den der erste Hash bietet, ist der, dass wenn das gleiche Passwort auf einem anderen System verwendet wird, dieses andere System nicht kompromittiert wird, wenn der Hash aufgedeckt wird.
Um es anders auszudrücken: Wenn jemand den Hash, der auf dem Server gespeichert ist, bekommen kann, ist das alles, was er braucht, um sich beim System anzumelden ... genauso wie reiner Textspeicher.
Nein, das ist nicht sicher. Der Hashwert ist effektiv das Passwort. Die Tatsache, dass das Passwort von etwas abgeleitet wurde, das der Benutzer als das Passwort betrachtet, spielt keine Rolle. Es ist ein geheimer Wert, der einen Benutzer authentifiziert, richtig? Klingt wie ein Passwort für mich.
Ich denke, es hängt von der Aussage ab: "Natürlich wollen wir nicht, dass sie im Plantext gespeichert werden, also hmazen wir sie lokal, bevor wir sie speichern und / oder senden." Wenn das System so geändert wird, dass das Hash-Passwort jetzt die gleiche Leistung wie das einmal vergebene Passwort hat, sollte dasselbe Sicherheitsmaß mit dem Hash-Passwort verwendet werden.
blowdart trifft den Nagel auf den Kopf - Sie ändern nur den Wert, um zu stehlen, nichts sichernd. Was Sie versuchen zu replizieren ist ein altes Authentifizierungsprotokoll, an das ich mich lebenslang nicht erinnern kann. So funktioniert es:
Bei der Initialisierung erhält der Server Ihr Passwort, iterativ hashed n-mal, dargestellt durch F n (bestanden). Der Kunde hat das Passwort und die Nummer n.
Sie gehen zur Authentifizierung und senden den Server F n-1 (pass) - das heißt, das Passwort wurde n-1-mal hashed. Der Server hashes es noch einmal, vergleicht es mit F n (pass) und wenn sie übereinstimmen erhalten Sie Zugriff. Der Server ersetzt dann F n (pass) durch F n-1 (pass) und dekrementiert n.
Wenn Sie sich das nächste Mal authentifizieren, senden Sie F n-2 (pass) und der Prozess wird wiederholt.
Sehen wir uns die Sicherheit an:
Das versuchen Sie zu erreichen. Es gibt jedoch einen Grund, warum dieses Protokoll nicht verwendet wird - es ist eine riesige Hündin, die synchronisiert werden muss. Wenn der Client und der Server aufgrund eines halbfertigen Schritts nicht mehr synchron sind, sind Sie ausgesperrt. Jegliche Resilienz, die Sie eingebaut haben, um dies zu vermeiden, würde wahrscheinlich die Sicherheit verringern, dass sie erneut abgespielt oder belauscht wird.
Ich bin mir nicht sicher, was das für Sie bedeutet, wenn Sie das Passwort lokal im Klartext speichern.
Der Zweck der lokalen Verschlüsselung besteht darin, zu verhindern, dass ein Hacker das Passwort an Ihren Server senden kann. Wenn Sie jedoch das verschlüsselte Formular über ... senden, haben Sie nichts gekauft.
Stattdessen sollte der lokale Computer das Kennwort in einem zweifach verschlüsselten Format speichern. Bedeutet, dass es entschlüsselt werden kann. Was Sie vor der Übertragung tun. Die Datenbank kann ein unidirektionales verschlüsseltes Format speichern (selbst mit einem separaten Verschlüsselungsmechanismus). Vor dem Vergleich verschlüsseln Sie das, was Sie erhalten haben, und prüfen dann.
Tags und Links security design-patterns passwords hash hmac