Diskussion:Replay-Angriff

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 1 Jahr von Matthäus Wander in Abschnitt Challenge-Response-Verfahren
Zur Navigation springen Zur Suche springen

Wäre Replay-Angriff nicht ein besseres Lemma? --ChristianErtl 18:48, 27. Jun 2006 (CEST)

Ja, Attacke ist eine missglückte Übersetzung des englischen attack. --Matthäus Wander 12:04, 19. Apr. 2008 (CEST)

Challenge-Response-Verfahren

[Quelltext bearbeiten]

shake: "schickt Bob aber ein anderes Nonce" ... Entspricht das nicht einer "Challenge" in einem Challenge-Response-Verfahren, bzw. wäre hier nicht der Verweis auf Challenge-Response angebracht(er) ? (nicht signierter Beitrag von 194.145.146.129 (Diskussion) 16. September 2010, 17:03 Uhr)

erledigt. --Matthäus Wander Diskussion:Replay-Angriff#c-Matthäus Wander-20230806161500-Challenge-Response-Verfahren11Beantworten

Weitere Möglichkeit zum Verhindern von Replay-Angriffen?

[Quelltext bearbeiten]

Wären gesicherte Verbindungen nicht auch eine Methode sich vor Replay-Angriffen zu schützen?

--80.140.227.133 Diskussion:Replay-Angriff#c-80.140.227.133-2013-07-11T13:27:00.000Z-Weitere Möglichkeit zum Verhindern von Replay-Angriffen?11Beantworten

Gesichert kann vieles und nichts bedeuten. Wenn du damit so etwas wie SSL/TLS meinst: TLS verwendet zwei Nonces beim Verbindungsaufbau, um vor Replay-Angriffen Schutz zu bieten. Gesicherte Verbindungen sind keine Methoden, sondern es werden Methoden und Verfahren eingesetzt, um Verbindungen zu sichern. --Matthäus Wander (Diskussion) Diskussion:Replay-Angriff#c-Matthäus Wander-2013-07-11T15:20:00.000Z-80.140.227.133-2013-07-11T13:27:00.000Z11Beantworten
Ach so, dann könnte man ja TLS bei den Nonces erwähnen, oder? Ich habe das nicht direkt mit TLS in Verbindung bringen können.

--80.140.227.133 Diskussion:Replay-Angriff#c-80.140.227.133-2013-07-11T21:40:00.000Z-Weitere Möglichkeit zum Verhindern von Replay-Angriffen?11Beantworten

Ja, gute Idee. In der TLS-Spezifikation heißen diese übrigens nicht Nonce, sondern client random und server random, entsprechen aber einer Nonce. --Matthäus Wander (Diskussion) Diskussion:Replay-Angriff#c-Matthäus Wander-2013-07-11T22:04:00.000Z-80.140.227.133-2013-07-11T21:40:00.000Z11Beantworten
Ergänzung: Es gibt noch eine dritte Nonce (Pre-Master-Secret) [1], von der hauptsächlich die Sicherheit abhängt. Client random und Server random spielen eine untergeordnete Rolle. --Matthäus Wander (Diskussion) Diskussion:Replay-Angriff#c-Matthäus Wander-2013-08-11T01:14:00.000Z-Matthäus Wander-2013-07-11T22:04:00.000Z11Beantworten

Wie soll das gehen??

[Quelltext bearbeiten]

Das muss mir jetzt mal jemand erklären: Bei SSL kennt Bob das geheime PW von Alice doch gar nicht! Weshalb wird dann: 1. Überhaupt ein Nonce verwendet? 2. Das Nonce nicht mit dem Public Key verschlüsselt übertragen? So wie der Artikel dasteht ist jedenfalls nicht klar wie das nun mit der Public-private-key-Kryptographie zusammenhängen soll. 178.197.227.80 Diskussion:Replay-Angriff#c-178.197.227.80-2013-08-10T21:43:00.000Z-Wie soll das gehen??11Beantworten

Beachte bitte, dass das Beispiel nicht SSL/TLS erklärt.
Zu 1: Eine Nonce soll bei TLS MITM-Angriffe und Replay-Angriffe verhindern.
Zu 2: Genau so wird die Nonce (Pre-Master-Secret) übertragen: verschlüsselt mit dem Public Key des Servers. --Matthäus Wander (Diskussion) Diskussion:Replay-Angriff#c-Matthäus Wander-2013-08-11T01:10:00.000Z-178.197.227.80-2013-08-10T21:43:00.000Z11Beantworten