Exception at 0x696b7982 Geschrieben 23. Juni 2004 Geschrieben 23. Juni 2004 Hi Leuz. Hab folgende Hausaufgabe von meiner Schule bekommen. Entwerfen Sie eine Anwendung, die eine Online-Anmeldung zu einem Schachturnier ermöglicht. Interessenten müssen jedoch durch eine anerkannte Zertifizierungsstelle authentifiziert werden, bevor sie sich anmelden können. Da es sich um ein öffentliches Turnier handelt, ist eine Verschlüsselung der Informationen nicht notwendig. Beschreiben Sie abstrakt den Ablauf der Anmeldung. Jemand Vorschläge? Danke! :OD
Exception at 0x696b7982 Geschrieben 30. Juni 2004 Autor Geschrieben 30. Juni 2004 Keiner einen Vorschlag?
CyberMaus Geschrieben 30. Juni 2004 Geschrieben 30. Juni 2004 Keiner einen Vorschlag? Ähm, naja, sollen andere deine Hausaufgaben machen? Hast du nicht mal selber eine Idee, einen Ansatz, den wir dann vielleicht verbessern, modifizieren können??
etreu Geschrieben 30. Juni 2004 Geschrieben 30. Juni 2004 Das schreit ja förmlich nach einem PAP o.ä.!
Exception at 0x696b7982 Geschrieben 30. Juni 2004 Autor Geschrieben 30. Juni 2004 Hatte es damals schon mal mit SSL gemacht: Ablauf eines Aufbaus einer Sicheren Verbindung (anhand einer SSL Sitzung): - der Client sendet dem Server die unterstützte SSL-Versionsnummer, Informationen über seine Verschlüsselungsmöglichkeiten (z.B. maximale Schlüssellängen, unterstützte Algorithmen) und Zufallsdaten für die Erzeugung des Sitzungsschlüssels - der Server sendet dem Client ebenfalls die unterstützte SSL-Versionsnummer, Informationen über seine Verschlüsselungsmöglichkeiten (z.B. maximale Schlüssellängen, unterstützte Algorithmen) und Zufallsdaten für die Erzeugung des Sitzungsschlüssels zurück. Danach sendet der Server sein eigenes Serverzertifikat an den Client und fragt gegebenenfalls nach einem Clientzertifikat, wenn dies für den gewünschten URL erforderlich ist - mit Hilfe des Serverzertifikats versucht der Client den Server zu authentisieren und gibt eine Warnmeldung aus, wenn ihm dies nicht gelingt - nun erzeugt der Client zufällige, geheime Daten (premaster secret) und verschlüsselt diese Daten mit dem öffentlichen Schlüssel des Servers unter Verwendung des mit dem Server vereinbarten Verschlüsselungsalgorithmus. Das so verschlüsselte premaster secret sendet er zum Server - in einer Variante dieses Vorgehens generieren der Client und Server mit Hilfe des Diffie-Hellman-Algorithmus gemeinsam ein premaster secret, das nur ihnen bekannt ist. Dies hat den Vorteil, dass, selbst wenn der private Schlüssel des Servers aus irgendeinem Grunde bekannt wird, eine vorher abgehörte SSL-Kommunikation immer noch nicht entschlüsselt werden kann (forward secrecy) - der Server verwendet seinen privaten Schlüssel, um die übertragenen Daten zu entschlüsseln. Danach führt der Server eine definierte Abfolge von Schritten aus, um aus den Daten einen neuen Satz geheimer Daten (master secret) zu generieren - der Client, der die Daten ja selber generiert hat, führt die gleichen Schritte wie der Server aus und kommt unabhängig von ihm zu einem identischen Satz geheimer Daten (master secret) - beide Seiten erzeugen aus diesen Daten nun den symmetrischen Sitzungsschlüssel, der für die Verschlüsselung der weiteren Kommunikation verwendet wird - der Client teilt dem Server mit, dass alle weitere Kommunikation mit dem Sitzungsschlüssel verschlüsselt sein wird. Danach sendet er eine bereits verschlüsselte Meldung, dass der Handshake für ihn beendet ist - der Server sendet analog zum Client eine Bestätigung zurück - die SSL-Sitzung ist nun gestartet, und sowohl der Client als auch der Server verwenden den ausgehandelten Sitzungsschlüssel zum Ver- und Entschlüsseln aller Nachrichten und um zu prüfen, ob die Daten auf dem Wege zwischen ihnen verändert wurden - die Authentisierung des Clients erfolgt dann auf der Anwendungsebene, z.B. über einen Anmelde-Dialog, bei dem der Benutzer am anderen Ende der Verbindung aufgefordert wird, sein Passwort einzugeben - Um SSL auf einem Server betreiben zu können, muss für diesen ein Zertifikat erstellt, das zur Authentisierung des Servers gegenüber dem Client dient - Angreifern haben zwar weniger Zeit für einen Brute-Force-Angriff, aber die Möglichkeit besteht trotzdem, SSL ist langsam - es gibt sogar einen Beitrag über die „7 Gefahren von SSL“ bestehend aus: 1. Efficiency versus Security 2. Keys in the Clear 3. Recovering Recorded Sessions 4. Bad Server Credentials 5. Poor Certificate Validation 6. Poor Entropy 7. Insecure Cryptography Aber auf einmal wollen die das ohne Verschlüsselung.
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde Dich hier an.
Jetzt anmelden