特に質問の最後の部分に関して：いいえ、安全でない認証システムを持つことは決して許されません。コンピューターのセキュリティに関して、ユーザーが啓発されることはほとんどありません。ユーザーは、自分の小さなゲームでも、Googleアカウント、Facebookアカウント、銀行口座などと同じパスワードを使用します。貧弱なインターネットセキュリティ習慣を使用することのせいだと主張できたとしても、ユーザーのログイン資格情報を盗むための攻撃ベクトルとしてゲームが使用された場合、あなたが責任を負うことになります。よりよく知っている開発者として、唯一の倫理的オプションは、認証プロセスを適切に保護するか、認証プロセスをまったく持たないことです。
求められていないが関連するアドバイスとして、ユーザーはとにかくゲームにサインアップする必要はありません。彼らがあなたのゲームをひどくプレイしたいなら彼らはそうするかもしれませんが、サインアップするためにもう一つの異常ログインを持っていることは多くの潜在的なプレーヤーを追い払うつもりです。特に、あらゆる種類の電子メール検証などが必要な場合、ユーザーはサイト、サービス、およびゲームごとに新しいアカウントを作成することにうんざりしています。可能な場合は、ログインしないようにするか、ユーザーが既にアカウントを持っている可能性のある既存のサードパーティ認証サービスを使用します。そうすればより多くのプレイヤーがいるでしょう。何らかの種類のアプリ内購入を予定している場合、これは3倍になります。
ウェブゲーム
一般的なオプション-特にWebゲームでは、従来のゲームでも機能しますが-は、Webベースのサードパーティ認証サービスを使用することです。FacebookとGoogleの両方には、認証用に十分に文書化されたAPI（両方とも標準化されたAPI、iircに基づいています）があります。ブラウザウィンドウを開いてユーザーをサービスに誘導する必要がありますが、ほとんどの非コンソールプラットフォームでこれを行うのは非常に簡単で、もちろんWebゲームでは簡単です。
これらのサービスは、回線上のログイントラフィックの暗号化、ログイン資格情報の安全な保存、およびユーザーログインの検証に関する面倒な詳細をすべて処理します。ゲームサーバーは、ユーザーからCookieを受信し、Cookieが有効かどうかを認証サービスに要求するプロトコルの部分のみを実装する必要があります。これは、ほとんどの場合、単純なHTTPで実行できます。
従来のマルチプレイヤーゲームのほとんどがこれを行うとは主張しませんが、ほとんどのオンラインカジュアルWebゲームはこれを行うと主張します。
従来の（非Web）ゲームの場合、ブラウザ（Awesomium、Chromium Embedded Framework、またはストレートアップWebkitが一般的な選択肢）を埋め込むか、外部ブラウザを呼び出すことにより、このログイン手順を容易にすることができますただし、認証Cookieを取得し、前述のライブラリのいずれかを埋め込むよりも簡単ではありません）。
このアプローチの典型的な例は、Facebookゲームです。
HTTPSを使用した従来のゲーム
ログイン用の単純なHTTPSサービスを使用することがますます一般的になっています。多くのゲームはカスタムプロトコルを使用しますが、これらのほとんどは不完全です（安全なログインがありますが、アカウントを作成/更新する安全な方法がないため、とにかくHTTPSサービスが必要です）か、恐ろしく安全ではありません。
カスタムSSL証明書を取得する必要さえありません。サブドメインを提供し、ワイルドカードSSL証明書を使用するオンラインアプリホスティングプロバイダーがあります。認証サービスをmygame.someservice.comに置くことができます。mygame.someservice.comは、Some Serviceが保持する* .someservice.comワイルドカード証明書でカバーされているので、準備完了です。
ここでの考え方は、ユーザーがサービスにログインすると、一意のセッションCookieが生成され、ユーザーはそれをメインゲームサーバーに渡すことができるということです。サーバーは、要求されたユーザーに対してCookieが有効かどうかをログインシステムに尋ねます。通常、Cookieには非常に短い秒単位のタイムアウト（15〜30など）があり、通常、使用すると無効になり、リプレイ攻撃が不可能になります。
クライアント自体の内部から有線で支払い情報を送信する場合は、HTTPSが最も推奨されるオプションであることに注意してください。ただし、これにはサードパーティを使用することをお勧めします。パスワードと同じくらい簡単なものをセキュリティで保護するのが面倒であると考える場合、クレジットカード番号を保存および処理するための最小限の（そして正直なところ非常に不十分な）PCIコンプライアンスルールを満たそうとさえ考えたくはありません。いずれにせよ、すでに登録されている信頼できるサードパーティの支払いサービスをユーザーが使用している場合、とにかく売上が向上します。
ログインサービスをメインゲームサーバーから分離することの1つの大きな利点は、ゲームとは無関係に外部機能をユーザーアカウントに結び付けることができることです。Webサイトにアカウント機能（アバターなどを表示）がある場合、またはFacebookアカウントをアカウントにリンクできるようにしている場合、または単一の基礎となるアカウントプラットフォームを共有する複数のゲームがある場合（Mass EffectのGalaxy at War機能など） 3）。
HTTPSを認証に使用した人気のあるゲーム例はMinecraftです。
ネイティブクライアントゲームを使用したサードパーティWeb認証
Facebook ConnectやGoogleなどのサードパーティサービスをネイティブクライアントで使用することができます。たとえば、FacebookにはiOSとAndroid用のネイティブSDKがあり、Googleも同様です。同様に、一部のサービスには、従来のPCクライアント用のネイティブSDKがあります。
ターゲットサービスにネイティブSDKがなく、Webブラウザーの使用が必要な場合は、ゲームにブラウザーを埋め込むことができます。ただし、一部のユーザーは、埋め込みブラウザを使用してログイン情報を入力することに不信感を抱いている場合があります。
外部ブラウザを使用することもできます。これを実現する方法はいくつかあります。他のものよりも少しOS統合が必要なものもあります。メインのゲームサーバーと一緒に（または少なくとも到達可能な）外部Webサービスを実行する必要があるものもあります。FacebookとGoogleは通常、認証されたURLを必要とするため、これらのプロトコルを（ほとんど）すべての場合に使用するには、公開Webサイトのランディングページが必要です。
最も簡単ではないにしても、最も確実で信頼性の高い方法は、メインWebサイトを通じてクライアントからのログイン要求をバウンスすることです。クライアントは、認証されたゲストユーザーとしてメインゲームサーバーに接続し、一意のセッショントークンを受け取ります。ゲームサーバーは、クライアントがこの状態にある間に実際に多くのことを行うことを許可しません。ゲームはプレイヤーが誰であるかを知らないため、プレイヤーはまだチャットしたり、試合を開始したりすることはできません。
次に、クライアントはゲームのドメインのログインURLを指す外部ブラウザーを起動し、このセッショントークンをURLのパラメーターとして渡します。その後、サイトはFacebook / Googleの通常のログインハンドシェイクを実行します。
この時点で、Webサーバーはユーザーがログインしていることを認識し、クライアントから受信したセッショントークンに関連付けることができます。この検証はゲームサーバーに伝達され、クライアントの認証されていないゲスト接続を認証されたユーザーセッションに昇格させます。これは、可能であれば、ウェブサーバーがゲームサーバーと直接通信することで実現できます。または、ゲームサーバーは、保留中のゲスト接続の認証ステータスについてウェブサーバーを定期的にポーリングできます。または、クライアントは定期的にWebサーバーをポーリングして、ログインが完了したかどうかを確認し、完了したら、ゲームサーバーにWebサーバーからの検証を要求するように信号を送ることができます。
これらはすべて、ゲームサーバーとWebサーバーが通信できる必要がありますが、サードパーティの認証サービスでは、ゲームサーバーが外部と通信できる必要があるため、これは驚くべきことではありません。
この認証方法は、一部の小規模から中規模のMMOで使用されています。
これはすべて、PayPal、Amazonペイメント、Googleウォレットなどの外部サービスを介して支払い要求を行う場合にも機能することに注意してください。
直接TLS接続
カスタムストリームプロトコルでTLSセッションを開始することはそれほど難しくありません。OpenSSL、GnuTLS、NSSなどのライブラリ、およびさまざまなOS固有のライブラリは、低レベルのトランスポート/プロトコルを重ねるストリームラッパーAPIを提供します。通常、ラッパーAPIを介してバイトをフィードするだけで、ハンドシェイクと暗号化を処理します。
ここで注意が必要な部分は、TLSの使用が安全であることを保証しています。たとえば、一般的なライブラリの一部では、デフォルトで信頼できる機関からの有効な署名付き証明書が必要です。いくつかの一般的なライブラリはそれを必要としますが、デフォルトではどの機関も信頼しません。それらのいくつかは、証明書がまったく有効であることを要求しません。
常に有効な証明書を要求することをお勧めします。無効な証明書を許可しても、盗聴しているだけの攻撃者はパスワードを盗むことはできませんが、中間者攻撃は可能です。
このアプローチは、最大限のセキュリティを確保しながら、外部依存関係の点で絶対に最小限を必要とします。
現在、これを使用するゲームの例には、ほとんどの大きな伝統的なMMOが含まれています。
安全な（伝統的な）伝統的なゲーム
別個のサービスを使用せず、TLSを使用しないゲームでは、通常、メインゲームプロトコルに何らかのノンスベースのログインプロトコルを実装する必要があります。この方法では、サーバーは乱数（ナンス）を生成し、それをクライアントに送信します。その後、クライアントはそのナンスをユーザーのパスワード（およびユーザー名、場合によっては他のデータ）でハッシュし、その応答をサーバーに送信します。サーバーは、このハッシュ値をファイルにある資格情報と比較します。これにより、ユーザーのパスワードはネットワーク上で秘密になり、他の多くの弱いハッシュベースのログイン方式のように、ハッシュされたパスワードに対して単純なリプレイ攻撃を使用できなくなります。
問題は、ユーザーがこのプロトコルを介して安全に新しいパスワードをサービスに送信する方法がないことです。典型的な実装では、ユーザーのパスワードを平文でサーバーに保存しますが、これは恐ろしい習慣です（サーバーがハッキングされた場合、おそらくユーザーはゲームと同じパスワードを使用していたため、メール/ Facebook /銀行のパスワードが盗まれただけです）ユーザーはそうする傾向があるため）
その基本的なログインスキームの拡張バージョンがあります。最も基本的な（まだ理想的ではありませんが）のは、サーバーがログイン中にナンス値を含むパスワードハッシュソルトを送信することです。これにより、サーバーはハッシュされた（およびソルトされた）パスワードを安全に保存でき、クライアントはログイン時に同じハッシュを生成できます。これにより、攻撃者は特定のユーザーのパスワードのソルトを取得できますが、元のハッシュ化されたパスワード（ログイン中にネットワーク経由で送信されない）も取得しないと、特に役に立ちません。パスワードの作成/更新中に、クライアントはハッシュされたパスワード全体（ソルト付き）を送信し、攻撃者はそれを盗聴できます。使用されるハッシュ関数が十分に強力な場合（たとえば、sha-2 / 512）、純粋なブルートフォーシングは実行不可能です。ただし、攻撃者は簡単に弱いパスワードを簡単に総当たり攻撃することができます（そのため、パスワードの最小長、文字/数字/記号の最小配布、および既知/明白/弱いパスワードの辞書との比較が重要です）。攻撃者がまだハッシュされたパスワードを取得できるという事実は、セキュリティで保護された暗号化されたチャネルを介してパスワード交換全体を行う方がより安全である理由です。
多くの一般的なゲームネットワーキングライブラリは、このプロトコルのオプション形式を実装しています。SmartFoxはそのような例の1つであると思いますが、詳しくは調べていません（このようなライブラリ認証システムは無視して、HTTPSメソッドを使用します。特にSteamやXBLなどが登場する前は、多くの初期の非Webインターネットゲームもこのアプローチを使用していました。
安全でない従来のゲーム
多くのゲームでは、残念ながらプレーンテキストでユーザー名/パスワードを送信するだけです。パスワードをハッシュし、ユーザーの実際のパスワードをあいまいに保護しているかもしれません（ほぼ十分ではありません）が、リプレイ攻撃はゲームサービスへのログインを簡単にします。
これをしないでください。無責任で怠け者です。これらのログイン方法を普及させた1990年代のインターネットの素朴さは、もはや実行可能な言い訳ではありません。
多くの初期のFacebook以前のFlashおよびWebゲームは、このアプローチを採用していました。頭の上の特定の例は知りません。私は彼らがすべて死んでいると信じたいのですが、世界はそれほど幸運ではありません。
認証なし
ほとんどのゲームは認証を行いません。プレーヤーは接続し、ハンドルを送信して自分を一意に識別し、試合が始まります。「CaptainMisterDude」であると主張することができるのは1人の実在の人間のみであることを検証しようとするグローバルサーバーはありません。ローカルサーバーは、現在接続されている1人のプレーヤーだけが特定のハンドルを持つことを保証するだけで、それで終わりです。ローカルサーバーは、トラブルメーカーのために名前ベースおよびIPベースのブラックリストを使用します。これは、今日でもFPSデスマッチスタイルのゲームで一般的です。
アカウントに永続的な状態が必要ない場合は、これがはるかに簡単な解決策であり、実際にハッキングまたは盗み出すものは何もないため、非常に「安全」です。ゲームセッション間でアカウント情報を保存する必要がある場合、明らかにこれはうまく機能しません。
Quakeは、この方法でユーザーを「認証」するゲームの例です。