В частности, в отношении последней части вашего вопроса: нет, небезопасно иметь систему небезопасной аутентификации. Пользователи редко бывают просветленными, когда речь заходит о компьютерной безопасности. Пользователи используют тот же пароль для вашей маленькой игры, что и для своей учетной записи Google, учетной записи Facebook, банковского счета и т. Д. Даже если вы можете утверждать, что это их вина в использовании плохих привычек безопасности в Интернете, вы будете нести ответственность, если ваша игра будет использоваться в качестве вектора атаки для кражи учетных данных пользователей. Как разработчик, который знает лучше, единственными этическими вариантами являются правильная защита вашего процесса аутентификации или его отсутствие.
Как некоторые нежелательные, но связанные советы, пользователи не хотят, чтобы их все равно регистрировали в вашей игре. Они могли бы сделать это, если они хотят играть в вашу игру достаточно плохо, но наличие еще одного Freaking Login, на которое можно подписаться, просто отбросит многих потенциальных игроков. Пользователям до смерти надоело создавать новую учетную запись для каждого отдельного сайта, службы и игры, особенно если им требуется какая-либо проверка электронной почты или тому подобное. Если вы можете, либо вообще не входите в систему, либо используйте стороннюю службу аутентификации, с которой пользователи, вероятно, уже имеют учетную запись. Таким образом, у вас будет больше игроков. Это в три раза, если вы планируете иметь какие-либо покупки в приложении.
Веб игры
Популярным вариантом - особенно для веб-игр, хотя он также работает и для традиционных игр - является использование сторонней службы аутентификации на основе Интернета. Facebook и Google имеют хорошо документированные API (оба основаны на стандартизированных API, iirc) для аутентификации. Им требуется возможность открывать окно браузера и направлять пользователя к своим услугам, но это довольно легко сделать на большинстве неконсольных платформ и, конечно, тривиально для веб-игр.
Эти службы позаботятся обо всех беспорядочных деталях шифрования входящего трафика по сети, безопасного хранения учетных данных и проверки пользовательских входов. Тогда вашему игровому серверу нужно реализовать только ту часть протокола, которая получает cookie от пользователя и запрашивает службу аутентификации, является ли cookie действительным или нет, что в большинстве случаев можно сделать с помощью простого HTTP.
Я не буду утверждать, что большинство традиционных многопользовательских игр делают это, потому что они этого не делают, но я буду утверждать, что большинство онлайн-казуальных онлайн-игр делают это.
Для традиционных (не веб-) игр облегчение этой процедуры входа в систему возможно либо путем встраивания браузера (Awesomium, Chromium Embedded Framework, либо прямого набора Webkit, который является популярным выбором), либо путем обращения к внешнему браузеру (для этого нужно еще немного пообщаться). получить файл cookie аутентификации, и это не намного проще, чем встраивание одной из вышеупомянутых библиотек).
Типичным примером такого подхода является любая игра на Facebook.
Традиционные игры с использованием HTTPS
Наличие простого HTTPS-сервиса для входа в систему становится все более нормальным. Во многих играх используются собственные протоколы, но большинство из них неполные (у них безопасный вход в систему, но нет безопасного способа создания / обновления учетной записи, поэтому им все равно нужна служба HTTPS) или они просто ужасно небезопасны.
Вам даже не нужно получать сертификат SSL. Существуют провайдеры хостинга онлайн-приложений, которые предоставляют вам поддомен и используют сертификат SSL с подстановочным знаком. Вы можете разместить свой сервис аутентификации на mygame.someservice.com, на который распространяется подстановочный сертификат * .someservice.com, который поддерживается некоторыми сервисами, и вы готовы к работе.
Идея заключается в том, что пользователь входит в вашу службу, которая генерирует уникальный файл cookie сеанса, который пользователь затем может передать на ваш основной игровой сервер. Затем сервер запрашивает систему входа в систему, является ли cookie действительным для запрашиваемого пользователя. Обычно cookie очень короткий, порядка секунд (например, 15-30), и он, как правило, аннулируется после использования, делая невозможными повторные атаки.
Обратите внимание, что HTTPS - мой самый рекомендуемый вариант, если вы планируете отправлять информацию о платеже по проводам изнутри самого клиента. Однако для этого значительно лучше использовать стороннюю. Если вы думаете, что защитить что-то столь же простое, как пароль, - это слишком много работы, вам даже не захочется даже думать о попытке соблюсти минимальные (и, честно говоря, неадекватные) правила соответствия PCI для хранения и обработки номеров кредитных карт. В любом случае, вы получите более высокий уровень продаж, если пользователи будут использовать доверенные сторонние платежные сервисы, с которыми они уже зарегистрированы.
Одно сильное преимущество отделения вашей службы входа от основного игрового сервера заключается в том, что она позволяет привязывать внешние функции к учетным записям пользователей независимо от игры. У вас могут быть некоторые функции учетной записи (просмотр аватаров или тому подобное) на вашем веб-сайте, или, возможно, вы разрешаете связывать учетные записи Facebook с вашими учетными записями, или, возможно, у вас есть несколько игр, использующих одну базовую платформу учетной записи (например, функции «Галактика в войне» в 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. Например, для некоторых общих библиотек по умолчанию требуется действительный подписанный сертификат от доверенного органа. Некоторые из общих библиотек требуют этого, но по умолчанию не доверяют никаким властям. Некоторые из них не требуют, чтобы сертификат был действительным вообще.
Рекомендуется всегда требовать действующий сертификат. Разрешение недействительных сертификатов не позволит злоумышленнику, который просто подслушивает, украсть пароль, но все равно разрешит атаки «человек посередине».
Этот подход требует абсолютного минимума с точки зрения внешних зависимостей, но при этом обеспечивает максимальную безопасность.
Примеры игр, использующих это, теперь включают в себя большинство больших традиционных MMO.
Безопасные (ish) традиционные игры
Игры, которые не используют отдельный сервис и не используют TLS, обычно должны реализовывать некоторый протокол входа в систему, не основанный на одноразовых номерах, в своем основном протоколе игры. С помощью этого метода сервер генерирует случайное число (одноразовый номер) и отправляет его клиенту. Затем клиент хэширует этот одноразовый номер с паролем пользователя (и именем пользователя, возможно, некоторыми другими данными) и отправляет этот ответ на сервер. Затем сервер сравнивает это хэшированное значение с учетными данными, которые он имеет в файле. Это сохраняет пароль пользователя в тайне и гарантирует, что вы не сможете использовать простую атаку воспроизведения на хешированный пароль, как и многие другие слабые схемы входа в систему на основе хеша.
Проблема заключается в том, что у пользователя нет возможности безопасно передать новый пароль службе по этому протоколу. Типичные реализации также хранят пароль пользователя в виде открытого текста на сервере, что является ужасной практикой (если ваш сервер был взломан, ваш пользователь, вероятно, просто украл свой пароль электронной почты / facebook / bank, потому что он использовал тот же пароль для вашей игры, что и везде, потому что пользователи, как правило, делают это).
Существуют расширенные версии этой базовой схемы входа. Самым основным - хотя и не идеальным - для сервера является отправка хеш-соли пароля со значением nonce во время входа в систему. Это позволяет серверу надежно хранить хешированный (и соленый) пароль, а клиенту генерировать тот же хеш при входе в систему. Это позволяет злоумышленнику получить соль для пароля конкретного пользователя, но это не особенно полезно без получения исходного хешированного пароля (который не передается по сети во время входа в систему). При создании / обновлении пароля клиент отправляет весь хешированный пароль (с солью), который злоумышленник может прослушать. Если используемая хеш-функция достаточно сильна (скажем, sha-2/512), тогда чисто грубое форсирование невозможно, хотя злоумышленник все еще может легко взломать слабые пароли (поэтому важно обеспечить минимальную длину пароля, минимальное распределение букв / цифр / символов и сравнение со словарем известных / очевидных / слабых паролей). Тот факт, что злоумышленник все еще может получить хешированный пароль, делает его более безопасным для полного обмена паролями по защищенному зашифрованному каналу.
Ряд популярных сетевых библиотек игр реализуют некоторые дополнительные формы этого протокола. Я полагаю, что SmartFox - один из таких примеров, хотя я не рассматривал его подробно (я обычно игнорирую любую такую систему аутентификации библиотеки и использую метод HTTPS, поскольку он очень прост в реализации и значительно эффективнее). Многие ранние не-сетевые интернет-игры также использовали этот подход, особенно до появления Steam, XBL и так далее.
Небезопасные традиционные игры
Многие игры, к сожалению, просто отправляют имя пользователя / пароль в виде открытого текста. Может быть, они хэшируют пароль, который в некоторой степени защищает действительный пароль пользователя (не достаточно хорошо), но атака воспроизведения делает вход в игровой сервис тривиальным.
Не делай этого. Это безответственно и лениво. Интернет-наивность 1990-х годов, которая популяризировала эти методы входа, больше не является оправданием.
Многие ранние флеш-игры и веб-игры до Facebook использовали этот подход. Я не знаю каких-либо конкретных примеров из головы; Я хотел бы верить, что они все давно мертвы, но миру просто не повезло.
Нет аутентификации
Большинство игр просто не делают аутентификацию. Игрок соединяется, передает некоторую ручку, чтобы однозначно идентифицировать себя, и начинается матч. Не существует глобального сервера, который пытался бы подтвердить, что только одному настоящему человеку разрешено претендовать на звание «CaptainMisterDude». Локальный сервер просто гарантирует, что только один подключенный в данный момент игрок имеет какой-либо конкретный дескриптор, и на этом все. Локальные серверы используют черные списки на основе имен и IP для тех, кто создает проблемы. Это характерно для игр в стиле FPS deathmatch даже сегодня.
Если вам не нужно какое-либо постоянное состояние для учетных записей, это, безусловно, самое простое решение, и довольно «безопасное», так как там нечего взломать или украсть. Очевидно, что это не очень хорошо работает, если вам нужно хранить информацию об учетной записи между игровыми сессиями.
Quake - это пример игры, использующей этот метод «аутентификации» пользователей.