Insbesondere in Bezug auf den letzten Punkt Ihrer Frage: Nein, ein unsicheres Authentifizierungssystem kann niemals vergeblich sein. Benutzer werden selten in Bezug auf die Computersicherheit aufgeklärt. Benutzer verwenden für Ihr kleines Spiel dasselbe Passwort wie für ihr Google-Konto, Facebook-Konto, Bankkonto usw. Selbst wenn Sie behaupten können, dass es ihre Schuld ist, schlechte Internet-Sicherheitsgewohnheiten zu verwenden, sind Sie derjenige, der dafür verantwortlich gemacht wird, wenn Ihr Spiel als Angriffsmethode verwendet wird, um die Anmeldeinformationen der Benutzer zu stehlen. Als Entwickler, der es besser weiß, besteht die einzige ethische Möglichkeit darin, Ihren Authentifizierungsprozess ordnungsgemäß abzusichern oder überhaupt keinen zu haben.
Aufgrund einiger unerwünschter, aber verwandter Ratschläge möchten Benutzer ohnehin nicht verpflichtet werden, sich für Ihr Spiel anzumelden. Sie tun dies vielleicht, wenn sie Ihr Spiel schlecht genug spielen wollen, aber ein weiteres Freaking-Login, für das sie sich anmelden müssen, wird viele potenzielle Spieler einfach vertreiben. Benutzer sind todkrank, wenn sie ein neues Konto für jede einzelne Site, jeden Dienst und jedes Spiel erstellen, insbesondere, wenn sie irgendeine Art von E-Mail-Validierung oder dergleichen benötigen. Wenn dies möglich ist, vermeiden Sie entweder die Anmeldung oder verwenden Sie einen vorhandenen Authentifizierungsdienst eines Drittanbieters, bei dem Benutzer wahrscheinlich bereits ein Konto haben. Auf diese Weise werden Sie mehr Spieler haben. Dies verdreifacht sich, wenn Sie vorhaben, In-App-Käufe zu tätigen.
Web-Spiele
Eine beliebte Option - insbesondere für Webspiele, obwohl sie auch für herkömmliche Spiele funktioniert - ist die Verwendung eines webbasierten Authentifizierungsdienstes eines Drittanbieters. Facebook und Google verfügen beide über gut dokumentierte APIs (beide basieren auf standardisierten APIs, iirc) zur Authentifizierung. Sie müssen in der Lage sein, ein Browserfenster zu öffnen und den Benutzer zu ihren Diensten zu leiten. Dies ist jedoch auf den meisten Nicht-Konsolen-Plattformen recht einfach und für Web-Spiele natürlich trivial.
Diese Dienste kümmern sich um alle Details der Verschlüsselung des Anmeldeverkehrs über das Netzwerk, die sichere Speicherung der Anmeldeinformationen und die Überprüfung der Benutzeranmeldungen. Ihr Spieleserver muss dann nur den Teil des Protokolls implementieren, der ein Cookie vom Benutzer empfängt und den Authentifizierungsdienst fragt, ob das Cookie gültig ist oder nicht, was in den meisten Fällen mit einem einfachen HTTP erfolgen kann.
Ich werde nicht behaupten, dass die meisten traditionellen Multiplayer-Spiele dies tun, weil sie dies nicht tun, aber ich werde behaupten, dass die meisten Online-Casual-Web-Spiele dies tun.
Bei herkömmlichen Spielen (die nicht aus dem Web stammen) kann dieser Anmeldevorgang vereinfacht werden, indem entweder ein Browser eingebettet wird (Awesomium, Chromium Embedded Framework oder Webkit als gängige Option) oder ein externer Browser aufgerufen wird (dies erfordert einige weitere Verbesserungen) Holen Sie sich das Auth-Cookie raus und es ist wirklich nicht einfacher, als eine der oben genannten Bibliotheken einzubetten.
Ein typisches Beispiel für diesen Ansatz ist jedes Facebook-Spiel.
Traditionelle Spiele mit HTTPS
Ein einfacher HTTPS-Dienst für die Anmeldung wird immer normaler. Viele Spiele verwenden benutzerdefinierte Protokolle, die meisten sind jedoch unvollständig (sie verfügen über eine sichere Anmeldung, bieten jedoch keine sichere Möglichkeit zum Erstellen / Aktualisieren eines Kontos, sodass sie den HTTPS-Dienst sowieso benötigen) oder einfach schrecklich unsicher.
Sie müssen nicht einmal ein benutzerdefiniertes SSL-Zertifikat erwerben. Es gibt Online-App-Hosting-Anbieter, die Ihnen eine Subdomain zuweisen und ein Wildcard-SSL-Zertifikat verwenden. Sie können Ihren Authentifizierungsdienst unter mygame.someservice.com einrichten. Dies wird durch das Wildcard-Zertifikat * .someservice.com abgedeckt, das Some Service verwaltet, und Sie können loslegen.
Die Idee dabei ist, dass sich der Benutzer bei Ihrem Dienst anmeldet, wodurch ein eindeutiger Sitzungscookie generiert wird, den der Benutzer dann an Ihren Hauptspielserver übergeben kann. Der Server fragt dann das Anmeldesystem, ob der Cookie für den angeforderten Benutzer gültig ist. Normalerweise gibt es eine sehr kurze Zeitüberschreitung für das Cookie in der Größenordnung von Sekunden (zum Beispiel 15-30) und es wird im Allgemeinen ungültig, wenn es einmal verwendet wird, was Wiederholungsangriffe unmöglich macht.
Beachten Sie, dass HTTPS meine am meisten empfohlene Option ist, wenn Sie Zahlungsinformationen vom Client aus über das Internet senden möchten. Es ist jedoch wesentlich besser, dafür einen Drittanbieter zu verwenden. Wenn Sie der Meinung sind, dass das Sichern eines einfachen Kennworts zu aufwendig ist, möchten Sie nicht einmal darüber nachdenken, die minimalen (und ehrlich gesagt unangemessenen) PCI-Compliance-Regeln für das Speichern und Verarbeiten von Kreditkartennummern einzuhalten. Sie erzielen ohnehin eine bessere Umsatzrealisierung, wenn Benutzer vertrauenswürdige Zahlungsdienste von Drittanbietern verwenden, bei denen sie bereits registriert sind.
Ein wesentlicher Vorteil der Trennung Ihres Anmeldedienstes vom Hauptspielserver besteht darin, dass externe Funktionen an spielunabhängige Benutzerkonten gebunden werden können. Möglicherweise verfügen Sie über einige Kontofunktionen (Anzeigen von Avataren oder Ähnlichem) auf Ihrer Website, oder Sie gestatten möglicherweise das Verknüpfen von Facebook-Konten mit Ihren Konten, oder Sie haben mehrere Spiele, die eine einzige zugrunde liegende Kontoplattform gemeinsam nutzen (z. B. die Galaxy at War-Funktionen von Mass Effect) 3).
Ein beliebtes Beispielspiel, das HTTPS zur Authentifizierung verwendet, ist Minecraft.
Drittanbieter-Webauthentifizierung mit nativen Client-Spielen
Es ist möglich, Dienste von Drittanbietern wie Facebook Connect oder Google mit einem nativen Client zu nutzen. Facebook hat zum Beispiel ein natives SDK für iOS und Android, ebenso wie Google. Einige Dienste verfügen ebenfalls über native SDKs für herkömmliche PC-Clients.
Wenn der Zieldienst kein natives SDK hat und die Verwendung eines Webbrowsers erfordert, können Sie einfach einen Browser in Ihr Spiel einbetten. Einige Benutzer können jedoch misstrauisch sein, einen eingebetteten Browser zum Eingeben von Anmeldeinformationen zu verwenden.
Sie können auch einen externen Browser verwenden. Es gibt einige Möglichkeiten, dies zu erreichen. Einige erfordern etwas mehr OS-Integration als andere. Bei einigen muss ein externer Webdienst neben Ihrem Hauptspielserver ausgeführt werden (oder zumindest über diesen erreichbar sein). Da für Facebook und Google in der Regel eine authentifizierte URL erforderlich ist, benötigen Sie in (fast) allen Fällen eine Zielseite für eine öffentliche Website, um diese Protokolle zu verwenden.
Die idiotensichere und zuverlässigste, wenn nicht die einfachste Möglichkeit, besteht darin, Ihre Anmeldeanforderung von Ihrem Kunden über Ihre Hauptwebsite weiterzuleiten. Ihr Client stellt eine Verbindung zum Hauptspielserver als authentifizierter Gastbenutzer her und erhält ein eindeutiges Sitzungstoken. Der Spieleserver erlaubt dem Client nicht, in diesem Zustand tatsächlich viel zu tun. Das Spiel weiß nicht, wer der Spieler ist, daher kann der Spieler noch nicht chatten, ein Match beginnen usw.
Der Client startet dann den externen Browser, der auf die Anmelde-URL der Domäne Ihres Spiels verweist, und übergibt dieses Sitzungstoken als Parameter in der URL. Die Seite durchläuft dann den üblichen Login-Handshake für Facebook / Google.
Zu diesem Zeitpunkt weiß Ihr Webserver, dass sich der Benutzer angemeldet hat, und kann dies dem Sitzungstoken zuordnen, das er vom Client erhalten hat. Diese Überprüfung kann dann an den Spieleserver übermittelt werden, wodurch die nicht authentifizierte Gastverbindung des Clients zu einer authentifizierten Benutzersitzung wird. Dies kann erreicht werden, indem der Webserver nach Möglichkeit direkt mit dem Spieleserver kommuniziert. Oder der Spieleserver kann den Webserver regelmäßig nach dem Authentifizierungsstatus ausstehender Gastverbindungen abfragen. Oder der Client kann den Webserver regelmäßig abfragen, um festzustellen, ob die Anmeldung abgeschlossen ist, und dem Spielserver signalisieren, dass er eine Bestätigung vom Webserver anfordern soll.
All dies setzt voraus, dass Ihr Spieleserver und Ihr Webserver miteinander kommunizieren können. Bei Authentifizierungsdiensten von Drittanbietern muss Ihr Spieleserver jedoch mit der Außenwelt kommunizieren können. Dies sollte also keine Überraschung sein.
Diese Authentifizierungsmethode wird in einigen kleinen bis mittleren MMOs verwendet.
Beachten Sie, dass dies alles auch für Zahlungsanforderungen über einen externen Dienst wie PayPal, Amazon Payments, Google Wallet usw. funktioniert.
Direkte TLS-Verbindung
Es ist nicht allzu schwierig, eine TLS-Sitzung über ein benutzerdefiniertes Stream-Protokoll zu starten. Bibliotheken wie OpenSSL, GnuTLS, NSS und verschiedene betriebssystemspezifische Bibliotheken bieten eine Stream-Wrapper-API, die sich über ein Transport- / Protokoll auf niedriger Ebene erstreckt. In der Regel müssen nur Bytes über die Wrapper-API eingegeben werden, und der Handshake und die Verschlüsselung werden ausgeführt.
Die heiklen Teile hier stellen sicher, dass Sie TLS sicher verwenden. Einige der gängigen Bibliotheken erfordern beispielsweise standardmäßig ein gültiges signiertes Zertifikat von einer vertrauenswürdigen Stelle. Einige der gängigen Bibliotheken erfordern dies, vertrauen jedoch standardmäßig keinen Behörden. Einige von ihnen verlangen nicht, dass das Zertifikat überhaupt gültig ist.
Es wird empfohlen, dass Sie immer ein gültiges Zertifikat benötigen. Durch das Zulassen ungültiger Zertifikate kann ein Angreifer, der lediglich lauscht, kein Passwort stehlen, aber dennoch Man-in-the-Middle-Angriffe ausführen.
Dieser Ansatz erfordert das absolut Geringste an externen Abhängigkeiten und bietet dennoch maximale Sicherheit.
Beispiele für Spiele, die dies verwenden, sind die meisten großen traditionellen MMOs.
Sichere (ish) traditionelle Spiele
Spiele, die keinen separaten Dienst und kein TLS verwenden, müssen in ihrem Hauptspielprotokoll normalerweise ein nicht-ce-basiertes Anmeldeprotokoll implementieren. Bei dieser Methode generiert der Server eine Zufallszahl (Nonce) und sendet diese an den Client. Der Client hascht diese Nonce dann mit dem Kennwort des Benutzers (und dem Benutzernamen, möglicherweise einigen anderen Daten) und sendet diese Antwort an den Server. Der Server vergleicht diesen Hash-Wert dann mit den Anmeldeinformationen, über die er verfügt. Dadurch wird das Kennwort des Benutzers über die Leitung geheim gehalten und es wird sichergestellt, dass Sie keinen einfachen Wiederholungsangriff auf das Hash-Kennwort ausführen können, wie bei vielen anderen schwachen Hash-basierten Anmeldeschemata.
Ein Problem besteht darin, dass der Benutzer über dieses Protokoll kein neues Kennwort sicher an den Dienst senden kann. Typische Implementierungen speichern das Passwort des Benutzers auch im Klartext auf dem Server, was eine schreckliche Praxis ist (wenn Ihr Server gehackt wird, hat Ihr Benutzer wahrscheinlich gerade sein E-Mail / Facebook / Bank-Passwort gestohlen, weil er dasselbe Passwort für Ihr Spiel verwendet hat wie überall sonst, weil Benutzer dazu neigen).
Es gibt erweiterte Versionen dieses grundlegenden Anmeldeschemas. Die einfachste - wenn auch noch nicht ideal sichere - Methode besteht darin, dass der Server beim Anmelden das Kennwort-Hash-Salt mit dem Wert nonce sendet. Auf diese Weise kann der Server ein gehashtes (und gesalzenes) Kennwort sicher speichern, während der Client während der Anmeldung denselben Hash generieren kann. Auf diese Weise kann ein Angreifer das Salt für das Kennwort eines bestimmten Benutzers abrufen. Dies ist jedoch nicht besonders hilfreich, wenn nicht auch das ursprüngliche Hash-Kennwort abgerufen wird (das beim Anmelden nicht über das Netzwerk gesendet wird). Während der Erstellung / Aktualisierung des Passworts sendet der Client das gesamte Hash-Passwort (mit Salt), das der Angreifer abhören kann. Wenn die verwendete Hash-Funktion stark genug ist (z. B. sha-2/512), ist reines Brute-Forcen nicht möglich. Der Angreifer kann schwache Passwörter dennoch leicht brachial erzwingen (daher ist es wichtig, eine Mindestlänge für Passwörter, eine Mindestverteilung von Buchstaben / Zahlen / Symbolen und einen Vergleich mit einem Wörterbuch bekannter / offensichtlicher / schwacher Passwörter zu erzwingen). Die Tatsache, dass der Angreifer immer noch das gehashte Passwort erhalten kann, ist der Grund, warum es immer noch sicherer ist, den gesamten Passwortaustausch über einen gesicherten, verschlüsselten Kanal durchzuführen.
Eine Reihe beliebter Netzwerkbibliotheken für Spiele implementiert eine optionale Form dieses Protokolls. Ich glaube, dass SmartFox ein solches Beispiel ist, obwohl ich es nicht ausführlich untersucht habe (ich ignoriere im Allgemeinen ein solches Bibliotheksauthentifizierungssystem und verwende die HTTPS-Methode, da es kinderleicht zu implementieren und bedeutend leistungsfähiger ist). Eine Reihe früherer Nicht-Web-Internet-Spiele nutzten diesen Ansatz ebenfalls, insbesondere bevor Steam, XBL usw. auf den Markt kamen.
Unsichere traditionelle Spiele
Viele Spiele senden leider nur einen Benutzernamen / ein Passwort im Klartext. Vielleicht haben sie das Passwort, das das tatsächliche Passwort des Benutzers vage schützt (bei weitem nicht gut genug), aber ein Wiederholungsangriff macht die Anmeldung beim Spieldienst trivial.
Mach das nicht. Es ist verantwortungslos und faul. Die Internet-Naivität der neunziger Jahre, die diese Anmeldemethoden populär machte, ist keine brauchbare Entschuldigung mehr.
Viele frühe Flash- und Web-Spiele vor Facebook verfolgten diesen Ansatz. Ich kenne keine konkreten Beispiele aus meinem Kopf; Ich würde gerne glauben, dass sie alle längst tot sind, aber die Welt ist einfach nicht so glücklich.
Keine Authentifikation
Die meisten Spiele führen keine Authentifizierung durch. Der Spieler verbindet sich, sendet über einen Handgriff, um sich eindeutig zu identifizieren, und ein Match beginnt. Es gibt keinen globalen Server, der versucht zu bestätigen, dass nur ein realer Mensch jemals behaupten darf, "CaptainMisterDude" zu sein. Der lokale Server stellt lediglich sicher, dass nur ein aktuell verbundener Player einen bestimmten Handle hat, und das ist das Ende. Lokale Server verwenden namenbasiertes und IP-basiertes Blacklisting für Trouble Maker. Dies ist für FPS Deathmatch-Spiele auch heute noch üblich.
Wenn Sie keinen permanenten Status für Konten benötigen, ist dies bei weitem die einfachste Lösung und ziemlich "sicher", da es dort nichts gibt, was Sie tatsächlich hacken oder stehlen könnten. Offensichtlich funktioniert dies nicht besonders gut, wenn Sie zwischen den Spielsitzungen Kontoinformationen speichern müssen.
Quake ist ein Beispiel für ein Spiel, bei dem diese Methode zum "Authentifizieren" von Benutzern verwendet wird.