it-swarm.com.de

Hash setzen, mit Passwort anmelden?

Ich bin gerade auf ein Passwort-Hashing/Passwort-Reset-Schema gestoßen, das ich noch nie gesehen habe. Ich bin skeptisch, kann mir aber keinen konkreten Grund vorstellen, warum dies schlecht ist.

Das Schema für die Kontoerstellung/das Zurücksetzen des Passworts sieht folgendermaßen aus:

1) Der Benutzer gibt das Passwort "FuzzyCat" In eine clientseitige App ein.

2) Die clientseitige App hascht das Kennwort hash("FuzzyCat") -> "99476bb..." (möglicherweise nach Anforderung der Hashing-Richtlinie - Salt, welche Hash-Funktion usw. - vom Server) und leitet den Hash an den Server weiter.

3) Der Server speichert "99476bb..." In der Datenbank als Kennwort-Hash für diesen Benutzer.

4) Wenn der Benutzer sich als nächstes anmeldet, gibt er "FuzzyCat" Ein, der Server hascht es und vergleicht es mit "99476bb..." In der Datenbank.


Der Anwendungsfall, in dem ich dies gesehen habe, ist, dass Konten anfänglich von einem Automatisierungsskript als Teil eines mehrstündigen Massenprozesses erstellt werden und wir die Klartextkennwörter während dieser Zeit lieber nicht im Speicher/auf der Festplatte haben möchten. Alle nachfolgenden Anmeldungen des Benutzers erfolgen direkt über einen sicheren Kanal beim Dienst (Hinweis: nicht https, ich meine den Typ "Logbuch signieren, um physischen Zugriff auf den Raum zu erhalten").

Der Grund, warum wir dem Automatisierungsskript nicht vertrauen, ist, dass es in einer Sprache mit unveränderlichen Zeichenfolgen und Garbage Collection geschrieben ist. Daher wird jeglicher Speicher, der Kennwörter enthält, nicht auf Null an das Betriebssystem zurückgegeben - was nicht unserem internen entspricht Richtlinien für die Passwortbehandlung. Ja, das Hauptanliegen ist ein passives MitM.


Frage : Welche möglichen Schwachstellen/Probleme könnte es bei diesem Schema geben?

Das einzige, woran ich denken kann, ist, dass der Server sich darauf verlassen muss, dass der Client ehrlich ist und die Hashing-Richtlinie befolgt, damit Benutzer möglicherweise schwache Hashes in die Datenbank einfügen können. Dies ist keine große Sache, da der Server beim Anmelden sein Passwort mit der tatsächlichen Hashing-Richtlinie hasht und die Hashes nicht übereinstimmen, also kein Login, kein Verstoß.

Soweit ich das beurteilen kann, besteht für einen Angreifer kein Risiko, dass er den Hash erhält, da dies ihm nicht hilft, sich anzumelden. Vermisse ich etwas?

22
Mike Ounsworth

Ich stimme @Xiong Chiamiov zu, an diesem Ansatz ist an sich nichts auszusetzen.

Auf der anderen Seite bietet es dem Standardansatz keinen großen Nutzen (alles Hashing wird serverseitig durchgeführt), und es besteht definitiv ein gewisses Risiko, den Hash nicht vertrauenswürdigen Entitäten offenzulegen.

Wenn dem ursprünglichen Client nicht vertraut wird, hat dies offensichtlich nichts zu tun, da der Client nur das eingegebene Kennwort protokollieren könnte.

Wenn die ursprüngliche Verbindung zwischen Client und Server nicht vertrauenswürdig ist, hilft dies nur wenig. Ein passiver Mann in der Mitte hat immer noch den Hash erhalten und kann versuchen, ihn zu knacken. Ein aktiver Mann in der Mitte könnte den Hash ändern, um Zugriff zu erhalten, oder die Antwort auf die Hashing-Richtlinie ändern, um einen schwachen Hash zu erzwingen, um das Passwort zu erhalten (oder überhaupt kein Hashing erzwingen; oder einfach Javascript oder ähnliches injizieren, um das auszulesen eingegebenes Passwort).

Der einzig sinnvolle Anwendungsfall ist daher die begrenzte Abschwächung gegen einen passiven Mann in der Mitte bei der ersten Anmeldung. Wenn ich darauf stoßen würde, würde ich überprüfen, wie wenig vertrauenswürdig die anfängliche Anmeldung wirklich ist und ob es keinen vernünftigeren Ansatz gibt, als den Hash offenzulegen.

