特别是关于您问题的最后一点：不，拥有不安全的身份验证系统永远不会被原谅。在计算机安全方面，很少会启发用户。用户为您的小游戏使用的密码与Google帐户，Facebook帐户，银行帐户等的密码相同。即使您可以断言使用不良的Internet安全习惯是他们的错，但如果您的游戏被用作窃取用户登录凭据的攻击媒介，那您将是负责任的。作为一个更加了解的开发人员，唯一的道德选择是适当地保护您的身份验证过程或完全没有身份验证过程。
作为一些未经请求但相关的建议，无论如何，用户都不希望被要求注册您的游戏。如果他们想足够糟糕地玩游戏，他们可能会这样做，但是如果要注册“另一个怪胎”登录，则会赶走很多潜在的玩家。用户为在那里的每个站点，服务和游戏都注册一个新帐户而感到厌烦，特别是如果他们需要任何类型的电子邮件验证等。如果可以，要么完全避免登录，要么使用用户可能已经拥有帐户的现有第三方身份验证服务。这样您将拥有更多的玩家。如果您打算进行任何类型的应用内购买，则费用将增加三倍。
网页游戏
一个流行的选择是使用基于Web的第三方身份验证服务，特别是对于Web游戏，尽管它也适用于传统游戏。Facebook和Google都具有详细记录的API（均基于标准iirc），用于身份验证。他们确实需要具有打开浏览器窗口并引导用户访问其服务的能力，但这在大多数非控制台平台上都非常容易实现，对于Web游戏来说当然是微不足道的。
这些服务处理所有杂乱的细节，包括通过网络加密登录流量，安全地存储登录凭证以及验证用户登录。然后，您的游戏服务器仅需要实现从用户接收cookie并询问身份验证服务是否有效的协议部分，这在大多数情况下可以通过简单的HTTP来完成。
我不会声称大多数传统的多人游戏会这样做，但是我会声称大多数在线休闲网络游戏会这样做。
对于传统（非网络）游戏，可以通过嵌入浏览器（Awesomium，Chromium嵌入式框架或流行的Webkit或直接选择Webkit）或通过调用外部浏览器来简化此登录过程（这需要花更多的精力在删除auth cookie，这实际上比嵌入上述库之一要容易得多。
这种方法的典型示例是任何Facebook游戏。
使用HTTPS的传统游戏
使用简单的HTTPS服务进行登录越来越普遍。许多游戏都使用自定义协议，但是其中大多数都不完整（它们具有安全的登录名，但是没有创建/更新帐户的安全方法，因此无论如何它们都需要HTTPS服务）或只是出于极大的不安全感。
您甚至不需要获得自定义SSL证书。有一些在线应用程序托管提供商可以为您提供子域并使用通配符SSL证书。您可以将身份验证服务放在mygame.someservice.com上，该服务由Some Service维护的* .someservice.com通配符证书涵盖，您可以随意使用。
这里的想法是用户登录到您的服务，该服务会生成一个唯一的会话cookie，然后用户可以将该会话cookie传递到您的主游戏服务器。然后，服务器询问登录系统cookie是否对请求的用户有效。Cookie上的超时通常很短，大约为几秒钟（例如15-30），并且一旦使用通常会失效，从而无法进行重放攻击。
请注意，如果您打算从客户端内部通过电汇发送付款信息，则HTTPS是我的最佳建议。但是，为此最好使用第三方。如果您认为保护诸如密码之类的简单操作实在太繁琐了，那么您甚至根本不想考虑满足用于存储和处理信用卡号的最低（且确实不够充分）PCI合规性规则。如果您让用户使用已经存档的受信任的第三方支付服务，则无论如何您都会获得更好的销售。
将登录服务与主游戏服务器分离的一个强大优势是，它允许将外部功能绑定到独立于游戏的用户帐户。您可能在网站上具有某些帐户功能（查看化身等），或者可能允许将Facebook帐户链接到您的帐户中，或者您有多个游戏共享一个基础帐户平台（例如，《质量效应》中的《银河战争》功能） 3）。
使用HTTPS进行身份验证的流行示例游戏是Minecraft。
带有本地客户端游戏的第三方Web身份验证
可以通过本地客户端使用Facebook Connect或Google等第三方服务。例如，Facebook和Google都有适用于iOS和Android的本地SDK。某些服务同样具有用于传统PC客户端的本地SDK。
如果目标服务没有本机SDK，并且需要使用Web浏览器，则可以将浏览器嵌入游戏中。但是，某些用户可能不信任使用嵌入式浏览器输入登录信息。
您也可以使用外部浏览器。有几种方法可以实现这一目标。有些需要比其他更多的操作系统集成。有些要求您在主游戏服务器旁边（或至少可以通过它）运行外部Web服务。请注意，由于Facebook和Google通常需要经过身份验证的URL，因此（几乎）在所有情况下，您都需要一个公共网站登录页面才能使用这些协议。
如果不是最简单的话，那么最简单，最可靠的方法就是通过您的主网站反弹来自客户的登录请求。您的客户端以经过身份验证的访客用户身份连接到主游戏服务器，并收到唯一的会话令牌。在这种状态下，游戏服务器不允许客户端实际执行大量操作；游戏不知道玩家是谁，因此玩家无法聊天，开始比赛等。
然后，客户端会启动外部浏览器，指向您游戏域的登录URL，并将此会话令牌作为URL中的参数传递。然后，该网站会进行通常的Facebook / Google登录握手。
此时，您的Web服务器知道用户已登录，并将其与从客户端收到的会话令牌相关联。然后，可以将此验证传递到游戏服务器，从而将客户端的未经身份验证的访客连接提升为经过身份验证的用户会话。如果可能，可以通过使Web服务器直接与游戏服务器通信来完成此操作。或者游戏服务器可以定期轮询Web服务器以查看未决访客连接的身份验证状态。或者客户端可以定期轮询Web服务器以查看登录是否完成，并且在登录时向游戏服务器发出信号，要求Web服务器进行验证。
所有这些都要求您的游戏服务器和Web服务器能够通信，但是任何第三方身份验证服务都将要求您的游戏服务器能够与外界通信，因此这并不奇怪。
在某些中小型MMO中可以找到这种身份验证方法。
请注意，这一切也适用于通过外部服务（例如PayPal，Amazon Payments，Google Wallet等）进行付款请求。
直接TLS连接
通过自定义流协议启动TLS会话并不是很困难。诸如OpenSSL，GnuTLS，NSS之类的库以及各种特定于OS的库都提供了流包装API，该API覆盖了低层的传输/协议。通常，您只需要通过包装API来提供字节，它就处理握手和加密。
这里的棘手部分是确保您使用TLS的安全性。例如，某些通用库默认情况下将需要来自可信机构的有效签名证书。一些通用库要求这样做，但是默认情况下不信任任何权限。其中一些不需要证书完全有效。
建议始终要求您提供有效的证书。允许无效证书将不会允许仅窃听的攻击者窃取密码，但仍将允许中间人攻击。
就外部依赖关系而言，此方法要求绝对最少，同时仍可提供最大的安全性。
现在，使用这种游戏的例子包括大多数大型传统MMO。
保护（ish）传统游戏
不使用单独服务且不使用TLS的游戏通常必须在其主要游戏协议中实现某种基于随机数的登录协议。使用此方法，服务器将生成一个随机数（随机数）并将其发送给客户端。然后，客户端使用用户的密码（和用户名，可能还有一些其他数据）来散列该随机数，并将该响应发送到服务器。然后，服务器将此哈希值与其在文件中拥有的凭据进行比较。这样可以使用户的密码一直保密，并确保您不能像对许多其他基于散列的弱登录方案一样，对散列的密码进行简单的重放攻击。
问题是用户无法通过此协议安全地向服务提交新密码。典型的实现还会在服务器上以纯文本格式存储用户密码，这是一种可怕的做法（如果服务器被黑客入侵，则用户可能只是被盗了他的电子邮件/ facebook /银行密码，因为他在游戏中使用的密码与其他地方，因为用户倾向于这样做。
该基本登录方案有增强版本。最基本的（尽管仍不是理想的安全性）是服务器在登录期间发送带有哈希值的密码哈希盐。这允许服务器安全地存储哈希（加盐）密码，同时允许客户端在登录期间生成相同的哈希。这的确使攻击者可以获得特定用户密码的盐，但这在没有获得原始哈希密码（在登录过程中不会通过网络发送）的情况下并不是特别有用。在创建/更新密码的过程中，客户端将发送完整的散列密码（带有盐），攻击者可以嗅到该密码。如果使用的哈希函数足够强大（例如sha-2 / 512），那么单纯的强行强制是不可行的，尽管攻击者仍然可以轻易强行破解弱密码（这就是为什么要强制设置一些最小密码长度，最小字母/数字/符号分布以及与已知/明显/弱密码字典进行比较很重要）的原因。攻击者仍然可以获取哈希密码的事实是为什么通过安全的加密通道进行整个密码交换仍然更加安全的原因。
许多流行的游戏网络库都实现了此协议的某些可选形式。我相信SmartFox就是这样的一个例子，尽管我没有深入研究它（我通常会忽略任何这样的库身份验证系统，而是使用HTTPS方法，因为它实现起来非常简单，而且功能更强大）。许多早期的非Web Internet游戏也使用这种方法，尤其是在Steam，XBL等问世之前。
不安全的传统游戏
不幸的是，许多游戏只是以纯文本形式发送用户名/密码。也许他们对密码进行了哈希处理，这大概可以保护用户的实际密码（还不够好），但是重放攻击使登录游戏服务变得微不足道。
不要这样 这是不负责任和懒惰的。普及这些登录方法的1990年代的互联网天真不再是可行的借口。
许多早期的Facebook Flash之前的Flash和网络游戏都采用这种方法。我不知道有什么特别的例子。我想相信他们已经死了，但是这个世界并不那么幸运。
不认证
大多数游戏只是不进行身份验证。玩家进行连接，发送一些手柄以唯一地标识自己，然后比赛开始。没有全局服务器试图验证只有一个真实的人曾经被允许宣称自己是“ CaptainMisterDude”。本地服务器仅确保只有一个当前连接的播放器具有任何特定的句柄，到此为止。本地服务器使用基于名称和基于IP的黑名单来制造麻烦。即使在今天，这对于FPS死亡竞赛风格的游戏也是很常见的。
如果您不需要任何永久性帐户状态，那么这是迄今为止最简单的解决方案，而且非常“安全”，因为实际上没有任何东西可以入侵或窃取。显然，如果您确实需要在游戏会话之间存储帐户信息，则这种方法不太好用。
雷神之锤是使用这种“认证”用户方法的游戏示例。