Frage:
Was nützt ein Client Nonce?
user700503
2011-04-10 07:56:56 UTC
view on stackexchange narkive permalink

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 in seinem Buch nie und ich habe Schwierigkeiten, den Zweck der Benutzerauthentifizierung zu verstehen.

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. Daher ist beides bedeutungslos.
  • 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.

Was ist also 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 für diesen Teil gefunden.

BEARBEITEN Einige Antworten haben schlug vor, dass der Kunde eine Nonce bereitstellen kann und sie dem gleichen Zweck dient. Dies bricht jedoch das Challenge-Response-Modell. Welche Auswirkungen hat dies?

Vier antworten:
#1
+141
Thomas Pornin
2011-04-11 18:03:24 UTC
view on stackexchange narkive permalink

Ein 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 den sehr großen Begriff "Wiedergabe" fallen.

Betrachten Sie beispielsweise ein passwortbasiertes Authentifizierungsprotokoll, das folgendermaßen aussieht:

  • Der Server sendet eine "Herausforderung" (einen vermeintlich zufälligen Wert c ) an die 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 sieht wenn es 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 möchten.

Stellen Sie sich einen passiven Angreifer vor: Der Angreifer lauscht, ändert aber nicht die Nachrichten. Er sieht c und h (c || p) , sodass er in seinem Cluster potenzielle Kennwörter aufzählen kann, bis eine Übereinstimmung gefunden wird. Das wird für ihn teuer. Wenn der Angreifer zwei Passwörter angreifen möchte, muss er die Aufgabe zweimal ausführen. Der Angreifer möchte eine gewisse Kostenteilung zwischen den beiden Angriffsinstanzen mithilfe von vorberechneten Tabellen ("Regenbogentabellen" sind nur eine Art vorberechnete Tabelle mit optimiertem Speicher; Um eine Regenbogentabelle zu erstellen, muss jedoch immer noch das gesamte Wörterbuch aufgelistet und jedes Kennwort gehasht werden. 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 Regenbogentabellen.

Angenommen, der Angreifer wird aktiv. Anstatt die Nachrichten einfach zu beobachten, wird er Nachrichten aktiv ändern, einige löschen, andere duplizieren oder eigene Nachrichten einfügen. 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 Kennwörter angreifen, ohne dass die Kosten für die Wörterbuchaufzählung für jedes Kennwort anfallen.

Eine Client-Nonce vermeidet dieses Problem. Das Protokoll lautet:

  • Server sendet eine zufällige Aufforderung c
  • Client wählt eine Nonce n (sollte unterschiedlich sein jedes Mal)
  • Client sendet n || h (c || n || p)
  • Server berechnet h (c || n || p) neu (unter Verwendung von p aus seiner Datenbank) und prüft, ob dieser Wert mit dem übereinstimmt, was der Client gesendet hat.
  • Da der Client für jede Sitzung einen neuen Zufallswert (das "Nonce") in die Eingabe der Hash-Funktion einfügt, wird der Die Eingabe der Hash-Funktion ist jedes Mal unterschiedlich, auch wenn der Angreifer die Herausforderung auswählen kann. Dies besiegt vorberechnete (Regenbogen-) 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 verschiedene Benutzer können auf zwei verschiedenen Systemen den gleichen Namen haben (z. B. hat jedes Unix-ähnliche System einen "Root" -Nutzer). Der Benutzername ist also keine gute Nonce (aber es ist immer noch besser, als überhaupt keine Client-Nonce zu haben).

    Zusammenfassend geht es bei der Client-Nonce darum, den Client vor einem Wiederholungsangriff zu schützen (die " Server "in der Tat ein Angreifer, der jedem Client, den er angreifen möchte, die gleiche 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).

    Beeindruckend. Vielen Dank! Ich wünschte, ich könnte das noch einmal abstimmen.
    Bei der Digest-Authentifizierung sendet der Server eine Nonce und der Client sendet dieselbe Nonce zurück. Mir scheint, dass eine Client-Nonce nur dann wirklich nützlich ist, wenn der Server das nimmt, was der Client sagt, ist die Nonce zum Nennwert und nicht das, was der Server selbst generiert hat? Wenn die HTTP-Verbindung am Leben war, scheint es mir, dass der Server wissen könnte, was die gerade gesendete Nonce war.
    @paynes_bay Statuslosigkeit ist häufig eine wünschenswerte Eigenschaft bei der Verwendung von HTTP, insbesondere aus Gründen der Skalierbarkeit und Hochverfügbarkeit. Wenn Sie die Nonce nicht an den Server zurücksenden, wird die Digest-Authentifizierung angezeigt.
    Aus Neugier - ist es eine wichtige Komponente der Client-Nonce, dass der Server jede so verfolgt und aufzeichnet, dass die Authentifizierung abgelehnt wird, wenn eine Client-Nonce ebenfalls wiederverwendet wird?
    Nur um es klar zu machen: Client Nonce ist besonders für den Fall gedacht, dass der Angreifer der Server ist, oder?Selbst wenn ich mich über einen sicheren Kanal befinde, leitet jemand / Abfangjäger die Anforderung einfach erneut (Weitergabe) weiter, ohne sie entschlüsseln zu müssen.Für solche Angriffe verwenden wir jedoch andere Mechanismen, z. B. einen Anforderungszähler (per nonce) und dergleichen.
    #2
    +7
    Bosh
    2011-04-10 11:12:22 UTC
    view on stackexchange narkive permalink

    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 funktioniert a cnonce bietet zusätzlichen Schutz? "

    Normalerweise enthält ein Client nicht nur eine Nonce mit der Anforderung, sondern signiert die gesamte Anforderung, 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 einem neuen Client-Nonce generieren, da er nicht weiß, wie er die neue Nachricht signieren entsprechend signieren soll (dh ihm fehlt die Client-Geheimnis oder privater Schlüssel).
    3. ol>
    Bricht ein vom Kunden produzierter Nonce nicht das Challenge-Response-Modell? Welchen Effekt hat das? Ein Anruf kann bestätigen, dass die Nachricht noch nicht gesehen wurde, aber nicht, dass sie frisch ist. Mit anderen Worten, es öffnet das System für Timing-Angriffe, bei denen ein Angreifer die Antwort des Clients abfängt, den Dienst verweigert und die Antwort wiederverwendet.
    Der Client kann eine Ablaufzeit angeben. Wenn der Server die Nachricht nach dem in der (signierten) Nachricht enthaltenen Ablauf empfängt, behandelt er die Nachricht genauso, als ob die Signatur ungültig wäre.
    @Justice Dies führt zu Problemen bei der Synchronisierungszeit und so weiter. Woher weiß der Server, wie spät es auf dem Client ist? Dies wäre leicht zu fälschen.
    Ein Fälscher kann eine Ablaufzeit nicht fälschen, da die Ablaufzeit Teil der zu signierenden Nachricht ist. In HTTP ist keine Uhrensynchronisation erforderlich, da der Client immer Uhrzeiten vom Server erhält. Während der Client die Dauer basierend auf der Messung seiner eigenen Uhr berechnen kann, addiert er diese Dauer immer zur Uhrzeit vom Server, um eine andere Uhrzeit zu erhalten.
    @Justice Ich habe gerade festgestellt, dass die Verwendung der Serverzeit und deren Änderung nach Clientzeit wirklich nur eine andere Möglichkeit ist, eine Server-Nonce zu implementieren. Tatsächlich bedeutet die Verwendung von Zeit auf diese Weise einfach nur die Verwendung einer Server-Nonce.
    Ich denke, "Signieren" bezieht sich hier auf eine Art Echtheitsstempel (wie ein HMAC oder etw).
    #3
    +1
    OJ
    2011-04-10 08:50:24 UTC
    view on stackexchange narkive permalink

    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 Anforderung an einen von OAuth unterstützten Serve sendet, muss die Anforderung eine Reihe von Feldern enthalten, von denen zwei Zeitstempel und Nonce sind. Der Zweck des Formulars liegt auf der Hand: Es gibt einen Hinweis auf den Zeitraum, in dem die Nachricht gesendet wurde, damit der Server besser erraten kann, ob die Nachricht veraltet ist oder nicht. Letzteres ist offensichtlich eine Reihe von zufälligen Zeichen / Bytes.

    Wenn der gesamte OAuth-Header mit dem Verbrauchergeheimnis gehasht wird, sind beide Felder enthalten. Anschließend wird die Signatur an die Anforderung angehängt (ob es sich um Abfrageparameter oder HTTP-Header handelt) und an den Server weitergeleitet. Der tatsächliche body der Anforderung ist nicht gehasht.

    Der OAuth-Server sollte den vorherigen Satz von N Nonce-Werten für einen bestimmten Client verfolgen Stellen Sie sicher, dass sie nicht wiederverwendet werden. Angesichts der Tatsache, dass sich der Nachrichtentext ändern kann (was im Wesentlichen keine Auswirkungen auf den Hash hat), ist es 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, den Zweck überhaupt zu klären? (hoffe es :)).

    Bricht OAuth nicht das Challenge-Response-Modell, indem der Verbraucher das Nonce erstellt? Ist das nicht schlecht? Ein Benutzer kann nicht bestätigen, dass die Nachricht noch nicht gesehen wurde, aber nicht, dass sie frisch ist. Mit anderen Worten, es öffnet das System für Timing-Angriffe, bei denen ein Angreifer die Antwort des Clients abfängt, den Dienst verweigert und die Antwort wiederverwendet.
    #4
    +1
    paynes_bay
    2011-07-11 04:33:00 UTC
    view on stackexchange narkive permalink

    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 (Passwort || nonce) nicht aus h (Passwort || fake_nonce) generieren und theoretisch scheint es, dass der Server h nicht akzeptieren sollte (Passwort || fake_nonce) sowieso, da der Server wissen sollte, welche Nonce ausgegeben wird und welche Nonce es nicht hat.

    Wenn Sie eine Frage stellen, sollte diese wahrscheinlich in einer separaten Frage und nicht in einer Antwort hier stehen.
    Es ist so ziemlich die gleiche Frage, die hier gestellt wird. Ich möchte wissen, was die Verwendung eines Client Nonce ist. RFC2617 liefert eine Antwort, aber diese Antwort macht für mich nicht viel Sinn. Thomas Pornin gab ebenfalls eine Antwort, aber seine Antwort macht für mich auch nach meiner Antwort auf seine Antwort keinen Sinn.
    @paynes_bay Willkommen auf der Seite! Bitte lesen Sie die [FAQ] - Antworten sind für die * Beantwortung * der Frage. Wenn Sie nach einer Klärung einer anderen Antwort suchen, funktionieren Kommentare. Wenn Sie zusätzliche Informationen wünschen, die nicht in der ursprünglichen Frage enthalten sind, fragen Sie einen anderen!


    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...