it-swarm-eu.dev

Was nützt ein Client Nonce?

Nachdem ich Teil I von Ross Andersons Buch Security Engineering gelesen und einige Themen auf Wikipedia geklärt hatte, stieß ich auf die Idee von Client Nonce (cnonce). Ross erwähnt es nie in seinem Buch und ich habe Schwierigkeiten zu verstehen, welchen Zweck es bei der Benutzerauthentifizierung erfüllt.

Eine normale Nonce wird verwendet, um Wiederholungsangriffe zu vermeiden, bei denen eine abgelaufene Antwort verwendet wird, um Berechtigungen zu erhalten. Der Server stellt dem Client eine Nonce (EINMAL verwendete Nummer) zur Verfügung, die der Client verwenden muss, um seine Antwort zu hashen. Der Server hasht dann die erwartete Antwort mit der von ihm bereitgestellten Nonce und wenn der Hash des Clients mit dem Hash der übereinstimmt Server kann der Server dann überprüfen, ob die Anforderung gültig und aktuell ist. Dies ist alles, was es überprüft; gültig und frisch .

Die Erklärungen, die ich für einen Kunden gefunden habe, sind jedoch weniger einfach und fragwürdig. Die Wikipedia-Seite für die Authentifizierung des digitalen Zugriffs und mehrere Antworten hier auf Stackoverflow scheinen darauf hinzudeuten, dass eine Client-Nonce verwendet wird, um ausgewählte Klartextangriffe zu vermeiden. Ich habe mehrere Probleme mit dieser Idee:

  • Wenn eine Person Pakete schnüffeln und einfügen kann, ist die größte Sicherheitslücke ein Man-in-the-Middle-Angriff, den weder ein Nonce noch ein Cnonce überwinden können, wodurch beide bedeutungslos werden.
  • Angenommen, der Angreifer möchte sich nicht auf einen Man-in-the-Middle-Angriff einlassen und die Authentifizierungsdetails wiederherstellen. Wie bietet ein cnonce zusätzlichen Schutz? Wenn der Angreifer die Kommunikation abfängt und auf eine Anfrage mit seiner eigenen Nonce antwortet, ist die Antwort des Clients ein Hash der Nonce, Daten und Cnonce zusätzlich zur Cnonce in unverschlüsselter Form. Jetzt hat der Angreifer Zugriff auf Nonce, Cnonce und Hash. Der Angreifer kann nun seine Regenbogentabellen mit Nonce und Cnonce hashen und eine Übereinstimmung finden. Daher bietet der cnonce keinen zusätzlichen Schutz.

Also, was ist der Zweck eines cnonce?

Ich gehe davon aus, dass es einen Teil der Gleichung gibt, den ich nicht verstehe, aber ich habe noch keine Erklärung dafür gefunden, was dieser Teil ist.

EDIT Einige Antworten deuten darauf hin, dass der Client eine Nonce bereitstellen kann und denselben Zweck erfüllt. Dies bricht das Challenge-Response-Modell. Welche Auswirkungen hat dies?

85
user2014

A nonce ist ein eindeutiger Wert, der von einer Entität in einem Protokoll ausgewählt wird. Er wird verwendet, um diese Entität vor Angriffen zu schützen, die unter das sehr große Dach der "Wiederholung" fallen.

Stellen Sie sich zum Beispiel ein passwortbasiertes Authentifizierungsprotokoll vor, das folgendermaßen aussieht:

  • der Server sendet eine "Herausforderung" (ein angeblich zufälliger Wert c) an den Client
  • der Client sendet daraufhin h (c || p) wobei h eine sichere Hash-Funktion ist (z. B. SHA-256), p ist das Benutzerkennwort und ' ||' bezeichnet die Verkettung
  • der Server sucht das Kennwort in seiner eigenen Datenbank, berechnet die erwartete Clientantwort neu und prüft, ob sie mit dem übereinstimmt, was der Client gesendet hat

Passwörter sind geheime Werte, die in das menschliche Gehirn passen. Als solche können sie nicht sehr komplex sein, und es ist möglich, ein großes Wörterbuch zu erstellen, das mit hoher Wahrscheinlichkeit das Benutzerkennwort enthält. Mit "groß" meine ich "kann in wenigen Wochen mit einem mittelgroßen Cluster aufgezählt werden". Für die aktuelle Diskussion akzeptieren wir, dass ein Angreifer in der Lage sein wird, ein einzelnes Kennwort zu brechen, indem er einige Wochen mit Berechnungen verbringt. Dies ist die Sicherheitsstufe, die wir erreichen wollen.

