Аутентифікація для багатокористувацької гри через розетки


11

Я реалізую спеціальний бінарний протокол для нової багатокористувацької гри, над якою працюю. Це покрокова стратегічна гра, тому терміни дійсно не мають значення. Наразі у мене завершена основна частина системи синхронізації даних, і мені було цікаво, як зазвичай вхід / вихід із системи та шифрування користувача зазвичай роблять для ігор MMORPG або подібних.

  • Чи можете ви порекомендувати схему безпечної / таємної передачі пароля під час входу? (Обмін ключами Diffie-Hellman?)
  • Як здійснити сильне шифрування пакетів даних? (AES 128-розрядна? .. або за якоюсь схемою цього публікації називається "шифруванням сильнішим, ніж ви, швидше за все, зламаєте")
  • Чи існують схеми форматування дейтаграми, які допомагають загартувати ігровий сервер для відтворення атак, недійсних пакетів даних тощо?

Відповіді:


15

Відповіді

  • SRP - Безпечний віддалений пароль - на основі Diffie-Hellman. Ідея полягає в тому, що ви можете зробити взаємну перевірку пароля, фактично ніколи не передаючи пароль або будь-яку інформацію, яка може бути використана для його отримання. Незважаючи на те, що це надійно за допомогою дроту, ви все одно маєте хешувати і солити свої паролі, оскільки ваш сервер ніколи не повинен зберігати їх у простому тексті .
  • Перевага SRP полягає в тому, що після його завершення він також дає ключ взаємного узгодження ключа шифрування, який зловмисник не зміг би вивести з огляду на передані вами дані. Це означає, що ви можете безкоштовно використовувати симетричний алгоритм шифрування (наприклад, AES), коли користувач перевіряє автентифікацію.
  • Якщо припустимо, що ви використовуєте UDP з власною надійною / впорядкованою (орієнтованою на з'єднання) реалізацією поверх нього: зашифруйте всю програму UDP, включаючи ваш номер послідовності пакетів. Якщо ваша система сконструйована правильно, вона автоматично відкидає відтворені повідомлення, і зловмисник не зможе змінити номер послідовності пакету, оскільки він зашифрований (таким чином, повторна версія можлива - але вона буде автоматично ігнорована).

Думки

Чи має бути ваша автентифікація безпечною? Абсолютно. Не робіть жодних компромісів з точки зору безпеки, коли пароль під питанням. Таким чином, ви, безумовно, повинні розглянути перший кулю моєї відповіді.

Чи повинні ваші дані бути захищеними? Тільки якщо це купівля / мікро-транзакція в грі - і чому б тоді просто не використати щось випробуване та справжнє, наприклад HTTPS. Шифрування трафіку ігор, мабуть, не є прийнятним рішенням з наступних причин:

  • Це повна параноїя.
  • Це додасть накладні витрати на процесор на вашому сервері, якщо ви не зможете придбати (дорогі) апаратні модулі шифрування.
  • Не має значення, яку безпеку ви забезпечуєте своїми даними по дроту - хтось може захопити клієнтський процес та перехопити повідомлення в той момент, перш ніж вони зашифровані та надіслані. Це не тільки можливість, але і нескінченно більш можлива, як суттєво простіше ввести код порівняно з перехоплюючими пакетами. Якщо ви робите це для запобігання накруткам, ви повністю і повністю витрачаєте свій час.
    • Що стосується безпеки пароля, то, на жаль, нічого не можна зробити з приводу викраденої системи, клієнт став ворожим. Ключі Blizzards WoW розроблені для вирішення цього питання - але я не впевнений, наскільки це безпечно (особливо якщо ви залишите його підключеним).

Будь ласка, якщо ви шифруєте для запобігання читів, відмовтесь від цього. Ви збираєтесь коротко - я дав вам інформацію, якщо ви цього не зробите. Пам’ятайте, що ви можете вибірково зашифровувати пакети першим байтом у пакеті, що вказує, і індикатор того, чи решта зашифровані: хоча, ще раз, я б дотримувався HTTPS, якщо вам потрібно робити такі речі, як транзакції кредитною карткою: вони надзвичайно рідкісні та HTTPS розроблений фахівцями - на відміну від того, що ви або я розробили.

Все, що сказано, Blizzard насправді шифрує свій трафік WoW. Основна причина цього зламання полягає в тому, що хтось, імовірно, повноцінний аматор, вирішив спробувати свої сили в алгоритмі шифрування в домашніх умовах; це дуже добре вимкнено . Навіть якщо ви користуєтесь стандартними алгоритмами, є хороший шанс, що хтось перепрограмує ваш код і змоделює його - як тільки клієнт вводить свій пароль, немає повідомлення про те, що підключена непідтримувана система.


2
+1 за те, що зашифровувати пакети даних для запобігання чіт-колам марно. ОП: перевіряйте все, що отримуєте від клієнта, виконайте перевірку чистоти, двічі перевіряйте, чи можлива дія, яку вимагав клієнт, перевіряйте дальність зброї, швидкість руху тощо, але не витрачайте час на забезпечення свого клієнта, оскільки він буде зламаний, якщо ваша гра того варта. Деякі компанії MMO шифрують та замовчують своїх клієнтів / протоколів, але це не запобігає обману, а ускладнить, наприклад, творцям ботів отримання хороших результатів, і навіть це робиться спеціалізованими командами експертів.
Ґілеад

1
Незначна суперечка щодо вашої третьої відповіді: просто шифрування пакетів може виявитися недостатньо для запобігання фальсифікації, оскільки багато схем шифрування принаймні дещо вигідні . Для захисту цілісності повідомлення вам потрібен або MAC, або автентифікований режим шифрування .
Ільмарі Каронен

+1 Дякую за дуже повну відповідь. Розглядаємо реалізацію SRP прямо зараз. Які ви рекомендації щодо хеш-функції, яка використовується для паролів? MD5? Яким би був протокол OTR (Off the Record) для такого випадку використання? буде добре працювати для auth / crypto замість SRP? Якщо я використовую SRP, чи потрібно мені використовувати один із наступних режимів "автентифікованого шифрування"? (OCB 2.0, Key Wrap, CCM, EAX, Encrypt-then-MAC та GCM)
Robinicks

1
@Jenko використовуйте алгоритми сімейства SHA (ймовірно, SHA1) - вам слід уникати MD5 в ці дні. OTR дійсно не те , що ви повинні дивитися - він не призначений , щоб бути безпечним / затемнити (насправді його спроектована таким чином, що хто - то може більш легко підробити пакети) він також призначений для обміну миттєвими повідомленнями , а не зв'язки машини. Жоден із цих режимів не потрібен, просто використовуйте SRP: після того, як у вас є симетричний ключ із взаємним узгодженням, просто можливість зашифрувати щось є достатньо гарантією того, що ви розмовляєте з правильною третьою стороною. Також знову перечитайте два мої останні два абзаци.
Джонатан Дікінсон

1
Насправді, у мене є ще краща пропозиція: використовуйте існуючий DTLS над реалізацією UDP і не намагайтеся прокрутити свій власний. Це заощадить ваш час, і є багато дрібних, але критичних деталей, які легко помилитися, якщо спробувати створити свій власний шар шифрування дейтаграми.
Ільмарі Каронен

2

Я думаю, що мій останній коментар до інакшого відмінного відповіді Джонатана варто розширити у власну відповідь:

Якщо у вас немає багато досвіду криптовалюти, вам не слід намагатися розробити свій власний шар шифрування, якщо ви зможете його уникнути. Якщо ви робите багато криптографічного досвід, ви повинні знати краще , ніж створити свій власний рівень шифрування , якщо ви можете уникнути цього.

Натомість спробуйте знайти існуючу, стандартизовану та добре перевірену криптобібліотеку, яка робить все, що вам потрібно. У вашому випадку я рекомендую GnuTLS , який, згідно Вікіпедії , забезпечує як аутентифікацію TLS-SRP ( RFC 5054 ), так і захищений UDP-зв'язок з DTLS ( RFC 6347 ). Перший піклується про вхід у систему, а другий захищає захищений таким чином канал, який формується як від підслуховування, так і від активних атак, і навіть може захистити вас від атак повторного відтворення .


Я використовую TCP. Це дуже різний вид гри для конкретного клієнта. Подібно до азартних ігор / ставок, вся інформація, яка може бути використана для викрадення процесу, збільшує шанси на отримання зайвих втрат. Нам потрібно зберігати дані надзвичайно безпечно, адже інформація в цьому випадку - це гроші.
Робінікс

Гаразд, якщо ви використовуєте TCP, тоді це ще простіше: ви можете використовувати звичайний TLS 1.2 замість DTLS, що дає більше варіантів на вибір. Я все ж рекомендую бібліотеку GnuTLS.
Ільмарі Каронен

Я трохи проведу дослідження і побачу, чи можу я посилатися на вихідний код TLS як на стороні клієнта, так і на сервері, і буду базувати свій протокол навколо того, що він робить. Це було б досить сильно? По суті, це просто шифрування пакетів з деяким шифром / режимом, правильно?
Робінікс

Ні, у протоколі TLS є зовсім небагато більше, ніж у цьому. Ось чому ви хочете використовувати стандартну бібліотеку, яка реалізує її, а не прокручувати власну.
Ільмарі Каронен
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.