Зокрема, стосовно останнього фрагмента вашого питання: Ні, ніколи не можна пробачити незахищену систему аутентифікації. Користувачі рідко просвітлюються, коли мова йде про безпеку комп'ютера. Користувачі використовують той самий пароль для вашої маленької гри, як і для свого облікового запису Google, облікового запису Facebook, банківського рахунку тощо. Навіть якщо ви можете стверджувати, що вони винні у використанні поганих звичок безпеки в Інтернеті, ви будете нести відповідальність, якщо ваша гра буде використовуватися як вектор атаки для крадіжки облікових даних користувачів. Як розробник, який краще знає, єдиний етичний варіант - належним чином захистити процес аутентифікації або взагалі його не мати.
Як деякі непотрібні, але пов’язані з цим поради, користувачі не хочуть, щоб вони вимагали підписуватися на вашу гру. Вони можуть зробити це, якщо вони захочуть грати у вашу гру досить погано, але, якщо ще один Freaking Login для реєстрації, це просто відігнає багатьох потенційних гравців. Користувачі хворіють на смерть, коли створюють новий обліковий запис для кожного веб-сайту, послуги та гри там, особливо якщо вони потребують перевірки електронної пошти тощо. Якщо ви можете, або взагалі не уникаєте входу або скористаєтесь послугою сторонньої аутентифікації, з якою користувачі, ймовірно, вже мають обліковий запис. У вас буде більше гравців. Це потрійне, якщо ви плануєте робити будь-які покупки через додаток.
Веб-ігри
Популярним варіантом - особливо для веб-ігор, хоча він працює і для традиційних ігор - є використання веб-сервісу сторонньої аутентифікації. Facebook і Google мають добре задокументовані API (обидва базуються на стандартизованих API, iirc) для аутентифікації. Вони вимагають можливості відкрити вікно браузера і направити користувача на свої послуги, але це зробити досить просто на більшості неконсольних платформ, і, звичайно, тривіально для веб-ігор.
Ці служби дбають про всі безладні деталі шифрування трафіку входу через провід, надійного зберігання облікових даних для входу та перевірки реєстраційних даних користувачів. Тоді вашому ігровому серверу потрібно лише реалізувати частину протоколу, який отримує файл cookie від користувача, і запитує службу аутентифікації, якщо файл cookie дійсний чи ні, що в більшості випадків можна зробити за допомогою простого HTTP.
Я не претендую на те, що більшість традиційних багатокористувацьких ігор роблять це, тому що вони цього не роблять, але я скажу, що більшість онлайн-випадкових веб-ігор роблять це.
У традиційних іграх (не для Інтернету) полегшити цю процедуру входу можна, або вбудувавши браузер (Awesomium, Chromium Embedded Framework, або прямий веб-сайт, який є популярним вибором), або зателефонувавши до зовнішнього веб-переглядача (для цього знадобиться ще деяка помилка вийміть файл cookie з автентичності, і це насправді не простіше, ніж вставити одну з вищезгаданих бібліотек).
Типовим прикладом такого підходу є будь-яка гра у Facebook.
Традиційні ігри за допомогою HTTPS
Наявність простого сервісу HTTPS для входу стає дедалі нормальнішим. У багатьох іграх використовуються власні протоколи, але більшість з них є неповними (у них є безпечний логін, але немає безпечного способу створення / оновлення облікового запису, тому їм так чи інакше потрібна послуга HTTPS) або просто жахливо небезпечно.
Вам навіть не потрібно займатись отриманням спеціального сертифікату SSL. Є інтернет-провайдери хостингу додатків, які надають вам субдомен та використовують символи SSL-символів. Ви можете розмістити службу аутентифікації на сайті mygame.someservice.com, на яку поширюється сертифікат * .someservice.com, який підтримує деякий сервіс, і ви готові йти.
Ідея тут полягає в тому, щоб користувач увійшов у вашу службу, яка генерує унікальний сесійний файл cookie, який користувач може передати на ваш основний ігровий сервер. Потім сервер запитує систему входу, чи cookie дійсний для запитуваного користувача. Зазвичай у файлі cookie є дуже короткий час очікування (приблизно 15-30, наприклад), і він, як правило, недійсний один раз, коли використовується, що робить атаки повторного відтворення неможливими.
Зауважте, що HTTPS є моїм найбільш рекомендованим варіантом, якщо ви плануєте надсилати платіжну інформацію по дроті зсередини самого клієнта. Однак для цього значно краще використовувати сторонніх. Якщо ви вважаєте, що захистити щось настільки просто, як пароль - це занадто велика робота, ви навіть не хочете думати про те, щоб намагатися відповідати мінімальним (і, чесно кажучи, досить неадекватним) правилам відповідності PCI для зберігання та обробки номерів кредитних карток. Ви все одно матимете кращі результати продажів, якщо у вас користувачі будуть користуватися надійними сторонніми платіжними послугами, про які вони вже працюють.
Однією з вагомих переваг відділення служби входу від основного ігрового сервера є те, що вона дозволяє прив’язувати зовнішні функціональні можливості до облікових записів користувачів незалежно від гри. Можливо, на вашому веб-сайті є деякі функції облікового запису (перегляд аватарів чи подібних) або, можливо, ви дозволяєте пов'язувати облікові записи Facebook зі своїми обліковими записами, або, можливо, у вас є кілька ігор, що обмінюються однією базовою платформою облікового запису (наприклад, функції Galaxy at War Mass Mass Effect 3).
Популярна прикладна гра, яка використовує HTTPS для аутентифікації - Minecraft.
Стороння веб-аутентифікація з іграми для власних клієнтів
Можливе використання сторонніх сервісів, таких як Facebook Connect або Google з рідним клієнтом. Наприклад, у Facebook є вбудований SDK для iOS та Android, як і Google. Деякі сервіси також мають вбудовані SDK для традиційних клієнтів ПК.
Якщо цільова служба не має вбудованого SDK і вимагає використання веб-браузера, ви можете просто вбудувати браузер у свою гру. Однак деякі користувачі можуть з недовірою використовувати вбудований браузер для введення інформації для входу.
Ви також можете використовувати зовнішній браузер. Є кілька способів вирішити це. Деякі вимагають трохи більше інтеграції в ОС, ніж інші. Деякі вимагають, щоб у вас був зовнішній веб-сервіс, який працює поряд (або принаймні доступний для вас) основним сервером ігор. Зауважте, що оскільки для Facebook та Google зазвичай потрібна автентифікована URL-адреса, для використання цих протоколів у (майже) всіх випадках вам знадобиться цільова сторінка загальнодоступного веб-сайту.
Найбезпечніший і надійний, якщо не зовсім простий, - це відмовитись від вашого клієнтського запиту через ваш головний веб-сайт. Ваш клієнт підключається до основного сервера ігор як аутентифікований гість користувача та отримує унікальний маркер сеансу. Ігровий сервер не дозволяє клієнту реально багато робити, перебуваючи в цьому стані; гра не знає, хто такий гравець, тому гравець ще не може спілкуватися, розпочати матч тощо.
Потім клієнт запускає зовнішній браузер, що вказує на вхідну URL-адресу домену вашої гри, передаючи цей маркер сеансу як параметр у URL-адресі. Потім сайт проходить через звичайне рукостискання для входу в Facebook / Google.
На даний момент ваш веб-сервер знає, що користувач увійшов у систему, і може пов’язати це з маркером сеансу, отриманим від клієнта. Потім ця верифікація може бути передана на ігровий сервер, піднявши несанкціонований гостьовий зв’язок клієнта на аутентифікований сеанс користувача. Це можна зробити, якщо веб-сервер, можливо, безпосередньо спілкується з ігровим сервером. Або ігровий сервер може періодично опитувати веб-сервер щодо стану автентифікації очікуваних з'єднань. Або клієнт може періодично опитувати веб-сервер, щоб побачити, чи логін завершений, і, коли він є, подати сигнал ігровому серверу, щоб він вимагав підтвердження від веб-сервера.
Все це вимагає, щоб ваш ігровий сервер та веб-сервер мали змогу спілкуватися, але будь-яка сторона-сервіс аутентифікації вимагатиме від вашого ігрового сервера змоги спілкуватися із зовнішнім світом, тому це не повинно бути сюрпризом.
Цей метод аутентифікації знайдено в деяких ММО середнього та середнього розміру.
Зауважте, що все це також працює для здійснення платіжних запитів через зовнішню службу, наприклад PayPal, Amazon Payments, Google Wallet тощо.
Пряме підключення TLS
Запустити сеанс TLS через нестандартний протокол не надто складно. Бібліотеки, такі як OpenSSL, GnuTLS, NSS та різні ОС-бібліотеки, забезпечують API обтікання потоку, який переходить на транспорт / протокол низького рівня. Зазвичай вам просто потрібно подавати байти через API обгортки, і це стосується рукостискання та шифрування.
Тут складні деталі забезпечують безпечне використання TLS. Наприклад, для деяких загальних бібліотек за замовчуванням потрібен дійсний підписаний сертифікат від довіреного органу. Деякі з загальних бібліотек вимагають цього, але за замовчуванням не довіряють жодним органам. Деякі з них не вимагають, щоб сертифікат взагалі був дійсним.
Рекомендується завжди вимагати дійсний сертифікат. Дозвіл недійсних сертифікатів не дозволить зловмиснику, який просто підслуховує, вкрасти пароль, але він все одно дозволить атакам "середнього".
Такий підхід вимагає абсолютного мінімуму з точки зору зовнішніх залежностей, але все ж дозволяє максимальну безпеку.
Приклади ігор, які використовують це, тепер включають більшість традиційних ММО.
Захищені традиційні ігри
Іграм, які не використовують окремий сервіс і не використовують TLS, зазвичай доводиться реалізовувати якийсь протокол входу на основі безнадійних даних у свій основний протокол гри. За допомогою цього методу сервер генерує випадкове число (без нуля) і відправляє його клієнту. Потім клієнт хеширує це питання паролем користувача (і ім'ям користувача, можливо, деякими іншими даними) і надсилає цю відповідь серверу. Потім сервер порівнює це хешоване значення з обліковими даними, які є у файлі. Це зберігає пароль користувача окремо по дроту і гарантує, що ви не можете використовувати просту атаку повторного повторення на хешований пароль, як і багато інших слабких схем входу на основі хешу.
Проблема полягає в тому, що користувач не може надійно подати новий пароль сервісу через цей протокол. Типові реалізації також зберігають пароль користувача у простому тексті на сервері, що є жахливою практикою (якщо ваш сервер зламається, у вашого користувача, ймовірно, був вкрадений пароль електронної пошти / facebook / банку, тому що він використовував той самий пароль для вашої гри, як скрізь, оскільки користувачі схильні це робити).
Існують розширені версії цієї основної схеми входу. Найголовніше - хоча все ще не ідеально захищене - сервер надсилає хеш-сіль пароля зі значенням nonce під час входу. Це дозволяє серверу надійно зберігати хешований (і солоний) пароль, дозволяючи клієнту генерувати той самий хеш під час входу. Це дає змогу зловмиснику отримати сіль для пароля конкретного користувача, але це не особливо корисно без отримання оригінального хешованого пароля (який не надсилається по дроту під час входу). Під час створення / оновлення пароля клієнт надсилає весь хешований пароль (з сіллю), який зловмисник може нюхати. Якщо використовувана хеш-функція є досить сильною (скажімо, sha-2/512), то чисте насильство не може бути здійснене, хоча зловмисник все ще може легко побивати слабкі паролі (саме тому важливо застосовувати деяку мінімальну довжину пароля, мінімальний розподіл літер / цифр / символів та порівняння зі словником відомих / очевидних / слабких паролів). Справа в тому, що зловмисник може все-таки отримати хешований пароль, тому все-таки більш безпечно робити весь обмін паролем через захищений, зашифрований канал.
Ряд популярних ігрових мереж-бібліотек реалізує певну необов'язкову форму цього протоколу. Я вважаю, що SmartFox є одним із таких прикладів, хоча я не розглядав це глибоко (я взагалі ігнорую будь-яку подібну систему аутентифікації бібліотеки і використовую метод HTTPS, оскільки це мертвий простий у здійсненні і значно сильніше). Ряд ранніх не-веб-ігор також використовував цей підхід, особливо до появи Steam, XBL тощо.
Небезпечні традиційні ігри
Багато ігор, на жаль, просто надсилають ім’я користувача / пароль в простому тексті. Можливо, у них є хеш-пароль, який розпливчасто захищає фактичний пароль користувачів (не дуже добре), але атака повторного перетворення робить вхід у службу ігор тривіальним.
Не робіть цього. Це безвідповідально і ліниво. Інтернет-наївність 1990-х, яка популяризувала ці методи входу, вже не є привідним приводом.
Багато ранніх флеш-ігор та веб-ігор, що передували Facebook, застосували такий підхід. Я не знаю жодних конкретних прикладів у верхній частині голови; Я хотів би повірити, що всі вони давно померли, але світ просто не такий щасливий.
Немає автентифікації
Більшість ігор просто не роблять аутентифікацію. Гравець підключається, передає якусь ручку, щоб однозначно ідентифікувати себе, і починається поєдинок. Немає глобального сервера, який намагається підтвердити, що тільки одному реальному людині дозволяється претендувати на "CaptainMisterDude". Локальний сервер просто гарантує, що тільки один підключений на даний момент програвач має будь-яку конкретну ручку, і на цьому все закінчено. Локальні сервери використовують чорний список на основі імен та IP-адрес для вирішувачів проблем. Це є загальним для ігор у стилі Deathmatch FPS навіть сьогодні.
Якщо вам не потрібен постійний стан для облікових записів, це, безумовно, найпростіше рішення і досить "безпечне", оскільки насправді немає нічого, щоб насправді зламати чи вкрасти. Очевидно, це не надто добре, якщо вам потрібно зберігати інформацію облікового запису між ігровими сеансами.
Quake - приклад гри, що використовує цей метод "автентифікації" користувачів.