Wie teile ich Login und Spielelogik beim Schreiben von Servern auf?

Ich baue einen Poker-ähnlichen Spieleserver auf, ich wollte alle Anmeldungen und Spielelogiken auf einem Server verwalten, aber aus meinen Recherchen im Internet habe ich erfahren, dass dies nicht skalierbar ist und es sinnvoll wäre, es zu teilen die Arbeit in einen Login und Spieleserver. Was ich jedoch nicht bekomme, ist, nachdem ich die Authentifizierung auf dem Anmeldeserver durchgeführt und den Client eine neue Verbindung zum Spieleserver hergestellt habe. Woher weiß ich, welcher Client welcher ist? Müsste ich mich nicht erneut anmelden und damit den Zweck eines Servers für die Anmeldung zunichte machen? Gibt es eine Möglichkeit, eine Verbindung zwischen Prozessen und Maschinen herzustellen, von denen ich nichts weiß? Entschuldigen Sie mein kleines Wissen über Networking.

server authentication

— user342580
quelle

YAGNI: Du wirst es nicht brauchen. Implementieren Sie keine vorzeitige Optimierung. Die Anmeldung klingt nach einem sehr trivialen Teil des Spiels. Es ist unwahrscheinlich, dass eine Aufteilung Vorteile bringt. Sobald Ihr Spiel genügend Benutzer hat, die Sie interessieren (Sie sollten in der Lage sein, Tausende von Benutzern auf einem einzelnen Server zu unterstützen, andere nur aus Redundanzgründen), können Sie einige Software-Ingenieure einstellen, die diese Art von Dingen verstehen.

— MarkR

Sie haben eine irreführende Antwort akzeptiert. Sie sollten dies sorgfältig überdenken. Andernfalls haben Sie falsche Vorstellungen im Kopf und ein falsches Sicherheitsgefühl in Ihrem Code.

— o0 '.

Ich mochte Kylotans Antwort, weil ich keine zusätzliche Verbindung zwischen den Spielservern und dem Anmeldeserver haben muss. Ich kann auch Philipps Argument sehen, dass ein Kompromiss des geheimen Schlüssels ein Kompromiss für alle Konten ist, die Fracht sind. Ich werde beide Anmeldeversionen implementieren und einen Sicherheitsexperten fragen, wenn ich meinen Code prüfen lasse. Meine Frage scheint ziemlich einfach zu sein und ich habe erwartet, dass dies eine Standardlösung ist, über die sich alle einig sind. Stelle dir das vor. Wenn nur ein Sicherheitsexperte in diese Diskussion kommen und eine Entscheidung treffen kann.

— user342580

Genau genommen ist das Übergeben des Anmeldetokens zwischen Ihren Servern sicherer, vorausgesetzt, Sie haben einen sicheren Kanal, mit dem Sie dies tun können. Es ist auch schwieriger zu implementieren, was das Risiko erhöht, dass Sie etwas falsch machen. Ein Hash-basiertes Nachrichtenauthentifizierungssystem sollte absolut sicher sein, es sei denn, jemand kann Ihren geheimen Schlüssel erhalten - und wenn er Ihren Schlüssel über den Zugriff auf Ihre internen Systeme erhalten kann, haben Sie Probleme, die durch das Senden des Logins nicht behoben werden können Token manuell.

— Kylotan

Antworten:

Obwohl Philipps Antwort vollkommen gut ist, gibt es einen etwas anderen Weg, der keine Verbindung zwischen dem Anmeldeserver und dem Spieleserver erfordert, was nützlich ist, wenn eine solche Verbindung schwierig ist.

Wenn sich der Benutzer erfolgreich auf dem Anmeldeserver authentifiziert, wird ihm eine Spielserveradresse und ein Anmeldetoken wie oben gesendet. Dieses Token besteht jedoch aus zwei Teilen: der Uhrzeit auf dem Anmeldeserver und einem Hash dieser Nummer sowie dem Benutzernamen, der IP-Adresse, der IP-Adresse oder ID des Spielservers und einem geheimen Schlüssel, den nur Sie kennen.
Der Client versucht, sich beim bereitgestellten Spieleserver anzumelden, indem er dieses Token sendet. Der Server bildet den gleichen Hash wie zuvor, basierend auf den Informationen im Anmeldetoken sowie seiner eigenen IP-Adresse / ID und dem geheimen Schlüssel. Wenn dieser Hash mit dem im Token übereinstimmt, wissen Sie, dass der Player ordnungsgemäß authentifiziert wurde. Überprüfen Sie dann, ob das Datum nicht zu alt ist (z. B. länger als 1 Minute).

Dies funktioniert, weil:

Es kann nicht kopiert und wiederverwendet werden, da das Datum abläuft.
Es kann nicht ohne ein neues Login erstellt werden, ohne den geheimen Schlüssel zu kennen.
Es kann nicht einfach von jemand anderem abgefangen werden (z. B. mit einem Paket-Sniffer) und verwendet werden, da die ursprüngliche IP-Adresse zum Erstellen verwendet wird.
Es kann nicht für ein anderes Konto verwendet werden, da der Benutzername Teil des Hashs ist.
Es kann nicht für gleichzeitige Anmeldungen auf verschiedenen Spielservern verwendet werden, da die ID / IP-Adresse des Servers Teil des Hashs ist.

