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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ба, я знал, что мне следовало упомянуть SHA вместо этого :)

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

Я думал примерно так: SWF Encrypt

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

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

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

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

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

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

ух ты

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

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

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