Jak podzielić login i logikę gry podczas pisania serwerów?

Buduję pokerowy serwer gry. Miałem zamiar obsługiwać wszystkie loginy i logikę gry na jednym serwerze, ale z moich badań w sieci dowiaduję się, że to nie będzie skalować i sensowne byłoby podzielenie prace nad logowaniem i serwerami gier. Ale nie dostaję tego po tym, jak obsłużyłem uwierzytelnianie na serwerze logowania i poprosiłem klienta o nawiązanie nowego połączenia z serwerem gier. Skąd mam wiedzieć, który to klient? Czy nie musiałbym ponownie logować się ponownie, a tym samym zniweczyć cel posiadania serwera do logowania? Czy istnieje jakiś sposób na przekazanie połączenia między procesami i komputerami, o których nie wiem? Przepraszam za moją małą wiedzę na temat sieci.

server authentication

— użytkownik342580
źródło

YAGNI: nie będziesz go potrzebować. Nie wdrażaj przedwczesnej optymalizacji. Logowanie brzmi jak bardzo trywialna część gry, dzielenie jej raczej nie przyniesie żadnych korzyści; gdy w grze będzie wystarczająco dużo użytkowników, na których Ci zależy (powinieneś być w stanie obsłużyć tysiące użytkowników na jednym serwerze, a inni tylko w celu zapewnienia nadmiarowości), będziesz mógł zatrudnić inżynierów oprogramowania, którzy rozumieją tego rodzaju rzeczy.

— MarkR

Zaakceptowałeś mylącą odpowiedź, powinieneś to przemyśleć ponownie, w przeciwnym razie skończysz z błędnymi pojęciami w głowie i fałszywym poczuciem bezpieczeństwa w kodzie.

— o0 ”.

Podobało mi się odpowiedź Kylotana, ponieważ nie muszę mieć dodatkowego połączenia między serwerami gry a serwerem logowania. Widzę też punkt Philipa, że kompromis tajnego klucza jest kompromisem na wszystkich kontach, które są transportowane. Zaimplementuję obie wersje logowania i zapytam eksperta ds. Bezpieczeństwa, kiedy otrzymam kontrolę kodu. Moje pytanie wydaje się dość proste i spodziewałem się, że będzie to standardowe rozwiązanie, na które wszyscy się zgodzą. Domyśl. Gdyby tylko ekspert ds. Bezpieczeństwa mógł wziąć udział w tej dyskusji i podjąć decyzję.

— user342580,

Ściśle mówiąc, przekazywanie tokena logowania między serwerami jest bezpieczniejsze, pod warunkiem, że masz bezpieczny kanał, aby to zrobić. Jest również trudniejszy do wdrożenia, co zwiększa ryzyko popełnienia błędu. System uwierzytelniania wiadomości oparty na haszowaniu powinien być całkowicie bezpieczny, chyba że ktoś może uzyskać Twój tajny klucz - a jeśli może on uzyskać Twój klucz przez dostęp do systemów wewnętrznych, masz problemy, których nie można rozwiązać, wysyłając login tokeny ręcznie.

— Kylotan

Odpowiedzi:

Chociaż odpowiedź Filipa jest całkowicie dobra, istnieje nieco inny sposób, który nie wymaga połączenia między serwerem logowania a serwerem gry, co jest przydatne, jeśli takie połączenie jest trudne.

Gdy użytkownik pomyślnie uwierzytelni się na serwerze logowania, wysyłany jest adres serwera gry i token logowania, jak wyżej. Jednak ten token składa się z 2 części: czasu na serwerze logowania i skrótu tego numeru oraz nazwy użytkownika, adresu IP, adresu IP lub identyfikatora serwera gry oraz tajnego klucza, który znasz tylko ty.
Klient próbuje zalogować się na podanym serwerze gry, wysyłając ten token. Serwer tworzy taki sam skrót jak poprzednio, w oparciu o informacje z tokena logowania oraz własny adres IP / identyfikator i tajny klucz. Jeśli ten skrót pasuje do tego z tokena, wiesz, że gracz został poprawnie uwierzytelniony. Następnie sprawdź, czy data nie jest za stara (np. Więcej niż 1 minuta).

Działa to, ponieważ:

Nie można go skopiować i użyć ponownie, ponieważ data wygaśnie.
Nie można go zbudować bez świeżego logowania bez znajomości tajnego klucza.
Nie może być łatwo przechwycone przez kogoś innego (np. Za pomocą sniffera pakietów) i użyte, ponieważ oryginalny adres IP jest używany do jego budowy.
Nie można go użyć do innego konta, ponieważ nazwa użytkownika stanowi część skrótu.
Nie można go używać do równoczesnego logowania na różnych serwerach gry, ponieważ identyfikator / adres IP serwera stanowi część skrótu.