Stellen Sie sich einen passiven Angreifer vor: Der Angreifer lauscht, ändert aber nicht die Nachrichten. Er sieht c und h (c || p), sodass er mit seinem Cluster potenzielle Passwörter aufzählen kann, bis eine Übereinstimmung gefunden wird. Das wird teuer für ihn. Wenn der Angreifer zwei Passwörter angreifen möchte, muss er den Job erledigen zweimal. Der Angreifer möchte eine gewisse Kostenteilung zwischen den beiden Angriffsinstanzen mit vorberechneten Tabellen ("Regenbogentabellen" sind nur eine Art vorberechnete Tabelle mit optimiertem Speicher, aber das Erstellen einer Rainbow-Tabelle erfordert immer noch das Auflisten des vollständigen Wörterbuchs und das Hashing jedes Passworts. Die zufällige Herausforderung besiegt jedoch den Angreifer: Da jede Instanz eine neue Herausforderung beinhaltet, ist die Eingabe der Hash-Funktion für jede Sitzung unterschiedlich, selbst wenn dasselbe Kennwort verwendet wird. Daher kann der Angreifer keine nützlichen vorberechneten Tabellen erstellen, insbesondere keine Rainbow-Tabellen.

Angenommen, der Angreifer wird aktiv. Anstatt die Nachrichten einfach zu beobachten, ändert er aktiv Nachrichten, löscht einige, dupliziert andere oder fügt eigene Nachrichten ein. Der Angreifer kann jetzt einen Verbindungsversuch vom Client abfangen. Der Angreifer wählt und sendet seine eigene Herausforderung ( c ') und wartet auf die Client-Antwort ( h (c' || p)). Beachten Sie, dass der echte Server nicht kontaktiert wird. Der Angreifer trennt die Verbindung unmittelbar nach der Client-Antwort abrupt, um einen harmlosen Netzwerkfehler zu simulieren. In diesem Angriffsmodell hat der Angreifer eine große Verbesserung erzielt: Er hat immer noch eine Herausforderung c ' und die entsprechende Antwort, aber die Herausforderung ist ein Wert, den der Angreifer nach eigenem Ermessen ausgewählt hat. Was der Angreifer tun wird, ist immer die gleiche Herausforderung zu bedienen c '. Wenn der Angreifer jedes Mal dieselbe Herausforderung verwendet, kann er Vorberechnungen durchführen: Er kann vorberechnete Tabellen (d. H. Regenbogentabellen) erstellen, die diese spezielle "Herausforderung" verwenden. Jetzt kann der Angreifer mehrere unterschiedliche Passwörter angreifen, ohne dass die Kosten für die Wörterbuchaufzählung für jedes Passwort anfallen.

