Как защитить проверку на стороне клиента?

#java #android #безопасность #клиент_сервер #криптография

Добрый день!
Есть клиент на андроид. Игра. При наборе определенного количества очков, айдишник
клиента отправляется на сервер и заносится в базу. Собственно, все игровые данные хранятся
на клиенте. Как защититься от умников, которые поймут какой именно запрос отправляются
и будут отправлять его через любой рест-клиент?
Сейчас сервер следит за айпишниками, так же вместе с айди отправляется его хэш+соль,
клиент обвусцирован. Но мне кажется что этого не достаточно. 
Как еще можно защититься? И заодно подскажите как надежнее всего можно зашифровать
соль, которая хранится на стороне клиента, чтобы ее было максимально сложно вытащить.
    

Ответы

Ответ 1

В ответе рядом описывается шифрование и т.п. Надо понимать, что это спасет лишь от
самых неумным умников, которые все что умеют это включить снифер. 

Главное правило - клиенту верить нельзя. Вы не сможете помешать взять ваш клиент,
декомлировать его и собрать новую версию почти такую же как ваша, но где все бонусы
увеличены в 10/100/1000 раз (при этом клиент будет точно так же авторизироваться и
все шифровать). Так же не сможете помешать игроку поменять значения в памяти или вытащить
из памяти сертификат пользуясь рутовских доступом к своему устройству.

Единственное 100% средство это перенести всю логику на сервер (впрочем это тоже не
панацея от всяких ботов, реагирующих быстрее человека). 

Компромиссный вариант отправлять часть информации на сервер и проводить ее валидацию,
например, вы точно знаете что ни один меч не наносит 100000 урона и не один сундук
не дает 100000000 золота и каждый кто пришлет такие данные - читер, которого можно
забанить. При хорошо настроенных правилах нечестные игроки вычисляются достаточно быстро.
При это рекомендуется банить игроков не сразу, а через определенный промежуток времени
(несколько  часов, дней или даже недель), чтобы было сложнее вычислить правила по которым
сервер определяет жулничество.

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


Ответ 2

Описанная вами ситуация - это типовой use case, где должна применяться асимметричная
криптография. Делается это так:

1) У сервера есть пара ключей приватный и публичный (на все случаи жизни)

2) Когда игрок регистрируется на сервере, то на стороне клиента генерируется пара
приватный и публичный ключи

3) Далее клиент и сервер обмениваются публичными ключами

4) Чтобы клиенту и серверу обмениваться данными им необходимо создать сеансовый ключ
по алгоритму:

clientSessionKey=sharedKey(clientPrivateKey, serverPublicKey);
serverSessionKey=sharedKey(serverPrivateKey, clientPublicKey);
//при этом по математике асимметричной криптографии
//clientSessionKey==serverSessionKey - иначе ничего не "взлетает"
// sharedKey() - функция которая диктуется конкретной реализацией асимметричной криптографии


5) Далее все данные шифруем обычным AES с использованием полученного сеансового ключа.

Схема полностью защищенная от всяких умников и проч. Дальше ее можно модифицировать
добавлять соли, выдумывать процедуру ротации сеансовых ключей и проч, но это уже вторично.

Update


  И заодно подскажите как надежнее всего можно зашифровать соль, которая хранится
на стороне клиента


Если вы шифруете соль, то у вас что-то не так с логикой шифрования. Соль нужна не
для того, чтобы ее никто не знал, а для того, чтобы защититься от атаки радужными таблицами

Максимум, что я бы рекомендовал сделать с солью это положить его в другое отличное
от хэша место и плюс немного помутировать ее пусть даже и Цезарем