Zum Inhalt springen

Empfohlene Beiträge

Geschrieben

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

Geschrieben
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?? :rolleyes:

Geschrieben

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.

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 erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...