Einfacher ausgedrückt stellt der Hash sicher, dass es für den Absender nahezu unmöglich ist, sein Anmeldetoken gefälscht zu haben, sodass den Informationen im Token vertraut werden kann.

Verwenden Sie wie bei jedem sicherheitsorientierten Hashing die beste Hash-Funktion, die Sie erhalten können - im Moment scheinen die Leute bcrypt, PBKDF2 und scrypt zu mögen - und stellen Sie sicher, dass Ihr geheimer Schlüssel sehr lang ist, um die Brute-Force-Reproduktion weniger praktisch zu machen.

— Kylotan
quelle

Sehr klug, ich bevorzuge diese Lösung sehr. Meine Frage ist dann der geheime Schlüssel. Sollte es wie eine Passphrase sein oder so? Und sollte es für jeden Benutzer anders sein?

— user342580

Dies funktioniert nicht oder ist tatsächlich eine versteckte Neuimplementierung von @ Philipps Antwort. Es schlägt fehl, da davon ausgegangen wird, dass sowohl der Anmeldeserver als auch der Spieleserver denselben geheimen Schlüssel kennen. Wenn beide den Schlüssel kennen, muss einer den anderen kontaktieren, um ihn bereitzustellen. Oder Sie benötigen einen Dritten, um es an beide zu senden. In jedem Fall ist es so schnüffelig wie zuvor.

— o0 '.

@Lohoris, die Idee ist, dass Sie sowohl den Login als auch den Spieleserver besitzen und ihnen den geheimen Schlüssel zur Verfügung stellen können. Wenn Sie nicht beide Server besaßen, wie könnte der Spieleserver der Authentifizierung des Anmeldeservers überhaupt vertrauen?

— Kylotan

@ user342580: Ich würde eine lange Phrase verwenden. Es muss sich nicht pro Benutzer unterscheiden, aber wenn es so wäre, würde das nicht schaden. Solange die Krypto-Hash-Funktion stark genug ist und Sie sie regelmäßig ändern, sollte dies keine Rolle spielen.

— Kylotan

@Kylotan genau, und wie geben Sie ihnen den Schlüssel? Warum halten Sie die Verbindung von Ihnen zu den Servern für sicherer als die von Server zu Server?

— o0 '.

Nachdem sich der Benutzer beim Anmeldeserver authentifiziert hat, geben Sie ihm ein Token (eine eindeutige, zufällig generierte Zeichenfolge, die zu lang ist, um erraten zu werden).
Der Loginserver wählt einen Gameserver aus. Senden Sie das Token, den Benutzernamen und alle anderen relevanten Daten über den Benutzer vom Anmeldeserver an den ausgewählten Server.
Senden Sie das Token und den Hostnamen des Spieleservers an den Client. Trennen Sie es dann vom Anmeldeserver.
Der Client stellt dann mit seinem Benutzernamen und seinem Token eine Verbindung zum Spieleserver her.
Wenn das Token vom Client mit dem gerade vom Anmeldeserver gemeldeten übereinstimmt, akzeptieren Sie es.

Beachten Sie, dass die Token aus einem kryptografisch sicheren Zufallszahlengenerator erstellt werden müssen, damit dies sicher ist. Jedes Token kann vom Spieleserver nur einmal akzeptiert werden und nicht verwendete Token sollten nach einigen Minuten verworfen werden.

— Philipp
quelle

Würde die Verwendung von bcrypt ausreichen? Ich denke darüber nach, ein Token aus dem Hash der Zeit + Benutzername + Passwort mit bcrypt zu erstellen.

— user342580

Ich denke es würde. Man könnte ein Token erraten, wenn man das Passwort kennt, aber wenn man das Passwort kennt, kann man sich einfach auf normale Weise anmelden.

— Philipp

bcrypt funktioniert so lange, wie die Eingabe angemessen zufällig und nicht aussagekräftig ist. Wenn Sie nur die Zeit verwenden, kann der Angreifer versuchen, die Zeit vorherzusagen, dann bcrypt ausführen und das Token abrufen. Stellen Sie sicher, dass Sie ein geheimes Salt mit der Zeit oder einen sicheren Randomizer verwenden (z. B. / dev / random auf UNIX / Linux-Systemen).

— Sean Middleditch

Das Passwort wurde möglicherweise auf einer anderen Site kompromittiert, daher würde ich vermeiden, anzunehmen, dass es ein geeignetes Geheimnis ist.

— Sean Middleditch

@ SeanMiddleditch Wenn das Passwort kompromittiert wird, geht die gesamte Sicherheit trotzdem verloren. Ein Angreifer, der das Passwort erhalten hat, hat keinen Grund, ein Token zu erraten, da er nur eines erhalten könnte, indem er sich auf normale Weise anmeldet.

— Philipp