A client nonce vermeidet dieses Problem. Das Protokoll wird:

  • server sendet eine zufällige Herausforderung c
  • der Client wählt eine Nonce n (sollte jedes Mal anders sein)
  • client sendet n || h (c || n || p)
  • der Server berechnet h (c || n || p) (unter Verwendung von p aus seiner Datenbank neu und prüft, ob dieser Wert mit dem vom Client gesendeten Wert übereinstimmt

Da der Client für jede Sitzung einen neuen Zufallswert (das "Nonce") in die Eingabe der Hash-Funktion einfügt, ist die Eingabe der Hash-Funktion jedes Mal unterschiedlich, selbst wenn der Angreifer die Herausforderung auswählen kann. Dies besiegt vorberechnete (Rainbow) Tabellen und stellt unsere beabsichtigte Sicherheitsstufe wieder her.

Eine grobe Emulation einer eindeutigen Nonce ist der Benutzername. Zwei unterschiedliche Benutzer innerhalb desselben Systems haben unterschiedliche Namen. Der Benutzer behält jedoch seinen Namen, wenn er sein Passwort ändert. und zwei unterschiedliche Benutzer können auf zwei unterschiedlichen Systemen den gleichen Namen haben (z. B. hat jedes Unix-ähnliche System einen "Root" -Benutzer). Der Benutzername ist also keine gute Nonce (aber es ist immer noch besser, als überhaupt keine Client-Nonce zu haben).

Zusammenfassend geht es beim Client Nonce darum, den Client vor einem Wiederholungsangriff zu schützen (der "Server" ist tatsächlich ein Angreifer, der jedem Client, den er angreifen möchte, dieselbe Herausforderung sendet). Dies ist nicht erforderlich, wenn die Abfrage über einen Kanal ausgeführt wird, der eine starke Serverauthentifizierung (z. B. SSL) enthält. Password Authenticated Key Exchange sind erweiterte Protokolle, die eine gegenseitige kennwortbasierte Authentifizierung zwischen Client und Server gewährleisten, ohne dass eine a priori-Vertrauensstellung (die "Stammzertifikate", wenn ein SSL-Client das SSL-Serverzertifikat authentifiziert) und Schutz erforderlich ist gegen aktive und passive Angreifer (einschließlich des "Cluster-for-Two-Week" -Angriffs auf ein einzelnes Passwort, das ist also strikt besser als das obige Protokoll, nonce oder no nonce).

138
Thomas Pornin

Lassen Sie mich versuchen, auf das Fleisch Ihrer Frage zu antworten: "Angenommen, der Angreifer möchte sich nicht auf einen Man-in-the-Middle-Angriff einlassen und die Authentifizierungsdetails wiederherstellen. Wie bietet ein cnonce zusätzliche Informationen?" Schutz?"

Normalerweise enthält ein Client nicht nur eine Nonce mit der Anfrage, sondern Zeichen die gesamte Anfrage, einschließlich der Nonce. Dies bedeutet, dass selbst wenn der Angreifer eine Nachricht zwischen Client und Server abfängt:

  1. Ein Wiederholungsangriff funktioniert nicht (da der Server die Client-Nonces verfolgt).
  2. Der Angreifer kann nicht einfach eine neue Nachricht mit einer neuen Client-Nonce generieren, da er nicht weiß, wie signieren die neue Nachricht entsprechend (dh es fehlt das Client-Geheimnis oder der private Schlüssel).
7
Bosh

Gemäß RFC 2617 schützen die Parameter cnonce und nc vor ausgewählten Klartextangriffen. Wie schützt dies vor solchen Angriffen?

Wenn Eve die Nonce ändert, die der Server an den Client sendet, was hat Eve gewonnen? Eve kann h(password || nonce) nicht aus h(password || fake_nonce) generieren und theoretisch sollte der Server h(password || fake_nonce) sowieso nicht akzeptieren, da der Server wissen sollte, welche Nonce ausgegeben wird und Was für eine Nonce hat es nicht.

1
paynes_bay

Ich denke, eine gute Idee wäre es, zu lesen, wie der Nonce-Wert in so etwas wie Oauth verwendet wird. Kurz gesagt, wenn eine Anwendung, die OAuth verwendet) eine Anfrage an einen von OAuth unterstützten Serve stellt, muss die Anfrage eine Reihe von Feldern enthalten, von denen zwei Zeitstempel und Nonce sind. Der Zweck des Formulars ist offensichtlich: Es gibt einen Hinweis auf den Zeitrahmen, in dem die Nachricht gesendet wurde, damit der Server besser erraten kann, ob die Nachricht veraltet ist oder nicht. Letzteres besteht offensichtlich aus einer Reihe zufälliger Zeichen/Bytes.

Wenn der gesamte Header OAuth - Header mit dem Consumer-Geheimnis gehasht wird, werden diese beiden Felder eingeschlossen. Anschließend wird die Signatur an die Anforderung angehängt (ob es sich um Abfrageparameter oder HTTP-Header handelt) und weitergeleitet an den Server. Der tatsächliche Text der Anforderung ist nicht gehasht.

Der Server OAuth sollte den vorherigen Satz von N Nonce-Werten für einen bestimmten Client verfolgen, um sicherzustellen, dass sie nicht wiederverwendet werden. Da sich der Nachrichtentext ändern kann (im Wesentlichen mit no) Auswirkung auf den Hash) Es ist wichtig, dass sich etwas anderes ändert (z. B. das Nonce), um sicherzustellen, dass die Anforderungen eindeutig sind. Angesichts der offenen/einfachen Textnatur von HTTP ist dies ziemlich wichtig.

Hilft dies überhaupt, seinen Zweck zu klären? (Ich hoffe :)).

1
OJ.