Предложения по (полу) обеспечению высоких результатов в игре Flash / PHP

Question

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

Клиентская сторона - 1. Ключ хранится внутри Flash SWF, который зашифрован с помощью стороннего инструмента. 2. Высокий балл хэшируется вместе со старшим баллом (например, md5 ('ourSecretKey' + 200)) 3. Это значение отправляется через AMF в PHP-скрипт на сервере вместе с рекордом (200)

Сторона сервера - 1. Сервер получает данные и хэширует переданный высокий балл (200) + секретный ключ («ourSecretKey», хранящийся на сервере, а также во Flash) и проверяет по переданному хэшу, соответствует ли значение совпадению, он позволяет высокий балл быть введенным, иначе FAIL.

Я знаю, что это не надежное решение, но будет ли это приемлемым? Я имею в виду, будет ли это достаточной безопасностью в форме рекорда для простой онлайн-игры на Flash? Мысли?

Заранее спасибо!

Answer 1

Для смехотворно короткого значения (т. Е. Значения <64 символов) MD5 в качестве хэша становится неэффективным из-за атак на радужные таблицы, а поскольку отправляемое вами значение будет передано по сети, все, что им нужно сделать, перебор общей тайны (и у них есть известный продукт для работы) </p>

Таким образом, это не закрытый ключ с открытым ключом. это только что поделился секретом.

Кроме того, имейте в виду, что этот общий секрет будет в вашем флеш-файле, который вы отправляете пользователю, который в наши дни будет тривиально разобран, и тогда ваш «секрет» больше не будет секретом.

Вам нужен более сложный механизм ответа-ответа с надлежащей криптографической подписью, в котором для каждой игры с сервера назначается новый ключ подписи, и несколько очков не могут быть отправлены с одним и тем же ключом подписи. (Для дополнительной защиты;))

1. Пользователь запускает игру. Требуется ключ подписи. (ключ знака создается из другого ключа, к которому они не могут получить доступ).
2. Счет подписывается с помощью ключа подписи, а затем отправляется
3. Вы подтверждаете значение знака ключом, который вы им отправили.
4. Вы сбрасываете подписной ключ, который вы им отправили.

Однако, у вас все еще есть проблема, когда у вас нет способа предотвратить подделку действительной системы подсчета очков. Кто-нибудь достаточно умный может просто перепроектировать ваш SWF-объект и внедрить новый код, который просто устанавливает счет на выбранное значение.

Answer 2

Ответ на ваш вопрос, это зависит. Это зависит главным образом от предполагаемой популярности вашей игры.

С точки зрения безопасности, ваше решение примерно так же безопасно, как отправка рекордов в открытом тексте. То, что вы делаете здесь, называется безопасностью по неизвестности, которая, в зависимости от того, кого вы слушаете, может в некоторых случаях иметь свои преимущества. В этом случае, вероятно, обычный пользователь Джо вряд ли сможет взломать его сам. Для тех, у кого есть навыки работы с l33t h4xxor, вы можете отправить все это в открытом тексте. Если все, что вам нужно, это остановить Джо, то, вероятно, этого достаточно, по крайней мере, пока кто-то не создаст поддельный клиент для загрузки Джо (который в зависимости от популярности вашей игры может занять от пары дней до никогда (или быстрее, если WoW)).

Лучшее решение - @Kent Fredric. Однако, как говорится, это не решает проблему создания фальшивого клиента. Решением этого может быть что-то вроде этого:

1. Дайте каждому действию, которое может выполнить игрок.
2. Храните каждое действие, которое игрок выполняет в списке идентификаторов.
3. Когда игра окончена, хешируйте счет, составьте список действий и зашифруйте его открытым ключом, полученным с сервера. (подробности см. в сообщении Кента Фредрика)
4. Отправьте зашифрованный хэш (более часто называемый цифровой подписью) на сервер вместе со счетом и списком выполненных действий.
5. Пусть сервер «играет» в игру в соответствии с действиями в списке.
6. Убедитесь, что тот же результат был достигнут.
7. Убедитесь, что цифровая подпись верна.
8. Обновление списка рекордов сервера.

