Eugene198956
@Eugene198956
где я???

Как организовать оптимальную безопасность для своего онлайн мультиплеера на Android?

Добрый день, я бэкенд разработчик. Решил окунуться в разработку мобильных игр.

Решил создать онлайн покер (интересует именно онлайн мультиплеер), но не имею опыта в организации защиты и безопасности в таких приложениях. Хотелось бы услышать советы и рекомендации, как это все делается и может у кого есть личный опыт.

Как это вижу я: делается игра-приложение (клиент) на андроид и бэк (сервер) для основной логики игры.
чтобы предвратить взлом/читы и накрутку монет/фишек и т.д. клиент не имеет основной логики, он лишь "общается" с сервером, где уже происходит вся основная логика игры (в случае покера, на сервере происходит раздача карт, и только сервер знает какая будет следующая карта и какие карты у соперника) + БД с профилями игроков, где хранятся все данные + фишки.

Интересует. как в андроид приложениях защититься от подмены данных отправляемых на сервер и быть уверенным, что каждая игра будет честной и без читерства.

подскажите, пожалуйста, книги, статьи, журналы, видео или др источники, где узнать подробней по защите таких мультиплеерных игр
  • Вопрос задан
  • 93 просмотра
Решения вопроса 1
Steel_Balls
@Steel_Balls
0L3QsNGH0LjQvdCw0Lsg0YEgQkFTSUMg0L3QsCDQo9Ca0J3Qpi
Ты всё правильно рассуждаешь.
Исходить из принципа: все клиенты - мошенники.
0% доверия клиенту.
Не хранить у клиента никакой информации.
Клиент - это только рендеринг данных.
Вся логика - на сервере.

Вся логика на сервере. Клиенту отдаются только соевые данные для рендеринга.
Интересует. как в андроид приложениях защититься от подмены данных отправляемых на сервер и быть уверенным, что каждая игра будет честной и без читерства.

Защита от подмены данных делается простым старым дедовским способом - подписью.
На сервере и на клиенте есть одинаковый временный ключ для подписи - signKey - длинная строка.
Клиент отправляет тебе POST-запрос со всеми данными: тип монеты, количество монет, ID юзера,...+ sign=HASH(тип_монеты+количество+userId+...+signKey)
HASH - это хэш-функция. Лучше использовать Bcrypt вместо слабого MD5.
Во-первых, всё делается через HTTPS.
Во-вторых, все операции - через сессии или аутентификацию по JWT.
На сервере ты делашь следующее:
- проверяешь соответствие переданных данных ожидаемым: userId (из JWT), тип монеты и прочее. От клиента ты ожидаешь МИНИМУМ изменяемых данных (количество фишек, например)
- проверяешь все поля на типы данных и ОЧЕНЬ ВАЖНО! - на длину передаваемых значений. Не допускается в строковом поле передавать больше, скажем, 20 символов. Это очень сильно ограничивает брутфорс для поиска коллизии хэша. Количество фишек должно быть целым положительным числом в определённых допустимых пределах (от 0 до 1000, напримр. Чем меньше диапазон, тем лучше)
- делаешь хэш по переданным значениям и сравниваешь его с переданным хэшем от клиента. Если не совпадают - юзер подменил количество монет.
На сервере у тебя должна быть защита от брутфорса: от одного userId, IP-адреса должно приходить не более 1-3 запросов в секунду. Если больше - банить на некоторое время, например, на 1 минуту.

Это то, что касается систем, где данные передаются ОТ пользователя серверу.

В твоём же случае - это просто игра.
И здесь поступают проще.
Всю логику делают на сервере. Юзер кликнул на монету - передаём серверу инфу: click(userId, x,y)
И вот тут включается логика сервера: он смотрит что за юзер кликнул, куда кликнул, как часто, разрешено ли ему это делать... Если всё в порядке, то сервер отправляет клиенту - Ок, вот тебе заработанные 10 монет. Клиент отрисовывает монетки, юзер радуется.
В этом случае полностью исключается подмена юзером количество монет, потому что всё решает сервер. Клиент - это просто терминал для отображения данных и отправки кликов на сервер.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
@historydev
Валера, настало твоё время
Нулевое доверие к клиенту в 100% случаев, в 100% приложений.

Что это значит?
- Клиент кушает
- Бэк кормит

То есть ты никогда не доверяешь клиенту, например расчёт суммы банка или алгоритм тасовки колоды.
Клиент может лишь запросить id выданных ему карт, сумму текущего банка и т.д.
Ответ написан
Комментировать
TrueBers
@TrueBers
Гуглю за еду
Не нужна никакая защита, если у тебя на сервере вся логика, а клиент просто рисует карты и анимации.

Спроектируй стейт-машину на беке адекватную. Если всё правильно сделаешь, у клиента просто не будет возможности что-то подменить, если стейт-машина верная.

Просто отслеживаешь в логах ошибки, когда при одном допустимом множестве действий, приходит недопустимое. Если от определённых игроков такого больше, чем пара штук -- показываешь ему предупреждение, чтоб прекратил. Если продолжается, просто банишь.
Ответ написан
Комментировать
402d
@402d
начинал с бейсика на УКНЦ в 1988
Сперва стоит подумать о своей безапосности - УК РФ Статья 171.2
Если от мошеничества со стороны клиента легко защититься тем, что он
может только сделать ставку/действие и ему переданы только данные карт, которые он вскрыл (получил на руки, козырь и т.д.), размер банка.
То остается момент обмана со стороны сервера. То есть исходная колода и полный лог хода игры. Как это реализовать ?
- А вот эта часть для просто разлекательной игры не нужна. Мы же не пишем казино ?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы