spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

@Nephtyz:
Angeregt von Deinem Artikel hab ich über das Problem auch bei mir nachgedacht und muss sagen, dass die Lösung mMn nicht so einfach ist, ohne dass man Gefahr läuft, dass sich Benutzer als andere Benutzer ausgeben. Immerhin hab ich den Vorteil, dass meine Anwendung Server-basiert ist, d.h. jede Aktion auf dem Server berechnet wird, geprüft werden kann und dabei eine Authentifizierung anhand der Credentials/SessionID durchführen kann. Wenn sich aber jemand durch Man-In-the-Middle oder Network-Sniffing die Daten abfängt, kann er immer auch sich als der Benutzer ausgeben. Es sei denn ich fang jetzt mit SSL und Public-/Privatkeys an. Das Sessionobjekt könnte seine SessionID von Anfrage zu Anfrage auf Zufallsbasis modifizieren. Evtl. hilft das dann, dass ein "Eindringling" max. 1 Aktion als der andere Benutzer auführen kann.

Bei deiner P2P-Anwendung muss ich ja auch nur den Benutzer kennen und dann im lokalen Speicher die Stelle des Datenbereichs der Anwendung wo der Benutzer abgelegt ist überschreiben und schon bin ich ein anderer. Ich nehme mal an dass du Strings verwendest, um den Benutzer zu speichern, da könnte ich mir vorstellen, dass das evtl. gar nicht schwierig rauszubekommen ist. Die Bindung der Session an einen Socket mag da helfen.

Letzten Endes ist das alles Kokollores, wenn die Benutzer nicht sorgfältig mit Ihrer e-Mail, ihrem Passwort und Benutzernamen umgehen.

Im Endeffekt musst du auch abwägen, wieviel Aufwand sich lohnt bzw. wie groß der Schaden ist. Als hier in diesem Forum die Frage aufkam, wie man Ingamekäufe auch Offline sicher umsetzen könnte, ist der mögliche Schaden schnell in Euro bezifferbar.

Und du wirst in diesem Fall wenig Handhabe gegen einen sicherheitstechnisch amoklaufenden Benutzer haben. Da kannst du nur noch dafür sorgen, dass dadurch nicht andere Benutzer in Mitleidenschaft gezogen werden.

@Thoran:
Natürlich kannst du eine gewisse Sicherheit nur erlangen wenn du deine Verbindung verschlüsselst. Du musst einfach immer irgendwo Daten zwischen Server und Client austauschen die du dann weiter für die Sicherheit benutzen möchtest. Wenn ein Angreifer diese Daten abfängt hast du keine Chance. Benötigte Daten müssen also auf einem gesicherten Kanal übertragen werden. Da gibe es genügend Möglichkeiten. Dazu lohnt es sich sicherlich einfach mal einen Blick in Uniskripte zum Thema Netzwerke und Netzwerksicherheit zu werfen. Dazu sollte es auch vernünftige Bücher geben. Wenn dich das Thema genauer interessiert kann ich mal bei uns durch die Skripte gucken ob ich gute Lektüre finde.

Auch Verschlüsselungen reichen da nicht.
Ich habe erst diese Woche Videos von meinem alten Lineage 2 Bot hochgeladen, der sich als Man-in-the-middle zwischen Spiel und Server klinkt, alle eingehenden Pakete entschlüsselt, manche verwirft, eigene injected und wieder verschlüsselt verschickt. In beide Richtungen. Es sind dabei 4 verschiedene Verschlüsselungen für verschiedene Gebiete eingesetzt und von mir letztlich doch gebrochen worden:
1) Login- & Server-Auswahl-Kommunikation
2) Login-Daten wie Name+PW
3) Spiel-Pakete
4) Spiel-Paket-Typ
Sicher ist eigentlich gar nichts, wenn sich der Man-in-the-middle für beide Seiten als authentisch ausgeben kann.

Ich denke das mit der Verschlüsselung ist keine Frage der Implementierung, sondern an sich schon ein Denkfehler. Verschlüsselung ist gut wenn du zwei Enden hast, die sicher miteinander kommunizieren wollen. Dann gibt es auch Methoden die eine Man-in-the-Middle Attack wirklich schwierig machen.

Bei so Themen wo ein Spieler mit Absicht einen Bot einbringen will, hat ein Ende, der Client, gar nicht das Verlangen in diesem Sinne sicher sein. Im Extremfall zieh ich mir, wie auch immer, die Schlüssel aus der laufenden Session des regulären Clients und geb sie meinem Bot. Der entsprechende Botter hat Zugriff dadrauf. Abhilfe schaffen da wenn Techniken wie sie bei TCPA angedacht waren.

Von daher, wenn man sicher sein will, muss man was auch immer zum Server verbindet als potenziell kompromittiert ansehen. Das klingt paranoid, aber die Situation ist nicht die gleiche wie wenn man ne Email verschicken will.