Básicamente, tienes tres requisitos:
- no debería ser fácil usar la misma clave para varias instancias de clientes,
- no debería ser fácil generar nuevas claves válidas, y
- No debería ser fácil robar la clave de un cliente legítimo.
La primera parte debería ser bastante sencilla: simplemente no permita que dos jugadores inicien sesión en el mismo servidor con la misma clave al mismo tiempo. También puede hacer que los servidores intercambien información sobre los usuarios registrados o que se comuniquen con un servidor de autenticación compartido, de modo que incluso al usar la misma clave para diferentes jugadores en diferentes servidores al mismo tiempo falle. Probablemente también desee buscar patrones sospechosos de uso de claves y, si determina que se ha filtrado una clave, agréguela a una lista de claves prohibidas.
Para la segunda parte, una forma es simplemente mantener una base de datos de todas las claves emitidas válidas. Mientras las claves sean lo suficientemente largas (digamos, 128 bits o más) y se elijan al azar (usando un RNG seguro), las probabilidades de que cualquiera logre adivinar una clave válida son esencialmente cero. (Incluso las claves mucho más cortas pueden ser seguras si usa algún tipo de limitación de velocidad en intentos fallidos de inicio de sesión para detener los intentos de encontrar claves válidas por fuerza bruta).
Alternativamente, puede generar claves tomando cualquier identificador único y agregando un código de autenticación de mensaje (como HMAC ), calculado utilizando una clave maestra secreta. Nuevamente, mientras el MAC sea lo suficientemente largo, las probabilidades de que cualquiera que no conozca la clave maestra pueda adivinar un MAC válido para cualquier ID es insignificante. Una ventaja de este método, además de eliminar la necesidad de una base de datos de claves, es que el identificador puede ser cualquier cadena única y puede codificar información sobre el cliente para el que se emitió la clave.
Un problema con el uso de MAC es que los servidores oficiales del juego (o al menos el servidor de autenticación) necesitan conocer la clave maestra para verificar la MAC, lo que significa que, si los servidores son pirateados, la clave maestra podría filtrarse. Una forma de mitigar este riesgo podría ser calcular varios MAC para cada ID, utilizando diferentes claves maestras, pero solo almacenar una de las claves maestras en los servidores del juego. De esa manera, si esa clave maestra alguna vez se filtra y se usa para generar ID falsas, puede revocarla y cambiar a otra clave maestra. Alternativamente, puede reemplazar los MAC con firmas digitales , que pueden verificarse utilizando solo la mitad pública de la clave maestra.
Para la tercera parte, un enfoque es asegurarse de que el cliente no envíe su clave a nadie sin verificar que el destinatario realmente sea un servidor oficial legítimo. Por ejemplo, podría usar SSL / TLS (o DTLS ) para el proceso de inicio de sesión, emitir certificados personalizados para sus servidores de juegos y solo tener los certificados de confianza del cliente emitidos por usted. Convenientemente, el uso de TLS también protegerá las claves del cliente (y cualquier otro dato de autenticación) de espías, por ejemplo, en WLAN públicas.
Desafortunadamente, este enfoque no permitirá que los servidores de terceros verifiquen las claves del cliente, incluso si así lo desean. Podría solucionar este problema configurando un servidor de autenticación oficial que los servidores de juegos de terceros puedan utilizar, por ejemplo, haciendo que el cliente inicie sesión en el servidor de autenticación y reciba un token aleatorio que pueden usar para iniciar sesión en el servidor de juego (que luego envía el token al servidor de autenticación para verificarlo).
Alternativamente, puede emitir certificados de cliente reales, o algo así, a sus clientes. Puede usar un protocolo existente (como TLS) que admita la autenticación de certificado de cliente (recomendado) o implementar el suyo propio, por ejemplo:
- El certificado del cliente consta de una cadena de identificación arbitraria, un par de claves pública / privada y una firma digital de la identificación y la clave pública utilizando la clave maestra.
- Para iniciar sesión, el cliente envía su ID, clave pública y firma. El servidor responde con una cadena de desafío única (preferiblemente que incluye una ID de servidor y una marca de tiempo, que el cliente debe verificar), que el cliente firma con la clave privada (para demostrar que conoce la clave) y envía la firma al servidor.
- El servidor verifica ambas firmas, lo que demuestra que la clave pública ID + forma una clave de cliente legítima (ya que fueron firmadas con la clave maestra) y que la clave del cliente realmente pertenece al cliente (ya que el cliente podría firmar el desafío del servidor con la clave privada llave).
(Este protocolo podría simplificarse aún más si el cliente genera el "desafío", que consiste en un ID de servidor y una marca de tiempo, y lo firma. Por supuesto, el servidor debe verificar que el ID y la marca de tiempo sean válidos. También tenga en cuenta que Este simple protocolo, por sí solo, no impedirá que un atacante intermediario pueda secuestrar la sesión del cliente, aunque evitará que obtenga la clave privada del cliente necesaria para futuros inicios de sesión).