Especificamente em relação à última parte da sua pergunta: Não, nunca é perdoável ter um sistema de autenticação inseguro. Os usuários raramente são esclarecidos quando se trata de segurança do computador. Os usuários usam a mesma senha para o seu joguinho e a conta do Google, conta do Facebook, conta bancária e assim por diante. Mesmo que você possa alegar que é culpa deles usar maus hábitos de segurança na Internet, você será o responsável se o jogo for usado como vetor de ataque para roubar as credenciais de login dos usuários. Como um desenvolvedor que conhece melhor, as únicas opções éticas são proteger adequadamente seu processo de autenticação ou não ter um.
Como alguns conselhos não solicitados, mas relacionados, os usuários não querem que seja necessário se inscrever no seu jogo. Eles podem fazê-lo se quiserem jogar o seu jogo mal o suficiente, mas ter ainda um outro login de pânico para se inscrever vai afastar muitos jogadores em potencial. Os usuários estão cansados de criar uma nova conta para cada site, serviço e jogo disponível, especialmente se exigirem algum tipo de validação de email ou algo semelhante. Se você puder, evite ter um logon ou use um serviço de autenticação de terceiros existente com o qual os usuários provavelmente já tenham uma conta. Você terá mais jogadores dessa maneira. Isso triplicará se você planeja fazer qualquer tipo de compra no aplicativo.
Jogos na Web
Uma opção popular - particularmente para jogos na Web, embora também funcione para jogos tradicionais - é usar um serviço de autenticação de terceiros baseado na Web. O Facebook e o Google têm APIs bem documentadas (ambas baseadas em APIs padronizadas, iirc) para autenticação. Eles exigem a capacidade de abrir uma janela do navegador e direcionar o usuário para seus serviços, mas isso é bastante fácil de fazer na maioria das plataformas que não são de console e, é claro, trivial para jogos na Web.
Esses serviços cuidam de todos os detalhes confusos da criptografia do tráfego de logon pela rede, armazenando com segurança as credenciais de logon e validando os logins dos usuários. Seu servidor de jogos precisa implementar apenas a parte do protocolo que recebe um cookie do usuário e pergunta ao serviço de autenticação se o cookie é válido ou não, o que pode ser feito com um simples HTTP na maioria dos casos.
Não vou afirmar que a maioria dos jogos multiplayer tradicionais faz isso, porque não o fazem, mas vou afirmar que a maioria dos jogos casuais online faz isso.
Para jogos tradicionais (fora da Web), é possível facilitar esse procedimento de login incorporando um navegador (Awesomium, Chromium Embedded Framework ou Webkit direto, sendo escolhas populares) ou chamando um navegador externo (isso exige mais tire o cookie de autenticação e não é mais fácil do que incorporar uma das bibliotecas mencionadas).
Um exemplo típico dessa abordagem é qualquer jogo do Facebook.
Jogos tradicionais usando HTTPS
Ter um serviço HTTPS simples para login é cada vez mais normal. Muitos jogos usam protocolos personalizados, mas a maioria deles é incompleta (eles têm login seguro, mas não há uma maneira segura de criar / atualizar uma conta; portanto, eles precisam do serviço HTTPS de qualquer maneira) ou são simplesmente terrivelmente inseguros.
Você nem precisa obter um certificado SSL personalizado. Existem provedores de hospedagem de aplicativos on-line que fornecem um subdomínio e usam um certificado SSL curinga. Você pode colocar seu serviço de autenticação em mygame.someservice.com, que é coberto pelo certificado curinga * .someservice.com que Some Service mantém, e você estará pronto.
A idéia aqui é que o usuário efetue login no seu serviço, o que gera um cookie de sessão exclusivo, que o usuário pode transmitir ao servidor principal do jogo. O servidor pergunta ao sistema de login se o cookie é válido para o usuário solicitado. Geralmente, há um tempo limite muito curto no cookie, da ordem de segundos (15 a 30, por exemplo), e geralmente é invalidado uma vez usado, impossibilitando ataques de repetição.
Observe que HTTPS é minha opção mais recomendada se você planeja enviar informações de pagamento por cabo a partir de dentro do próprio cliente. No entanto, é significativamente melhor usar terceiros para isso. Se você acha que proteger algo tão simples quanto uma senha é muito trabalhoso, você nem quer pensar em tentar cumprir as regras mínimas (e honestamente inadequadas) de conformidade com PCI para armazenar e processar números de cartão de crédito. De qualquer forma, você terá uma melhor aceitação de vendas se os usuários usarem serviços confiáveis de pagamento de terceiros com os quais eles já estão registrados.
Uma grande vantagem de separar seu serviço de login do servidor principal do jogo é que ele permite que a funcionalidade externa seja vinculada às contas de usuário independentemente do jogo. Você pode ter alguns recursos da conta (visualizar avatares ou outros) em seu site, ou talvez permitir a vinculação de contas do Facebook em suas contas, ou talvez você tenha vários jogos compartilhando uma única plataforma de conta subjacente (por exemplo, os recursos de Mass Effect do Galaxy at War 3)
Um exemplo de jogo popular usando HTTPS para autenticação é o Minecraft.
Autenticação da Web de terceiros com jogos de clientes nativos
É possível usar serviços de terceiros, como o Facebook Connect ou o Google, com um cliente nativo. O Facebook, por exemplo, possui um SDK nativo para iOS e Android, assim como o Google. Alguns serviços também têm SDKs nativos para clientes de PC tradicionais.
Se o serviço de destino não possuir um SDK nativo e exigir o uso de um navegador da Web, você poderá incorporar um navegador ao seu jogo. No entanto, alguns usuários podem desconfiar do uso de um navegador incorporado para inserir informações de login.
Você também pode usar um navegador externo. Existem algumas maneiras de conseguir isso. Alguns exigem um pouco mais de integração do sistema operacional do que outros. Alguns exigem que você tenha um serviço da Web externo em execução ao lado (ou pelo menos acessível por) do servidor principal do jogo. Observe que, como o Facebook e o Google geralmente exigem um URL autenticado, você precisará de uma página de destino do site público para usar esses protocolos em (quase) todos os casos.
O mais infalível e confiável, se não o mais fácil, é devolver sua solicitação de login do seu cliente através do site principal. Seu cliente se conecta ao servidor principal do jogo como um usuário convidado autenticado e recebe um token de sessão exclusivo. O servidor do jogo não permite que o cliente realmente faça muito enquanto estiver nesse estado; o jogo não sabe quem é o jogador, portanto ainda não pode conversar, iniciar uma partida ou assim por diante.
O cliente inicia o navegador externo apontando para o URL de login do domínio do seu jogo, passando esse token de sessão como um parâmetro no URL. O site passa pelo handshake de login usual para o Facebook / Google.
Nesse ponto, seu servidor web sabe que o usuário efetuou login e pode associá-lo ao token de sessão recebido do cliente. Essa verificação pode ser comunicada ao servidor do jogo, elevando a conexão de convidado não autenticada do cliente em uma sessão de usuário autenticada. Isso pode ser feito com o servidor da web se comunicando diretamente com o servidor do jogo, se possível. Ou o servidor do jogo pode pesquisar periodicamente o servidor da web quanto ao status de autenticação de conexões de convidados pendentes. Ou o cliente pode pesquisar periodicamente o servidor da web para ver se o login está completo e, quando for, sinalizar ao servidor do jogo para solicitar a verificação do servidor da web.
Tudo isso exige que o servidor do jogo e o servidor da web possam se comunicar, mas qualquer serviço de autenticação de terceiros exigirá que o servidor do jogo seja capaz de se comunicar com o mundo exterior, portanto, isso não deve ser uma surpresa.
Esse método de autenticação é encontrado em alguns MMOs de pequeno a médio porte.
Observe que tudo isso também funciona para fazer solicitações de pagamento por meio de um serviço externo, como PayPal, Amazon Payments, Google Wallet etc.
Conexão TLS direta
Não é muito difícil iniciar uma sessão TLS por um protocolo de fluxo personalizado. Bibliotecas como OpenSSL, GnuTLS, NSS e várias bibliotecas específicas do SO fornecem uma API de wrapper de fluxo que se sobrepõe a um protocolo / transporte de baixo nível. Geralmente, você só precisa alimentar bytes através da API do wrapper e ela lida com o handshake e a criptografia.
As partes complicadas aqui estão garantindo o uso seguro do TLS. Algumas das bibliotecas comuns, por exemplo, exigem um certificado assinado válido de uma autoridade confiável. Algumas das bibliotecas comuns exigem isso, mas por padrão não confiam em nenhuma autoridade. Alguns deles não exigem que o certificado seja válido.
É recomendável que você sempre exija um certificado válido. Permitir certs inválidos não permitirá que um invasor que está apenas bisbilhotando roube uma senha, mas ainda permitirá ataques man-in-the-middle.
Essa abordagem requer o mínimo absoluto em termos de dependências externas, enquanto ainda permite segurança máxima.
Exemplos de jogos que usam isso agora incluem os maiores MMOs tradicionais.
Jogos tradicionais seguros (ish)
Os jogos que não usam um serviço separado e não usam TLS geralmente precisam implementar algum tipo de protocolo de login não baseado em seu protocolo principal de jogo. Com esse método, o servidor gera um número aleatório (um nonce) e o envia ao cliente. O cliente faz o hash dessa senha com a senha do usuário (e nome de usuário, possivelmente outros dados) e envia essa resposta ao servidor. O servidor compara esse valor de hash com as credenciais que possui no arquivo. Isso mantém a senha do usuário secreta e garante que você não pode usar um ataque de repetição simples na senha com hash, como muitos outros esquemas fracos de login baseados em hash.
Um problema é que o usuário não tem como enviar uma nova senha para o serviço por esse protocolo com segurança. As implementações típicas também armazenam a senha do usuário em texto sem formatação no servidor, o que é uma prática horrível (se o servidor for hackeado, provavelmente o usuário teve sua senha de email / facebook / banco roubada, porque ele estava usando a mesma senha no seu jogo como em qualquer outro lugar, porque os usuários tendem a fazer isso).
Existem versões aprimoradas desse esquema básico de login. O mais básico - embora ainda não seja idealmente seguro - é o servidor enviar o hash salt da senha com o valor nonce durante o login. Isso permite que o servidor armazene uma senha com hash (e salgada) com segurança, enquanto permite ao cliente gerar o mesmo hash durante o login. Isso permite que um invasor consiga obter a senha de um usuário em particular, mas isso não é particularmente útil sem a obtenção da senha hash original (que não é enviada por fio durante o login). Durante a criação / atualização da senha, o cliente envia a senha inteira do hash (com salt), que o invasor pode farejar. Se a função hash usada for forte o suficiente (por exemplo, sha-2/512), a forçagem bruta pura não será viável, embora o invasor ainda possa facilmente usar senhas fracas com força bruta (é por isso que é importante aplicar um tamanho mínimo de senha, é necessária uma distribuição mínima de letras / números / símbolos e comparar um dicionário de senhas conhecidas / óbvias / fracas). O fato de o invasor ainda poder obter a senha com hash é o motivo pelo qual ainda é mais seguro realizar toda a troca de senhas em um canal criptografado e protegido.
Várias bibliotecas populares de redes de jogos implementam alguma forma opcional deste protocolo. Acredito que o SmartFox é um exemplo, apesar de não ter analisado profundamente (geralmente ignoro qualquer sistema de autenticação de biblioteca e uso o método HTTPS, pois é simples de implementar e significativamente mais forte). Vários jogos anteriores da Internet que não são da Web também usavam essa abordagem, principalmente antes da chegada do Steam, XBL e assim por diante.
Jogos tradicionais inseguros
Infelizmente, muitos jogos apenas enviam um nome de usuário / senha em texto simples. Talvez eles usem a senha com hash, o que protege vagamente a senha real do usuário (não o suficiente), mas um ataque de repetição torna o login no serviço de jogo trivial.
Não faça isso. É irresponsável e preguiçoso. A ingenuidade na Internet dos anos 90 que popularizou esses métodos de login não é mais uma desculpa viável.
Muitos jogos anteriores da Web e Flash anteriores ao Facebook adotaram essa abordagem. Não conheço nenhum exemplo específico em cima da minha cabeça; Eu gostaria de acreditar que eles estão todos mortos há muito tempo, mas o mundo simplesmente não tem essa sorte.
Sem autenticação
A maioria dos jogos simplesmente não faz autenticação. O jogador se conecta, envia uma alça para se identificar de maneira única e inicia uma partida. Não existe um servidor global que tente validar que apenas um humano real pode reivindicar ser "CaptainMisterDude". O servidor local apenas garante que apenas um jogador conectado no momento tenha um identificador específico, e esse é o fim. Servidores locais usam listas negras baseadas em nome e IP para criadores de problemas. Isso é comum em jogos no estilo deathmatch de FPS ainda hoje.
Se você não precisa de nenhum estado permanente para as contas, essa é de longe a solução mais fácil e bastante "segura", pois não há nada para invadir ou roubar. Obviamente, isso não funciona muito bem se você precisar armazenar informações da conta entre as sessões do jogo.
Quake é um exemplo de jogo usando esse método de "autenticação" de usuários.