Específicamente con respecto al último bit de su pregunta: No, nunca es perdonable tener un sistema de autenticación inseguro. Los usuarios rara vez se ilustran cuando se trata de seguridad informática. Los usuarios usan la misma contraseña para su pequeño juego que usan para su cuenta de Google, cuenta de Facebook, cuenta bancaria, etc. Incluso si puede afirmar que es su culpa por usar malos hábitos de seguridad en Internet, usted será el responsable si su juego se usa como un vector de ataque para robar las credenciales de inicio de sesión de los usuarios. Como desarrollador que conoce mejor, las únicas opciones éticas son asegurar adecuadamente su proceso de autenticación o no tener ninguna.
Como algunos consejos no solicitados pero relacionados, los usuarios no quieren que se les solicite registrarse en su juego de todos modos. Es posible que lo hagan si quieren jugar tu juego lo suficiente, pero tener un inicio de sesión de Yet Another Freaking para registrarte va a ahuyentar a muchos jugadores potenciales. Los usuarios están hartos de crear una nueva cuenta para cada sitio, servicio y juego, especialmente si requieren algún tipo de validación de correo electrónico o similar. Si puede, evite tener un inicio de sesión o use un servicio de autenticación de terceros existente con el que los usuarios probablemente ya tengan una cuenta. Tendrás más jugadores de esa manera. Esto se triplica si planeas tener algún tipo de compras en la aplicación.
Juegos web
Una opción popular, particularmente para los juegos web, aunque también funciona para los juegos tradicionales, es utilizar un servicio de autenticación de terceros basado en la web. Facebook y Google tienen API bien documentadas (ambas basadas en API estandarizadas, iirc) para la autenticación. Requieren la capacidad de abrir una ventana del navegador y dirigir al usuario hacia sus servicios, pero esto es bastante fácil de hacer en la mayoría de las plataformas que no son de consola y, por supuesto, trivial para los juegos web.
Esos servicios se encargan de todos los detalles desordenados de cifrar el tráfico de inicio de sesión a través del cable, almacenar de forma segura las credenciales de inicio de sesión y validar los inicios de sesión de los usuarios. Su servidor de juegos solo necesita implementar la parte del protocolo que recibe una cookie del usuario y le pregunta al servicio de autenticación si la cookie es válida o no, lo que se puede hacer con un HTTP simple en la mayoría de los casos.
No afirmaré que la mayoría de los juegos multijugador tradicionales hacen esto, porque no lo hacen, pero afirmaré que la mayoría de los juegos casuales en línea hacen esto.
Para los juegos tradicionales (no web), es posible facilitar este procedimiento de inicio de sesión incorporando un navegador (Awesomium, Chromium Embedded Framework o directamente Webkit como opciones populares) o llamando a un navegador externo (esto requiere un poco más de dificultad para sin embargo, elimine la cookie de autenticación, y no es realmente más fácil que incrustar una de las bibliotecas mencionadas anteriormente).
Un ejemplo típico de este enfoque es cualquier juego de Facebook.
Juegos tradicionales usando HTTPS
Tener un servicio HTTPS simple para iniciar sesión es cada vez más normal. Muchos juegos usan protocolos personalizados, pero la mayoría de estos están incompletos (tienen un inicio de sesión seguro, pero no hay una forma segura de crear / actualizar una cuenta, por lo que necesitan el servicio HTTPS de todos modos) o simplemente son terriblemente inseguros.
Ni siquiera necesita obtener un certificado SSL personalizado. Hay proveedores de alojamiento de aplicaciones en línea que le otorgan un subdominio y utilizan un certificado SSL comodín. Puede poner su servicio de autenticación en mygame.someservice.com, que está cubierto por el certificado comodín * .someservice.com que mantiene algunos servicios, y ya está listo.
La idea aquí es que el usuario inicie sesión en su servicio, que genera una cookie de sesión única, que el usuario puede pasar a su servidor de juego principal. El servidor luego le pregunta al sistema de inicio de sesión si la cookie es válida para el usuario solicitado. Por lo general, hay un tiempo de espera muy corto en la cookie, del orden de segundos (15-30, por ejemplo), y generalmente se invalida una vez utilizada, lo que hace que los ataques de repetición sean imposibles.
Tenga en cuenta que HTTPS es mi opción más recomendada si planea enviar información de pago a través del cable desde el propio cliente. Sin embargo, es significativamente mejor usar un tercero para esto. Si cree que asegurar algo tan simple como una contraseña es demasiado trabajo, ni siquiera quiere pensar en tratar de cumplir con las normas de cumplimiento de PCI mínimas (y, sinceramente, bastante inadecuadas) para almacenar y procesar números de tarjetas de crédito. De todos modos, tendrá una mejor captación de ventas si hace que los usuarios utilicen servicios de pago de terceros de confianza con los que ya están registrados.
Una gran ventaja de separar su servicio de inicio de sesión del servidor principal del juego es que permite que la funcionalidad externa esté vinculada a las cuentas de usuario independientes del juego. Es posible que tenga algunas características de la cuenta (ver avatares o similares) en su sitio web, o tal vez permita vincular cuentas de Facebook a sus cuentas, o tal vez tenga varios juegos que compartan una sola plataforma de cuenta subyacente (por ejemplo, las características Galaxy at War de Mass Effect 3)
Un juego de ejemplo popular que usa HTTPS para la autenticación es Minecraft.
Autenticación web de terceros con juegos de clientes nativos
Es posible utilizar servicios de terceros como Facebook Connect o Google con un cliente nativo. Facebook, por ejemplo, tiene un SDK nativo para iOS y Android, al igual que Google. Asimismo, algunos servicios tienen SDK nativos para clientes de PC tradicionales.
Si el servicio de destino no tiene un SDK nativo y requiere el uso de un navegador web, puede insertar un navegador en su juego. Sin embargo, algunos usuarios pueden desconfiar del uso de un navegador integrado para ingresar información de inicio de sesión.
También puede usar un navegador externo. Hay algunas maneras de lograr esto. Algunos requieren un poco más de integración del sistema operativo que otros. Algunos requieren que tenga un servicio web externo que se ejecute junto (o al menos accesible) con su servidor de juegos principal. Tenga en cuenta que, dado que Facebook y Google generalmente requieren una URL autenticada, necesitará una página de inicio de sitio web pública para usar estos protocolos en (casi) todos los casos.
Lo más infalible y confiable, si no el más fácil, es rechazar su solicitud de inicio de sesión de su cliente a través de su sitio web principal. Su cliente se conecta al servidor principal del juego como un usuario invitado autenticado y recibe un token de sesión único. El servidor del juego no permite que el cliente haga mucho en este estado; el juego no sabe quién es el jugador, por lo que el jugador aún no puede chatear, comenzar un partido, etc.
Luego, el cliente inicia el navegador externo apuntando a la URL de inicio de sesión del dominio de su juego, pasando este token de sesión como un parámetro en la URL. Luego, el sitio pasa por el protocolo de enlace de inicio de sesión habitual para Facebook / Google.
En este punto, su servidor web sabe que el usuario ha iniciado sesión y puede asociarlo con el token de sesión que recibió del cliente. Esta verificación se puede comunicar al servidor del juego, elevando la conexión de invitado no autenticado del cliente a una sesión de usuario autenticada. Esto se puede hacer haciendo que el servidor web se comunique directamente con el servidor del juego, si es posible. O el servidor del juego puede sondear periódicamente el servidor web para el estado de autenticación de las conexiones de invitados pendientes. O el cliente puede sondear periódicamente el servidor web para ver si el inicio de sesión está completo y, cuando lo está, indicar al servidor del juego que solicite la verificación del servidor web.
Todo esto requiere que su servidor de juegos y servidor web puedan comunicarse, pero cualquier servicio de autenticación de terceros requerirá que su servidor de juegos pueda comunicarse con el mundo exterior, por lo que esto no debería ser una sorpresa.
Este método de autenticación se encuentra en algunos MMO de tamaño pequeño a mediano.
Tenga en cuenta que todo esto también funciona para realizar solicitudes de pago a través de un servicio externo, como PayPal, Amazon Payments, Google Wallet, etc.
Conexión directa TLS
No es demasiado difícil iniciar una sesión TLS sobre un protocolo de flujo personalizado. Las bibliotecas como OpenSSL, GnuTLS, NSS y varias bibliotecas específicas del sistema operativo proporcionan una API de envoltura de flujo que se superpone en un protocolo / transporte de bajo nivel. En general, solo necesita alimentar bytes a través de la API del contenedor y se ocupa del protocolo de enlace y el cifrado.
Las partes difíciles aquí son garantizar que su uso de TLS sea seguro. Algunas de las bibliotecas comunes, por ejemplo, requerirán por defecto un certificado firmado válido de una autoridad confiable. Algunas de las bibliotecas comunes requieren eso, pero por defecto no confían en ninguna autoridad. Algunos de ellos no requieren que el certificado sea válido en absoluto.
Se recomienda que siempre requiera un certificado válido. Permitir certificaciones no válidas no permitirá que un atacante que simplemente esté espiando robe una contraseña, pero aún permitirá ataques de hombre en el medio.
Este enfoque requiere lo menos absoluto en términos de dependencias externas, al tiempo que permite la máxima seguridad.
Los ejemplos de juegos que usan esto ahora incluyen la mayoría de los grandes MMO tradicionales.
Juegos tradicionales seguros (ish)
Los juegos que no usan un servicio separado y no usan TLS generalmente tienen que implementar algún tipo de protocolo de inicio de sesión no basado en su protocolo de juego principal. Con este método, el servidor genera un número aleatorio (un nonce) y lo envía al cliente. Luego, el cliente agrega esa clave con la contraseña del usuario (y nombre de usuario, posiblemente otros datos) y envía esa respuesta al servidor. El servidor luego compara este valor hash con las credenciales que tiene en el archivo. Esto mantiene el secreto de la contraseña del usuario por cable y garantiza que no pueda usar un simple ataque de repetición en la contraseña hash, como muchos otros esquemas de inicio de sesión débiles basados en hash.
Un problema es que el usuario no tiene forma de enviar una nueva contraseña al servicio a través de este protocolo de forma segura. Las implementaciones típicas también almacenan la contraseña del usuario en texto plano en el servidor, lo cual es una práctica horrible (si su servidor es pirateado, es probable que su usuario haya sido robado su contraseña de correo electrónico / facebook / banco, porque estaba usando la misma contraseña para su juego como en todas partes, porque los usuarios tienden a hacer eso)
Hay versiones mejoradas de ese esquema de inicio de sesión básico. Lo más básico, aunque todavía no es idealmente seguro, es que el servidor envíe la sal de hash de contraseña con el valor nonce durante el inicio de sesión. Esto permite que el servidor almacene una contraseña hash (y salada) de forma segura mientras permite que el cliente genere el mismo hash durante el inicio de sesión. Esto permite que un atacante obtenga la sal para la contraseña de un usuario en particular, pero esto no es particularmente útil sin también obtener la contraseña hash original (que no se envía por cable durante el inicio de sesión). Durante la creación / actualización de la contraseña, el cliente envía la contraseña hash completa (con sal), que el atacante puede oler. Si la función hash utilizada es lo suficientemente fuerte (por ejemplo, sha-2/512), entonces el forzamiento bruto puro no es factible, aunque el atacante aún puede forzar fácilmente contraseñas débiles por fuerza bruta (es por eso que es importante aplicar una longitud mínima de contraseña, una distribución mínima de letras / números / símbolos y comparar con un diccionario de contraseñas conocidas / obvias / débiles). El hecho de que el atacante aún pueda obtener la contraseña cifrada es la razón por la que es aún más seguro realizar el intercambio completo de la contraseña a través de un canal seguro y encriptado.
Una serie de bibliotecas de redes de juegos populares implementan alguna forma opcional de este protocolo. Creo que SmartFox es uno de esos ejemplos, aunque no lo he analizado en profundidad (generalmente ignoro cualquier sistema de autenticación de biblioteca y uso el método HTTPS, ya que es muy simple de implementar y significativamente más fuerte). Varios de los primeros juegos de Internet que no son web también utilizaron este enfoque, particularmente antes de que aparecieran Steam, XBL, etc.
Juegos tradicionales no seguros
Desafortunadamente, muchos juegos solo envían un nombre de usuario / contraseña en texto sin formato. Tal vez ellos introducen la contraseña, que protege vagamente la contraseña real de los usuarios (no lo suficientemente bien), pero un ataque de repetición hace que iniciar sesión en el servicio del juego sea trivial.
No hagas esto. Es irresponsable y vago. La ingenuidad de Internet de la década de 1990 que popularizó estos métodos de inicio de sesión ya no es una excusa viable.
Muchos de los primeros juegos flash y web anteriores a Facebook adoptaron este enfoque. No conozco ningún ejemplo específico fuera de mi cabeza; Me gustaría creer que todos están muertos hace mucho tiempo, pero el mundo no tiene tanta suerte.
Sin autenticacion
La mayoría de los juegos simplemente no hacen autenticación. El jugador se conecta, envía un identificador para identificarse de manera única y comienza una partida. No hay un servidor global que intente validar que solo un humano real pueda decir que es "CaptainMisterDude". El servidor local solo asegura que solo un jugador conectado actualmente tenga un controlador particular, y ese es el final. Los servidores locales utilizan listas negras basadas en nombres y en IP para los creadores de problemas. Esto es común para los juegos de estilo FPS deathmatch incluso hoy en día.
Si no necesita ningún estado permanente para las cuentas, esta es, con mucho, la solución más fácil y bastante "segura", ya que no hay nada para piratear o robar. Obviamente, esto no funciona demasiado bien si necesita almacenar información de la cuenta entre sesiones de juego.
Quake es un ejemplo de un juego que utiliza este método de "autenticación" de usuarios.