W szczególności w odniesieniu do ostatniego fragmentu pytania: Nie, nigdy nie można wybaczyć posiadania niepewnego systemu uwierzytelniania. Użytkownicy rzadko są oświeceni, jeśli chodzi o bezpieczeństwo komputera. Użytkownicy używają tego samego hasła do Twojej małej gry, co do konta Google, konta Facebook, konta bankowego i tak dalej. Nawet jeśli możesz twierdzić, że to ich wina za używanie złych nawyków związanych z bezpieczeństwem w Internecie, to Ty będziesz odpowiedzialny za to, że Twoja gra zostanie wykorzystana jako wektor ataku do kradzieży danych logowania użytkowników. Jako programista, który wie lepiej, jedynymi etycznymi opcjami są odpowiednie zabezpieczenia procesu uwierzytelniania lub ich brak.
Jako niektóre niezamówione, ale powiązane porady, użytkownicy nie chcą być zobowiązani do rejestracji w grze. Mogą to zrobić, jeśli chcą zagrać w twoją grę wystarczająco źle, ale posiadanie Yet Another Freaking Login, aby się zarejestrować, odstraszy wielu potencjalnych graczy. Użytkownicy mają dość tworzenia nowego konta dla każdej witryny, usługi i gry, zwłaszcza jeśli wymagają one jakiejkolwiek weryfikacji adresu e-mail lub podobnego. Jeśli możesz, w ogóle unikaj logowania lub skorzystaj z istniejącej usługi uwierzytelniania innej firmy, z którą użytkownicy prawdopodobnie już mają konto. W ten sposób będziesz mieć więcej graczy. To potroi się, jeśli planujesz mieć jakiekolwiek zakupy w aplikacji.
Gry internetowe
Popularną opcją - szczególnie w przypadku gier internetowych, choć działa również w przypadku tradycyjnych gier - jest korzystanie z internetowej usługi uwierzytelniania innych firm. Facebook i Google mają dobrze udokumentowane interfejsy API (oba oparte na standardowych interfejsach API, iirc) do uwierzytelniania. Wymagają one możliwości otwarcia okna przeglądarki i skierowania użytkownika do swoich usług, ale jest to dość łatwe na większości platform innych niż konsole i oczywiście trywialne w przypadku gier internetowych.
Usługi te zajmują się wszystkimi niechlujnymi szczegółami szyfrowania ruchu związanego z logowaniem przez sieć, bezpiecznego przechowywania danych logowania i sprawdzania poprawności logowania użytkownika. Twój serwer gry musi wtedy zaimplementować tylko część protokołu, która otrzymuje plik cookie od użytkownika i pyta usługę uwierzytelniania, czy plik cookie jest ważny, czy nie, co w większości przypadków można zrobić za pomocą prostego protokołu HTTP.
Nie twierdzę, że robią to tradycyjne gry wieloosobowe, ponieważ tego nie robią, ale twierdzę, że większość zwykłych gier internetowych to robi.
W przypadku tradycyjnych gier (innych niż internetowe) ułatwienie tej procedury logowania jest możliwe poprzez osadzenie przeglądarki (Awesomium, Chromium Embedded Framework lub zwykłe Webkit będące popularnymi wyborami) lub przez wywołanie zewnętrznej przeglądarki (wymaga to więcej fanagowania do pozbyć się auth cookie i nie jest tak naprawdę łatwiejsze niż osadzenie jednej z wyżej wymienionych bibliotek).
Typowym przykładem tego podejścia jest każda gra na Facebooku.
Tradycyjne gry wykorzystujące HTTPS
Posiadanie prostej usługi HTTPS do logowania jest coraz bardziej normalne. Wiele gier korzysta z niestandardowych protokołów, ale większość z nich jest niekompletna (mają bezpieczne logowanie, ale nie ma bezpiecznego sposobu na utworzenie / aktualizację konta, więc i tak potrzebują usługi HTTPS) lub są po prostu strasznie niepewne.
Nie musisz nawet kupować niestandardowego certyfikatu SSL. Istnieją dostawcy internetowych usług hostingowych aplikacji, którzy udostępniają subdomenę i używają certyfikatu SSL z wieloznacznymi danymi. Możesz umieścić swoją usługę uwierzytelniania na stronie mygame.someservice.com, która jest objęta certyfikatem wieloznacznym * .someservice.com, który zachowuje Some Service, i możesz zacząć.
Chodzi o to, że użytkownik loguje się do Twojej usługi, która generuje unikalny plik cookie sesji, który użytkownik może następnie przekazać na główny serwer gry. Serwer następnie pyta system logowania, czy plik cookie jest prawidłowy dla żądanego użytkownika. Ciasteczko zazwyczaj ma bardzo krótki limit czasu (na przykład 15-30) i jest zwykle unieważniane po użyciu, co uniemożliwia ataki z powtórkami.
Pamiętaj, że HTTPS jest moją najbardziej zalecaną opcją, jeśli planujesz przesyłać informacje o płatności za pośrednictwem przelewu z poziomu samego klienta. Jednak znacznie lepiej jest do tego użyć innej firmy. Jeśli uważasz, że zabezpieczanie czegoś tak prostego jak hasło jest zbyt pracochłonne, nie chcesz nawet myśleć o próbie spełnienia minimalnych (i szczerze mówiąc nieodpowiednich) zasad zgodności z PCI dotyczących przechowywania i przetwarzania numerów kart kredytowych. Tak czy inaczej, będziesz mieć lepszą sprzedaż, jeśli masz użytkowników korzystających z zaufanych zewnętrznych usług płatniczych, z którymi są już zarejestrowane.
Zaletą oddzielenia usługi logowania od głównego serwera gry jest to, że pozwala ona na powiązanie zewnętrznych funkcji z kontami użytkowników niezależnie od gry. Możesz mieć pewne funkcje konta (przeglądanie awatarów itp.) Na swojej stronie, a może zezwalasz na łączenie kont Facebook ze swoimi kontami, a może masz wiele gier współdzielących jedną platformę konta (np. Funkcje Galaxy at War Mass Effect 3).
Popularną przykładową grą używającą HTTPS do uwierzytelniania jest Minecraft.
Uwierzytelnianie stron trzecich przez natywne gry klienckie
Możliwe jest korzystanie z usług stron trzecich, takich jak Facebook Connect lub Google, z rodzimym klientem. Na przykład Facebook ma natywny zestaw SDK dla systemów iOS i Android, podobnie jak Google. Niektóre usługi mają również natywne zestawy SDK dla tradycyjnych klientów PC.
Jeśli usługa docelowa nie ma natywnego zestawu SDK i wymaga użycia przeglądarki internetowej, możesz po prostu osadzić przeglądarkę w grze. Jednak niektórzy użytkownicy mogą nie ufać używaniu wbudowanej przeglądarki do wprowadzania danych logowania.
Możesz także użyć zewnętrznej przeglądarki. Istnieje kilka sposobów, aby to zrobić. Niektóre wymagają nieco większej integracji systemu operacyjnego niż inne. Niektóre wymagają posiadania zewnętrznej usługi internetowej działającej obok (lub przynajmniej dostępnej) głównego serwera gry. Pamiętaj, że ponieważ Facebook i Google zazwyczaj wymagają uwierzytelnionego adresu URL, do korzystania z tych protokołów będzie potrzebna strona docelowa publicznej witryny (prawie) we wszystkich przypadkach.
Najbardziej niezawodny i niezawodny, jeśli nie najłatwiejszy, polega na odrzuceniu żądania logowania od klienta za pośrednictwem głównej witryny. Twój klient łączy się z głównym serwerem gry jako uwierzytelniony użytkownik-gość i otrzymuje unikalny token sesji. Serwer gry nie pozwala klientowi na faktyczne wykonanie wielu czynności w tym stanie; gra nie wie, kim jest gracz, więc gracz nie może jeszcze czatować, rozpocząć meczu itp.
Następnie klient uruchamia zewnętrzną przeglądarkę wskazującą adres URL logowania do domeny gry, przekazując token sesji jako parametr w adresie URL. Następnie strona przechodzi zwykły uścisk logowania na Facebooku / Google.
W tym momencie twój serwer wie, że użytkownik się zalogował i może powiązać to z tokenem sesji otrzymanym od klienta. Ta weryfikacja może następnie zostać przekazana do serwera gry, podnosząc nieuwierzytelnione połączenie gościa klienta w uwierzytelnioną sesję użytkownika. Można to zrobić poprzez bezpośrednią komunikację serwera z serwerem gry, jeśli to możliwe. Lub serwer gry może okresowo odpytywać serwer WWW o status uwierzytelnienia oczekujących połączeń gości. Albo klient może okresowo odpytywać serwer WWW, aby sprawdzić, czy logowanie jest zakończone, a kiedy to nastąpi, zasygnalizować serwerowi gry żądanie weryfikacji z serwera.
Wszystkie te wymagają, aby Twój serwer gier i serwer sieciowy mogły się komunikować, ale każda usługa uwierzytelniania strony trzeciej będzie wymagać, aby Twój serwer gier mógł komunikować się ze światem zewnętrznym, więc nie powinno to być zaskoczeniem.
Ta metoda uwierzytelniania znajduje się w niektórych małych i średnich MMO.
Pamiętaj, że wszystko to działa również w przypadku wysyłania żądań płatności za pośrednictwem usługi zewnętrznej, takiej jak PayPal, Amazon Payments, Portfel Google itp.
Bezpośrednie połączenie TLS
Rozpoczęcie sesji TLS przy użyciu niestandardowego protokołu strumienia nie jest trudne. Biblioteki takie jak OpenSSL, GnuTLS, NSS i różne biblioteki specyficzne dla systemu operacyjnego zapewniają API otoki strumienia, które warstwuje na niskim poziomie transportu / protokołu. Zasadniczo wystarczy podać bajty przez interfejs API opakowania, który zajmuje się uzgadnianiem i szyfrowaniem.
Trudne części tutaj zapewniają bezpieczeństwo korzystania z TLS. Na przykład niektóre popularne biblioteki domyślnie wymagają ważnego podpisanego certyfikatu od zaufanego organu. Niektóre wspólne biblioteki tego wymagają, ale domyślnie nie ufają żadnym organom. Niektóre z nich wcale nie wymagają ważności certyfikatu.
Zaleca się, aby zawsze wymagać ważnego certyfikatu. Zezwolenie na nieprawidłowe certyfikaty nie pozwoli atakującemu, który podsłuchuje, na kradzież hasła, ale nadal pozwoli na ataki typu man-in-the-middle.
Takie podejście wymaga absolutnego minimum pod względem zewnętrznych zależności, a jednocześnie zapewnia maksymalne bezpieczeństwo.
Przykłady gier korzystających z tego obejmują teraz większość dużych tradycyjnych gier MMO.
Bezpieczne (tradycyjne) gry
Gry, które nie korzystają z oddzielnej usługi i nie korzystają z TLS, zazwyczaj muszą implementować jakiś rodzaj protokołu logowania nieopartego na swojej logice w głównym protokole gry. Dzięki tej metodzie serwer generuje liczbę losową (nonce) i wysyła ją do klienta. Klient następnie szyfruje tę nonce hasłem użytkownika (i nazwą użytkownika, ewentualnie innymi danymi) i wysyła tę odpowiedź do serwera. Serwer następnie porównuje tę wartość skrótu z poświadczeniami, które posiada w pliku. Utrzymuje to hasło użytkownika w tajemnicy przez sieć i zapewnia, że nie można użyć prostego ataku powtórnego na hashowane hasło, podobnie jak wiele innych słabych schematów logowania opartych na haszowaniu.
Problem polega na tym, że użytkownik nie ma możliwości bezpiecznego przesłania nowego hasła do usługi za pośrednictwem tego protokołu. Typowe implementacje przechowują również hasło użytkownika w postaci zwykłego tekstu na serwerze, co jest okropną praktyką (jeśli Twój serwer zostanie zhakowany, użytkownik prawdopodobnie właśnie ukradł swoje hasło do konta e-mail / facebook / bank, ponieważ używał tego samego hasła do gry, co wszędzie indziej, ponieważ użytkownicy to robią).
Istnieją ulepszone wersje tego podstawowego schematu logowania. Najbardziej podstawowym - choć wciąż niezbyt bezpiecznym - jest wysyłanie przez serwer hasła skrótu hasła z wartością nonce podczas logowania. Umożliwia to serwerowi bezpieczne przechowywanie zaszyfrowanego (i solonego) hasła, jednocześnie umożliwiając klientowi wygenerowanie tego samego skrótu podczas logowania. Pozwala to atakującemu uzyskać sól dla hasła określonego użytkownika, ale nie jest to szczególnie przydatne bez uzyskania oryginalnego hasła zakodowanego (które nie jest przesyłane za pośrednictwem drutu podczas logowania). Podczas tworzenia / aktualizacji hasła klient wysyła całe hashowane hasło (z solą), które atakujący może obwąchać. Jeśli zastosowana funkcja skrótu jest wystarczająco silna (powiedzmy sha-2/512), wówczas wymuszenie czystego brutalnego nie jest możliwe, chociaż atakujący wciąż może łatwo użyć słabych haseł o brutalnej sile (dlatego ważne jest egzekwowanie minimalnej długości hasła, minimalne rozmieszczenie liter / cyfr / symboli oraz porównanie ze słownikiem znanych / oczywistych / słabych haseł). Fakt, że osoba atakująca nadal może uzyskać zaszyfrowane hasło, sprawia, że bezpieczniejsza jest cała wymiana haseł za pośrednictwem bezpiecznego, szyfrowanego kanału.
Wiele popularnych bibliotek sieciowych do gier implementuje opcjonalną formę tego protokołu. Wierzę, że SmartFox jest jednym z takich przykładów, chociaż nie przyjrzałem się mu dogłębnie (generalnie ignoruję taki system uwierzytelniania bibliotek i używam metody HTTPS, ponieważ jest on bardzo prosty do wdrożenia i znacznie silniejszy). Wiele wczesnych nie-internetowych gier internetowych również stosowało to podejście, szczególnie przed pojawieniem się Steam, XBL i tak dalej.
Niezabezpieczone tradycyjne gry
Wiele gier niestety po prostu wysyła nazwę użytkownika / hasło w postaci zwykłego tekstu. Może hashują hasło, które w pewnym sensie chroni rzeczywiste hasło użytkownika (niezbyt dobrze), ale atak powtórkowy sprawia, że logowanie do usługi gry jest banalne.
Nie rób tego To nieodpowiedzialne i leniwe. Internetowa naiwność lat 90., która spopularyzowała te metody logowania, nie jest już realnym usprawiedliwieniem.
Wiele wczesnych gier flashowych i internetowych sprzed Facebooka miało takie podejście. Nie znam żadnych konkretnych przykładów z głowy; Chciałbym wierzyć, że wszyscy już nie żyją, ale świat po prostu nie ma tyle szczęścia.
Brak autoryzacji
Większość gier po prostu nie wykonuje uwierzytelnienia. Gracz łączy się, przesyła jakiś uchwyt, aby jednoznacznie się zidentyfikować, i rozpoczyna się mecz. Nie ma globalnego serwera, który próbowałby potwierdzić, że tylko jeden prawdziwy człowiek może kiedykolwiek twierdzić, że jest „CaptainMisterDude”. Serwer lokalny zapewnia tylko, że tylko jeden aktualnie podłączony gracz ma określony uchwyt i to jest koniec. Lokalne serwery używają czarnych list opartych na nazwach i adresach IP dla sprawiających problemy. Jest to powszechne nawet w grach typu FPS deathmatch.
Jeśli nie potrzebujesz żadnego stałego stanu dla kont, jest to zdecydowanie najłatwiejsze rozwiązanie i dość „bezpieczne”, ponieważ nie ma nic, co można by włamać lub ukraść. Oczywiście nie działa to zbyt dobrze, jeśli musisz przechowywać informacje o koncie między sesjami gry.
Quake jest przykładem gry wykorzystującej tę metodę „uwierzytelniania” użytkowników.