Serwer nie może w pełni ufać żadnym danym, które otrzymuje od klienta, więc sprawdzenie najlepszych wyników jest trudne.

Oto kilka opcji:

1. Ukryj kod po stronie klienta i ruch na serwerze. To najłatwiejsza opcja - nadal będzie można oszukiwać, ale prawdopodobnie nie będzie to nic warte.

2. Wyślij pełną lub częściową powtórkę gry na serwer do walidacji. Ruchy gracza mogą być uruchamiane na serwerze, aby określić prawidłowy wynik. To zadziała w niektórych grach, a nie w innych.

3. Przenieś logikę gry i weryfikację na serwer. Klient po prostu przekazuje każdy ruch na serwer, gdzie jest sprawdzany, a stan gry aktualizowany.

Wszystko sprowadza się do tego, jak działa Twoja gra, jakie jest prawdopodobieństwo, że ludzie będą oszukiwać i jak bardzo zależy ci na tym.

Gdyby osoba atakująca była atakującym pośrednikiem w warstwie sieciowej, wystarczyłby protokół https. Ale niestety twój atakujący jest klientem, więc jest to raczej bezcelowe.

Zasada numer jeden w grach zabezpieczających przed oszustwami: Nigdy nie ufaj klientowi! Klient jest w rękach wroga.

Gry Javascript uruchamiane są w przeglądarce internetowej użytkownika. Jak zapewne wiesz jako programista stron internetowych, każda przeglądarka internetowa jest obecnie wyposażona we wbudowany debugger, który może wyświetlać i zmieniać wszystkie zmienne podczas działania aplikacji. Użytkownik może po prostu użyć debugera, aby zmienić swój wynik przed przesłaniem. Nic nie możesz zrobić, aby temu zapobiec. W przypadku gier przeglądarkowych nie możesz nawet nałożyć na nie narzędzia przeciwdziałającego oszustwom innej firmy (które i tak mają wątpliwą wartość i są wątpliwe etycznie).

Jedynym środkiem zaradczym jest wdrożenie wszystkich mechanizmów gry wartych manipulacji na serwerze. Klient powinien jedynie przekazywać polecenia użytkownika na serwer i wizualizować rozgrywkę na podstawie komunikatów serwera. Właściwa rozgrywka powinna odbywać się na serwerze, gdzie jest poza zasięgiem oszustów.

Tak, oznacza to, że będziesz musiał przeprojektować architekturę oprogramowania swojej gry od podstaw. Oznacza to również, że będziesz musiał dodać kod przewidywania i interpolacji, aby opóźnienie sieci było mniej widoczne. Oznacza to również, że będziesz potrzebować znacznie lepszego sprzętu serwerowego i lepszego połączenia internetowego dla swojego serwera (serwerów). Ale jeśli chcesz grę online bez oszustw, to jedyna opcja.

Aby osiągnąć wysoki wynik w bezpiecznej grze, potrzebujesz „ dowodu pracy” lub raczej, bardziej trafnie, zwanego dowodem gry.

Dowód pracy / play to wszelkie dane, które są trudne do obliczenia przed zakończeniem gry, ale łatwe do obliczenia po zakończeniu gry i łatwe do zweryfikowania przez serwer. Na przykład w przypadku gry Sudoku dowodem wykonania jest rozwiązanie łamigłówki.

Niestety, nie ma ogólnego sposobu na zintegrowanie odpowiedniego systemu weryfikacji gry w wielu grach. Nie zawsze jest możliwe zintegrowanie dowodu gry bez poprawiania lub ponownego przeglądania rozgrywki lub ograniczania zakresu tabeli wyników tylko do elementów, w których można dołączyć wystarczająco bezpieczny dowód gry.

Dowód gry na gra rozpoczyna się od wydania przez serwer seeda dla RNG gry. Klient będzie musiał wtedy znaleźć dowód gry, który pasuje do materiału siewnego, który został wydany graczowi. W wielu grach dowód gry można utworzyć, przesyłając rozwiązanie gry na serwer wraz z przesyłaniem najlepszych wyników, w innych może być konieczne nagranie całej sesji gry na różnych poziomach szczegółowości w zależności od gry i dowodu gry, której używasz.

Dowód gry musi być odporny na powtórki (jeden gracz nie powinien być w stanie użyć ukończonej gry innego gracza, aby ułatwić obliczenie własnego dowodu gry). Ogranicza to dowód gry do gier, w których istnieje pewna przypadkowość, że gracze nie mogą po prostu ponownie wykorzystać dowodu gry innego gracza, ale także nie mogą mieć zbyt wielu niedeterministycznych zachowań do tego stopnia, że ​​weryfikacja gry staje się niemożliwa.

Dowód gry jest również ograniczona. Na przykład w grze Sudoku nie można udowodnić, ile czasu zajmuje graczowi rozwiązanie łamigłówki. Dowód gry nie zawsze też może odróżnić grę, w którą gra sam gracz, od gracza, który napisał scenariusz, który grał za niego.

