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

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

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

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

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

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

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

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

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

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

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

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

1. Счет исходит от правильного клиента.
2. Оценка правильна в отношении игры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что-то вроде этого, о чем я думал: SWF Encrypt

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

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

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

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

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

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

Вау

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

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

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