Ich habe mir für eine tcp commando schnittstelle einen einfachen thread per connection server geschrieben der wie folgt functionert (funktionieren soll). das ganze baut auf minimalem code und maximal WinApi auf.

*client generiert hash
*client TCP -> sendet hash an -> server
*hash wird validiert und in liste eingetragen
*server -> sended ok -> client
*client -> kann jetzt alle commands senden und bekommt auch was vom server zurück

ok soweit sogut, funktioniert alles aus dem hash generator und der validierung.

meine frage(n) also:
*ist das überhaupt möglich?
*welcher hash generator(validator),kame dafür infrage?
*gibts noch eine leichtere schnellere möglichkeit (muss nicht super secure sein)?

achso, ich suche einen OpenSource, wenns geht sehr simplen, kleinen, muss nicht das neueste in cryptographieforschung sein hash generator/validierer. Ich habe mich schoneinmal mit der WinApi crypto rumgeschlagen, das wäre aber mein letzter ausweg.

Ich hoffe ihr verzeiht und versteht das ich keine Lust, Ahnung und Zeit für Grundsatzdiskussionen von security und server techniken gebrauchen kann.

danke vorerst

Ich hoffe ihr verzeiht und versteht das ich keine Lust, Ahnung und Zeit für Grundsatzdiskussionen von security und server techniken gebrauchen kann.

Mallory liest Hash von Alice mit.
[...später am Abend...]
Mallory sendet Hash an Server.
Server validiert Mallory als Alice.
Server sendet OK an Mallory.
Mallory kann jetzt alle Kommandos von Alice schicken...

Vielleicht hättest Du Dir sparen sollen, das Protokoll zu beschreiben...

ich hätte nur gern eine methode gefunden ohne große ssl implementierung einen handshake mit md5/rsa/etc.. hashes zu finden, wobei bei server und client gerne auch ein hardcodeter string der dann in einen hash umgewandelt wird sein darf.

aber danke für deinen hilfreichen kommentar

Wenn Du mit dem Hash erreichen willst, daß ein Angreifer das Passwort nicht mitlesen kann, dann hast Du einen Denkfehler. Dem Angreifer ist das Passwort selbst nämlich egal. Er will nur wissen, was er an den Server schicken muß, um sich zu authentifizieren. Wenn er nur den Hash-Wert des Passworts kenn, sich aber damit beim Server anmelden kann, ist der Hash-Wert so gut wie das Passwort selbst. Dann kannst Du auch gleich das schicken. Auch dem "dummy" User ist es egal, ob er das Passwort bekommt oder irgendetwas anderes. Du hast mit dem Hash einfach gar nichts gewonnen.

Eine kleine Erweiterung des Protokolls macht die Sache sicher. Wenn der Server eine Zufallszahl schickt und der Client die md5-Summe aus Passwort und der Zufallszahl schickt, ist die Authentifizierung sicher. Wenn der "dummy"-User, wie Du Deinen Angreifer nennst dann das Protokoll mit liest, hilft ihm das nichts, da der Server jedes mal eine andere Zufallszahl schicken kann. Diese Zufallszahl muß noch nicht mal sicher sein. Du kannst einfach eine laufende Nummer oder die aktuelle Uhrzeit schicken. Hauptsache Du schickst jedes mal etwas anderes.

du hattest recht, da war ein logischer fehler. ich dachte vorerst an sowas, aber meinte es würde mit einem kommunikationsschritt auch getan sein.
das hilft mir schon ziemlich weiter. ich werde mich bei erfolg melden!

Der Ansatz ist ein klassisches Beispiel für eine man-in-the-middle Attacke und bringt auch keine Sicherheit.

Alice: Client
Bob: Server
Mallory: Angreifer

Mallory gibt sich für Alice als Bob und für Bob als Alice aus.
Alice sendet eine Anfrage an falschen Bob (= Mallory).
Falsche Alice (= Mallory) sendet eine Anfrage an Bob und sendet die "Challenge" an Alice.
Alice beantwortet Mallory die Challenge und Mallory sagt Alice "Out-of-service".
Mallory benutzt gelöste Challenge als Authentifizierung bei Bob.

Aber wir kommen der Lösung schon näher...

Wie wäre es hiermit:

1.) Alice sendet Bob eine Challenge und verschlüsselt diese mit dem öffentlichen Schlüssel von Bob.
2.) Bob entschlüsselt die Nachricht mit seinem privaten Schlüssel und verschlüsselt den Klartext (d.h. die Challenge) mit dem öffentlichen Schlüssel von Alice.
3.) Alice entschlüsselt die Challenge mit ihrem privaten Schlüssel.

Die Challenge darf hierbei nicht vorhersagbar sein.