Chciałem tylko wspomnieć, że istnieje rozwiązanie tego problemu, ale prawdopodobnie nie będzie ono dostępne dla Ciebie; to rozwiązanie nazywa się „szyfrowaniem homomorficznym” i pozwala klientowi wykonać znane obliczenia bez dokładnej wiedzy, z jakimi wartościami oblicza, a serwerowi w związku z tym sprawdzić strukturę obliczonej wartości, aby udowodnić, że klient nie tylko wysyła losowy ciąg z powrotem, ale w rzeczywistości zbudował go z kilku podanych wartości.

Problem w tym, że jest albo powolny albo niekompletny , z „niepełnym” znaczeniem „nie zawiera pełnego zakresu logicznych prymitywów”. Bardzo często jest to częściowy system pozwalający na pewne operacje szyfrowania i deszyfrowania E (), D (), a także pewne skomplikowane operacje ⊕ takie, że

D (E (A) ⊕ E (B)) = A + B,

lub tym podobne.

Zobaczmy, jak to rozwiązuje problem w niektórych grach. Rozważ grę typu „gas out”, w której naciskasz N heksów sześciokątnej siatki i każdy z nich przełącza zarówno swój stan, jak i stany osób wokół niego. Jest to algebra przemienna na tych „tłoczeniach”, a zatem w danym rozwiązaniu nie będzie więcej niż N naciśnięć łącznie, a każdy heks zależy tylko od stanu początkowego plus naciśnięcia jego własnego heksa plus 6 heksów wokół niego.

Ponieważ nasz schemat szyfrowania homomorficznego dopuszcza tylko +, a nie XOR, dajemy każdemu szesnastkowemu 3-bitowy licznik określający, ile razy został odwrócony. (Oprogramowanie klienta automatycznie zmniejszy każde dwukrotne naciśnięcie klawisza szesnastkowego do zaledwie jednego naciśnięcia.) Rzeczywiste działania odwracania mają zatem wygląd wektorów bitowych,

  001 001 000 000 000 001 001 001 000 001 001 000 000 ... 000 00000000 00000001  

Innymi słowy, mają jedynki w każdym z tych 3-bitowych pól, które zmienia, plus 1 w 16-bitowym liczniku.

Szyfrujemy to wszystko za pomocą homomorficznego schematu szyfrowania, wysyłamy każdy z nich do klienta, a klient odsyła nam zaszyfrowaną wartość obliczoną na podstawie tych zaszyfrowanych wartości, które odesłaliśmy. Następnie odszyfrowujemy to i odszyfrowaną wartość za pomocą łańcucha bitów,

  001 001 001 001 ... 001 11111111 00000000  

i porównać z początkową grą -stan połączony z 0 dla tych 8 bitów licznika.

Jeśli wysyłają nam losową wartość, ich szansa, że ​​ją zaakceptujemy, wynosi 2 ^{- (N + 8)} , a zatem ich Jedynym użytecznym sposobem zaliczenia testów jest użycie wartości, które im podaliśmy w dozwolonej kombinacji. Mają dostęp do niektórych ruchów, na które nie pozwalamy im bezpośrednio z powodu przepełnienia liczb całkowitych, ale zawsze możemy zrobić pola szersze niż 3 bity, aby uczynić je bardziej kosztownymi dla licznika po prawej stronie. Ale nigdy nie przesyłano nam ich indywidualnych naciśnięć przycisków, a tym bardziej nie odtwarzaliśmy historii: zaakceptowaliśmy wektor mówiący „oto jak odwróciłem siatkę”, co jest „bardzo niepewną rzeczą”, przed którą wszyscy cię ostrzegają, ale my zrobili to w taki sposób, że nie mogą robić rzeczy, o które się martwimy, bez dostępu do tajnego klucza.

Zamiast tego w głosowaniu kryptograficznym widzisz tego rodzaju rzeczy, w których chcesz mieć pewność, że maszyna do głosowania nie daje Alice spontanicznie 1000 głosów.

Wszystko po stronie klienta może zostać sfałszowane. Więc odpowiedź brzmi nie.

EDYTUJ Usunąłem mechanizm bezpieczeństwa, który tutaj napisałem, ponieważ zapewnia on tylko sesje morskie ... ale sfałszowane wyniki mogą być wysyłane przez sesje morskie. Dzięki @Luke Park

Moje zalecenie dotyczy raczej techniki zaciemniania obrazu i może być frustrującą przeszkodą dla wielu użytkowników. Jednak zaawansowani lub zdeterminowani użytkownicy mogą nadal analizować kod źródłowy w celu odtworzenia wyników.

Użyj narzędzia takiego jak Hashids, aby utworzyć skrót wyniku i wyślij go w żądaniu serwera wraz z wynikiem w postaci zwykłego tekstu. Wartość ciągu identyfikatora użytkownika może być solą używaną do kodowania hashidu wyniku, co sprawi, że hash będzie bezużyteczny, jeśli zostanie udostępniony. Po stronie serwera możesz zdekodować ten hash i porównać wynik z wynikiem w postaci zwykłego tekstu, który został wysłany, aby upewnić się, że są zgodne z oczekiwaniami.