Autorización segura para juegos o servicios basados en suscripción

2

Supongamos que estoy desarrollando un juego de escritorio basado en suscripción: el jugador paga una tarifa para poder acceder a ciertos niveles del juego durante un tiempo determinado. Por ejemplo, el jugador paga $ 1 para obtener acceso a un nivel especial del juego durante un mes.

Cada vez que se carga el juego, envía una solicitud a la API de back-end para verificar a qué niveles puede acceder el jugador, y luego habilita los niveles correspondientes para el jugador. Sin embargo, el jugador puede usar un ataque MITM (hombre en el medio) para interceptar y modificar la respuesta del servidor, por lo que le dice al juego que el jugador tiene acceso a todos los niveles del juego.

¿Cómo debe implementarse el proceso de autorización en esta situación para evitar que el jugador obtenga acceso no autorizado a niveles?

Asumamos dos perfiles de jugador para dos escenarios diferentes:

  • Escenario 1: el jugador puede oler la red.
  • Escenario 2: el jugador puede oler la red y tiene acceso al código fuente del juego (no del servidor).
pregunta Racso 07.10.2018 - 02:53
fuente

2 respuestas

1

Es difícil evitar que un juego se rompa. Hay mucho si los aficionados a la afición que juegan juegos solo por diversión.

Yo diría que la mejor opción sería tener los recursos de descarga del juego necesarios para que el juego se ejecute cuando el usuario alcance ese nivel. Una especie de cheque "justo a tiempo". De esa manera no pueden parchear el juego para simplemente ignorarlo o verificarlo.

Otra cosa que puedes hacer es asegurarte de que la conexión pasa por https, y usar la fijación de certificados para asegurarte de que estás usando el certificado correcto.

El intercambio de pila de ingeniería inversa puede ofrecerle más sugerencias sobre cómo evitar la inversión del binario (craqueo / parcheado)

Así que para responder a la pregunta Escenario 1: usar https con anclaje de certificado Escenario 2: la fuente no es tan necesaria, un inversor puede revertir desde un binario (que es como se hace normalmente). Evite una única comprobación de variables, descargue activos y verifique qué intercambio de la pila de inversión.

    
respondido por el Daisetsu 07.10.2018 - 05:01
fuente
4
  

Escenario 1: el jugador puede oler la red.

Esto se puede prevenir con HTTPS.
Solo, si el jugador tiene el control total del cliente, puede parchear al cliente para proporcionar y tal vez modificar la información de texto sin formato directamente en la aplicación (es decir, el juego). Pero esto no está cubierto por sus suposiciones en el escenario 1.

  

Escenario 2: ... y tiene acceso al código fuente del juego (no del servidor).

Asegúrese de que el código fuente que tiene el cliente no sea suficiente para jugar, es decir, implemente partes relevantes de la lógica de los juegos fuera del alcance del cliente: en el servidor. Cómo se puede hacer esto depende mucho de cómo funciona el juego.

Además de eso, puede intentar ofuscar el código para hacer que la ingeniería inversa sea más difícil, firmar digitalmente cualquier mensaje del servidor para que un atacante no pueda falsificarlo (aunque podría cambiar el código para deshabilitar la comprobación de firmas) ... Pero al final solo puedes hacerlo más difícil y no imposible. Los jugadores conocedores podrían, por ejemplo, tratar de escribir su propio servidor que implemente una lógica de juego similar a la que ya tiene para dejar de depender de sus servidores.

Esto significa que debe ser más fácil y más atractivo pagarte en lugar de intentar piratear el juego. Puede ayudar a esto si el juego es lo suficientemente barato para empezar. O si hay elementos atractivos fuera del juego que valgan la pena pagar.

En cuanto a hacer que el pirateo sea más difícil, podría ser útil tener varias versiones del juego con diferentes tipos de protecciones en el mismo, de modo que los hacks "genéricos" solo cubran algunas de las versiones del juego, lo que hace que sea más barato solo para comprar. de para hackear el juego. O haga que las partes de la comunicación sean específicas para cada instalación del juego, es decir, dependiendo de la identificación del usuario usuario para la autenticación. Otra forma contra la propagación de hacks genéricos es lanzar nuevas versiones regularmente que interactúen de manera diferente con el servidor y que requieran el desarrollo de un nuevo hack, lo que frustrará a los usuarios que confían en los hacks en lugar de pagar.

    
respondido por el Steffen Ullrich 07.10.2018 - 08:40
fuente

Lea otras preguntas en las etiquetas