Mówiąc prościej, skrót zapewnia, że nadawca nie jest w stanie sfałszować swojego tokena logowania, dzięki czemu można zaufać informacjom zawartym w tokenie.

Podobnie jak w przypadku każdego haszowania zorientowanego na bezpieczeństwo, użyj najlepszej funkcji skrótu, jaką możesz uzyskać - w tej chwili ludzie wydają się lubić bcrypt, PBKDF2 i scrypt - i upewnij się, że twój tajny klucz jest bardzo długi, aby odtworzenie brutalnej siły było mniej praktyczne.

— Kylotan
źródło

Bardzo sprytne, zdecydowanie wolę to rozwiązanie. Moje pytanie jest więc tajnym kluczem. Czy powinno być jak hasło lub coś takiego? I czy powinno być inaczej dla każdego użytkownika?

— user342580,

To nie działa lub w rzeczywistości jest to ukryta ponowna implementacja odpowiedzi @ Philipp. Nie udaje się, ponieważ zakłada, że zarówno serwer logowania, jak i serwer gry znają ten sam tajny klucz. Jeśli oboje znają klucz, jeden z nich musi skontaktować się z drugim, aby go podać. Lub potrzebujesz strony trzeciej, aby wysłać go do obu. Tak czy inaczej, jest tak samo powąchany jak wcześniej.

— o0 ”.

@Lohoris, chodzi o to, że posiadasz zarówno login, jak i serwer gry i możesz przekazać im tajny klucz. Jeśli nie posiadasz obu serwerów, to w jaki sposób serwer gry może ufać uwierzytelnieniu serwera logowania?

— Kylotan

@ user342580: Chciałbym użyć długiej frazy. Nie musi się różnić w zależności od użytkownika, ale jeśli tak, to nie zaszkodzi. Tak długo, jak funkcja szyfrowania kryptograficznego jest wystarczająco silna i okresowo ją zmieniasz, nie powinno to mieć znaczenia.

— Kylotan,

@Kylotan dokładnie i jak podać im klucz? Dlaczego uważasz, że bardziej bezpieczne jest połączenie między tobą a serwerami niż połączenie między serwerami?

— o0 ”.

Po uwierzytelnieniu się użytkownika na serwerze logowania, podaj mu token (unikatowy, losowo generowany ciąg znaków, który jest zbyt długi, aby go zgadnąć).
Serwer logowania wybiera serwer gier. Wyślij token, nazwę użytkownika i wszystkie inne istotne dane o użytkowniku z serwera logowania na wybrany serwer.
Wyślij token i nazwę hosta serwera gier do klienta. Następnie odłącz go od serwera logowania.
Następnie klient łączy się z serwerem gier za pomocą swojej nazwy użytkownika i tokena.
Gdy token klienta pasuje do tego zgłoszonego przez serwer logowania, akceptujesz go.

Należy pamiętać, że aby było to bezpieczne, tokeny należy utworzyć z kryptograficznie bezpiecznego generatora liczb losowych, każdy token może zostać zaakceptowany tylko przez serwer gry, a nieużywane tokeny należy odrzucić po kilku minutach.

— Philipp
źródło

Czy wystarczyłoby bcrypt? Zastanawiam się nad utworzeniem tokena z mieszania czasu + nazwa użytkownika + hasło przy użyciu bcrypt.

— user342580,

Chyba tak. Znając hasło, można odgadnąć token, ale znając hasło, można po prostu zalogować się w normalny sposób.

— Philipp

bcrypt działa, o ile dane wejściowe są odpowiednio losowe i nie można ich wymyślić. Jeśli wykorzystasz tylko czas, atakujący może spróbować przewidzieć czas, a następnie uruchomić program bcrypt i zdobyć token. Pamiętaj, aby używać tajnej soli z czasem lub bezpiecznego randomizatora (np. / Dev / random w systemach UNIX / Linux).

— Sean Middleditch,

Hasło mogło zostać przejęte przez inną witrynę, dlatego unikałbym zakładania, że jest to odpowiedni sekret.

— Sean Middleditch,

@SeanMiddleditch Gdy hasło zostanie naruszone, wszystkie zabezpieczenia i tak zostaną utracone. Osoba atakująca, która uzyskała hasło, nie ma powodu, aby zgadywać token, ponieważ mógł je zdobyć, logując się w normalny sposób.

— Philipp