В основному у вас є три вимоги:
- використовувати один ключ для декількох екземплярів клієнта не повинно бути просто,
- генерувати нові дійсні ключі не повинно бути просто
- викрасти ключ законного клієнта не повинно.
Перша частина повинна бути досить простою: просто не дозволяйте двом гравцям одночасно входити в один сервер одним ключем. Ви також можете змусити сервери обмінюватися інформацією про зареєстрованих користувачів або звертатися до спільного сервера автоматизації, так що навіть використання одного і того ж ключа для різних гравців на різних серверах одночасно не вдасться. Ви також, ймовірно, захочете шукати підозрілі зразки використання ключів, і, якщо визначите, що ключ просочився, додайте його до списку заборонених ключів.
У другій частині один із способів - просто підтримувати базу даних усіх дійсних виданих ключів. Поки ключі досить довгі (скажімо, 128 біт або більше) та вибрані випадковим чином (використовуючи захищений RNG), шанси тих, хто вдається вгадати дійсний ключ, по суті дорівнюють нулю. (Навіть набагато більш короткі клавіші можуть бути безпечними, якщо ви використовуєте якесь обмеження швидкості для невдалої спроби входу, щоб зупинити спроби знайти дійсні ключі грубою силою.)
Крім того, ви можете генерувати ключі, взявши будь-який унікальний ідентифікатор і додавши до нього код автентифікації повідомлення (наприклад, HMAC ), обчислений за допомогою секретного головного ключа. Знову ж таки, поки MAC достатньо довгий, шанси кожного, хто не знає, що головний ключ зможе вгадати дійсний MAC для будь-якого ідентифікатора, незначний. Однією з переваг цього методу, крім усунення потреби в базі даних ключів, є те, що ідентифікатором може бути будь-яка унікальна рядок і може кодувати інформацію про клієнта, для якого був виданий ключ.
Одна з проблем використання MAC полягає в тому, що офіційні сервери ігор (або принаймні сервер аутентифікації) повинні знати головний ключ, щоб перевірити MAC, а це означає, що, якщо сервери будуть зламані, головний ключ може просочитися. Одним із способів зменшити цей ризик може бути обчислення декількох MAC для кожного ідентифікатора, використовуючи різні головні ключі, але зберігати лише один з головних ключів на ігрових серверах. Таким чином, якщо цей головний ключ колись просочується і використовується для генерування підроблених ідентифікаторів, ви можете його відкликати та перейти на інший головний ключ. Крім того, ви можете замінити MAC цифровими підписами , які можна перевірити, використовуючи лише відкриту половину головного ключа.
У третій частині, один підхід полягає в тому, щоб переконатися, що клієнт не надсилатиме свій ключ нікому, не перевіряючи, що одержувач справді є законним офіційним сервером. Наприклад, ви можете використовувати SSL / TLS (або DTLS ) для процесу входу, видавати спеціальні сертифікати для своїх ігрових серверів і лише видавати клієнтські довірені сертифікати. Зручно, використання TLS також захищатиме клієнтські ключі (та будь-які інші дані про автоматизацію) від підслуховувачів, наприклад, у загальнодоступних локальних мережах.
На жаль, такий підхід не дозволить стороннім серверам перевірити клієнтські ключі, навіть якщо вони цього хочуть. Ви можете обійти це, встановивши офіційний сервер аутентифікації, яким можуть скористатися сторонні сервери ігор, наприклад, за допомогою входу клієнта на сервер автентифікації та отримання випадкового одноразового маркера, який вони можуть використовувати для входу в ігровий сервер (який потім передає маркер серверу аутентифікації для його перевірки).
Крім того, ви можете видавати своїм клієнтам справжні сертифікати клієнта або щось подібне до них. Ви можете або використовувати існуючий протокол (наприклад, TLS), який підтримує автентифікацію клієнтських сертифікатів (рекомендується), або реалізувати свій власний, наприклад, такий:
- Клієнтський сертифікат складається з довільної рядка ідентифікатора, пари відкритого / приватного ключів та цифрового підпису ідентифікатора та відкритого ключа за допомогою головного ключа.
- Для входу в систему клієнт надсилає свої посвідчення особи, відкритий ключ та підпис. Сервер відповідає за допомогою унікальної рядка виклику (бажано, включаючи ідентифікатор сервера та часову позначку, яку клієнт повинен перевірити), яку клієнт підписує приватним ключем (щоб довести, що він знає ключ) та відправляє підпис серверу.
- Сервер перевіряє обидві підписи, доводячи, що відкритий ключ ID + утворює законний клієнтський ключ (оскільки вони були підписані головним ключем) і що клієнтський ключ фактично належить клієнту (оскільки клієнт може підписати виклик сервера приватним ключ).
(Цей протокол можна додатково спростити, змусивши клієнта створити "виклик", що складається з ідентифікатора сервера та часової позначки, і підписати його. Звичайно, сервер повинен перевірити, чи є ідентифікатор і часова мітка дійсними. Також зауважте, що цей простий протокол, сам по собі, не перешкоджає зловмиснику не мати змоги захопити клієнтський сеанс, хоча це заважатиме їм отримати приватний ключ клієнта, необхідний для майбутніх входів.)