17
tim

Das Problem, das tritt normalerweise auf , wenn es um clientseitiges Hashing geht, ist, dass ein Angreifer, der die Datenbank verletzt hat, die Hashes lediglich zur Authentifizierung an den Server weitergeben kann. Dieses Schema erlaubt jedoch nicht die Verwendung des Hashs zur Authentifizierung, sondern nur die erstmalige Kontoerstellung, sodass es nicht in diese Falle gerät.

Ich habe solche Dinge gesehen, die im Zusammenhang mit Apache htpasswd-Dateien verwendet wurden. Benutzer generieren einen Digest und senden ihn über einen relativ unsicheren Kanal (z. B. E-Mail) an den Systemadministrator, der ihn dann zur Serverkonfiguration hinzufügt. Während ein System mit Basis- oder Digest-Authentifizierung nicht der Höhepunkt der Computersicherheit ist, zeigt dies, dass es sich nicht um einen völlig neuartigen Ansatz handelt und zumindest einige Aufmerksamkeit auf sich gezogen hat.

Angesichts der Beschreibung, wie Sie es ausdrücken, sehe ich keine offensichtlichen Probleme. Es kann natürlich Implementierungsprobleme geben, wie z. B. einen Fehler, bei dem der Hash anstelle des Kennworts zur Authentifizierung eingegeben werden kann. Und da die ursprüngliche Verbindung nicht vertrauenswürdig ist, ist es für einen Angreifer wahrscheinlich etwas einfacher, einen Kennwort-Hash zu erhalten (für den er dann versuchen kann, eine Kollision zu knacken oder zu generieren). Dies sind jedoch keine Probleme mit dem System selbst oder größere Probleme.

Zwei Nissen

möglicherweise nach Anforderung der Hashing-Richtlinie - Salt, welche Hash-Funktion usw. - vom Server

Mir ist nicht klar, ob dieser Mechanismus ein Salz pro Benutzer oder ein globales Salz verwendet. Wenn ein globales Salz verwendet wird, ist es anfällig für einen Regenbogenangriff.

Der Server speichert "99476bb ..." in der Datenbank als Kennwort-Hash für diesen Benutzer.

Da der Hash außerhalb des Servers generiert wurde, kann der Server keine Regeln für die Komplexität oder Länge von Kennwörtern durchsetzen. Sie müssten von der App erzwungen werden. Es gibt auch keine Möglichkeit, die Wiederverwendung von Passwörtern zu überprüfen.

2
John Wu

Ich glaube nicht, dass das vorgeschlagene System ein zusätzliches Risiko mit sich bringt, aber ich bin mir nicht sicher, ob es tatsächlich eines verringert. Es scheint eine wichtige Information zu fehlen. Wie können Sie den Kunden im Rahmen dieses Schemas zunächst überprüfen, um festzustellen, wer er zu sein glaubt, bevor Sie ihm erlauben, den Hash festzulegen? Dies ist die eigentliche Herausforderung. Es gibt verschiedene Möglichkeiten, wie Sie einen Kennwortsatz/eine Kennwortänderung über das Kabel kommunizieren können, um MitM-Angriffe zu verhindern. Wenn Sie jedoch die Remote-Einrichtung eines beliebigen Authentifizierungsprozesses zulassen möchten, besteht das Problem darin, das zu überprüfen Remote-Benutzer.

Ich bin auch nicht davon überzeugt, dass die Politik, die Sie veranlasst, diese Alternative in Betracht zu ziehen, von wirklichem Nutzen ist, außer dass sich die Prüfer besser fühlen. Seien wir ehrlich, wenn Ihr Risiko darin besteht, Kennwortinformationen aus dem Betriebssystemspeicher zu sammeln, besteht das eigentliche Problem in einer angemessenen Kontrolle über den Zugriff auf das Betriebssystem und diesen Speicher, nicht auf das, was sich im Speicher befindet. Wenn jemand über diese Zugriffsebene verfügt, kann er Ihren Basisauthentifizierungsprozess wahrscheinlich trotzdem gefährden. Alles, was die Richtlinie wirklich tut, ist das Hinzufügen von Komplexität, was wahrscheinlich andere Probleme verursachen wird.

2
Tim X