Clanintern Clanintern Clanintern

Forum

Öffentliche Foren
ZURÜCK
FORUM: Spiele & Computer THEMA: Authentifikation - das Rad neu erfinden?
AUTOR BEITRAG
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#1 - 30.03 23:57

Hoi Ihr.

Um mal mein Kalenderprojekt anzufangen, will ich demnächst mal versuchen, nen rudimentären RPC zu realisieren. Nachdem der Client natürlich nicht beliebig auf dem Server rumhantieren darf sondern eine Zugriffsberechtigung auf Benutzerebene stattfinden soll, bin ich am überlegen, wie ich sicherstellen kann, dass der Server der Server und der Client der Client ist.

Kurz für nicht eingeweihte: RPC = Remote Procedure Call. Soll in etwa folgendermaßen ablaufen:
1. Client schickt ne HTTP-Anfrage mit n paar bestimmten Werten im Header an den Server
2. Server führt ne bestimmte Anwendung aus und schickt die Antwort an den Client zurück

Der Server ist in meinem Fall ein PHP-Script, der Client auch.
Normalerweise würde ein solches Vorhaben mittels SSL realisiert, der Benutzer kann dann selbst entscheiden, ob er dem SSL-Zertifikat vertraut oder nicht.
Mein Client-PHP-Script (fsockopen) dagegen wird wohl bestenfalls prüfen, ob das SSL-Zertifikat auf die richtige Domain ausgestellt ist und noch nicht abgelaufen. Ob es von einer vertrauenswürdigen Quelle unterschrieben ist, kann fsockopen sicherlich nicht wissen. Aus diesem Grund ist eigentlich ein abgelaufenes Zertifikat oder ein Zertifikat auf die falsche Domain auch unerheblich.

Zwischenergebnis: SSL zur Verschlüsselung tauglich, zur Authentifikation nicht.

Wie stellt mein Client jetzt sicher, dass der Server der Server ist und der Server dass der Client der Client ist, ohne Klartextpasswörter über die Leitung zu schicken?


Kurze Idee zu Klartextpasswörtern und einem Angriff:

Client zu Server: "Hi, ich Client. Passwort xyz"
Server prüft Passwort => Ja oder nein.

Wenn mir jetzt jemand DNS-Spoofing betreibt, sagt mein Client dem Angreifer das Klartextpasswort. Dass die Verbindung SSL-gesichert ist (im Angriffsfall per DNS-Spoofing dann die Verbindung zwischen Client und Angreifer) spielt in dem Fall absolut keine sicherheitsrelevante Rolle. Genauso wenig ist entscheidend, ob der Server wie im Web üblich einen md5 des Client-Passworts speichert oder den Klartext, weil das Übel ja schon eintritt, wenn der Server noch von nichts ne Ahnung hat.


Jetzt meine Idee:

Anfrage und Antwort haben ein bestimmtes Format. Das Passwort wird an eine solche Anfrage ankonkateniert, ein md5 drüber und dieser Wert mit der Anfrage zusammen verschickt.
Damit irgend was nicht mehrfach über die Leitung geht (Mittelsmann könnte eine bereits als gültig gesendete Anfrage wiederholt senden) geht eine TAN mit.

Codebeispiel:
code:

$anfrage = array(
  $benutzername,
  $session_id,
  $tan,
  $parameterliste
);
$gesendet_wird = array(
  $anfrage,
  md5($anfrage.$passwort)
);


Bei der ersten Anfrage wäre $session_id=0, $tan=0 und die $parameterliste würde nur eine $tanliste enthalten.
Der Server würde mit der $session_id antworten und seinerseits eine $tanliste mitschicken.

Der Server würde ebenfalls mit
code:

$antwort = array(
  $session_id,
  $tan,
  $antwortwert
);
$gesendet_wird = array(
  $antwort,
  md5($passwort.$antwort);
);



Verschlüsselung wäre durch Man-in-the-middle zwar immer noch nicht hinreichend gelöst, da SSL wie schon geschrieben hier nicht hilft, aber Authentizität ist zumindest schon mal gegeben.


Einwände/Vorschläge/sonstwas?


Kurzzeitig hab ich mir überlegt, sowas sowas wie nen Elgamal oder RSA nachzuprogrammieren, aber das dürfte die Performance gegen 0 gehen lassen, in einem PHP-Script.


Ein Teilziel hiervon ist, auch auf Hosting-Webspace betrieben werden zu können. Die Installation von PHP-Erweiterungen oder gar Consolenanwendungen zur Verschlüsselung fällt also flach.
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#2 - 31.03 23:23

Öhm ja ... die Frage hat sich eigentlich weitgehend erledigt. Wenn ich nen Blockchiffre aus Gedanken an DES mit MD5 baue, hab ich zumindest ne symmetrische Verschlüsselung in halbwegs akzeptabler Zeit.

http://alive.no-ip.com/cryption/cryption.php
http://alive.no-ip.com/cryption/cryption.phps


[edit]


Hmm, hab grad versucht, nen RSA nachzuprogrammieren. Dank den bcmth-Funktionen kein großer Aufwand für mich als Codeschreiber. Die Funktion, die ein Schlüsselpaar erzeugt ist knappe 100 Zeilen lang, einen Klartext zu verschlüsseln, zu entschlüsseln und per echo auszugeben ist n Einzeiler mit weniger als 50 Zeichen.

Lediglich der Rechenzeitbedarf ist absolut untragbar. An einen Schlüssel aus etwa 300 Dezimalziffern (bei 3.5 Bit pro Ziffer also knappe 1000 Bit) hatte ich schon gedacht, allerdings ist grade mal ein Schüssel aus fünf Dezimalziffern bisher bei rum gekommen. Schon ein Schlüssel aus acht Ziffern rechnet momentan 15 Minuten.
Mal n bissl am Prinzahlentest schrauben, vielleicht geht da ja noch was.
ZURÜCK