Это гарантирует две вещи:

1. Счет получен от правильного клиента.
2. Счет правильный в отношении сыгранной игры.

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

Однако это дает немного более сильную гарантию, чем просто использование решения в посте Кента Фредрика. Чтобы решить всю проблему, вы должны будете как-то проверить клиента. Это очень сложно, так как большинство способов сделать это легко обойти.

Наконец, я просто должен был прокомментировать ваш выбор хеш-алгоритма: MD5 - отличный хеш-алгоритм для тех, кто все еще живет в девяностых. Для остальных из нас я рекомендую SHA-2 или хотя бы SHA-1.

Answer 3

Если дистрибуция вашей игры ограничена и игроки не выигрывают реальные деньги / награды, вероятно, вам достаточно исходной схемы.

Использование SWF Encrypt, вероятно, несколько усложнит извлечение ключа, и это может быть хорошим инструментом для использования даже в более продвинутой системе. Но если у вас есть реальная схема с открытым / закрытым ключом (например, RSA), это действительно спорный вопрос, поскольку открытый ключ не является секретом, он не должен быть. И все же, чтобы помешать большинству людей редактировать код и вмешиваться в систему подсчета очков, SWF Encrypt, вероятно, является достаточно хорошим выбором.

---

Просто чтобы сделать вас немного более параноиком, я также написал следующее:

Проблема с SWF Encrypt, как и с большинством других подобных инструментов, заключается в том, что все еще должна быть возможность выполнить сценарий на (возможно скомпрометированном) компьютере. Таким образом, вся информация должна быть доступна на указанной машине. Сравните это с классическим использованием криптографии, отправкой сообщений:

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

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

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

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

Answer 4

Существует один и только один 100% работающий способ шифрования результатов: запись воспроизведения.
Но не просто ЛЮБОЙ повтор, в идеале вы должны записывать только нажатия клавиш пользователя и расстояние между ними. Таким образом, даже если кто-то вмешался в источник или динамически в ОЗУ, воспроизведение, воспроизводимое на сервере, обнаружит проблему.
Это решение, к сожалению, требует огромного количества работы, чтобы быть возможным. Для простоты Вы можете просто вручную проверить все оценки (или лучшие оценки), и вы счастливы. Тем не менее, вам все равно нужно избегать некоторых вещей:

• Генератор случайных чисел по умолчанию, вам нужен генератор Seeded, который всегда дает одинаковые случайные числа для данного семени;
• Нет времени дельта, извините;
• Пользовательские тригонометрические функции (я не уверен на 100%, однажды я слышал, что они могут давать немного разные результаты на разных компьютерах);

И, возможно, больше.
Эта защита, однако, просто нерушима. И требуется время, чтобы закодировать: D.

Answer 5

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

1. Итак, я прошу ключ.
2. Сделай мой рекорд
3. Хэш-рекорд с помощью ключа.
4. Отправить рекорд на сервер
5. Сервер использует отправленный ключ, чтобы вернуть рекорд.

Answer 6

Blockquote Наконец, мне просто нужно прокомментировать ваш выбор алгоритма хеширования: MD5 - отличный алгоритм хеширования для тех, кто еще живет в девяностых. Для остальных из нас я рекомендую SHA-2 или хотя бы SHA-1.

Бах, я знал, что должен был упомянуть SHA:)

Если я использую что-то вроде приложения SWF-шифратора для шифрования SWF-кода, разве это не затруднит доступ к ключу, хранящемуся во Flash? Я бы подумал, что без этого ключа (или, по крайней мере, без легкого доступа к нему) было бы очень трудно выяснить, что используется для генерации хэша, отправляемого на сервер.

Примерно так я и думал: SWF-шифрование

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

Answer 7

Вау

Довольно сложные решения 8).

Я однажды внедрил такую ​​систему. Хотя это не сработает для каждой игры ...

Вы должны повторить игру на сервере. Когда пользователь играет - вы сохраняете «изменения состояния», а затем просто подаете его в игру в каком-то режиме «воспроизведения».