Enviando paquetes de forma segura sin que sean falsificados

2

Estoy trabajando en un juego multijugador simple para romper el hielo con la programación en red. Tengo un sistema en el que si el jugador se mueve, el servidor recibe un paquete de movimiento que contiene algunas cosas, como la marca de tiempo en que se envió el paquete, las teclas que presionaron codificadas en un byte, la ID única de los jugadores y su posición.

¿Qué pasa si el jugador puede de alguna manera enviar un paquete fingiendo que su ID es X, donde X es algún ID aleatorio de jugador o moderador? ¿Me estoy acercando a este paquete incorrecto, debo cifrar los paquetes? ¿O existe un método comúnmente utilizado en los protocolos de red de juegos para garantizar que los paquetes sean quienes dicen ser?

    
pregunta Jon Blow 16.04.2016 - 01:46
fuente

1 respuesta

6

¿Has oído hablar de JWT o sesiones sin estado?

Esto suena como un trabajo para un paquete cifrado que se envía al cliente y se devuelve para que se envíe el siguiente paquete. Este token web JSON se puede usar para indicar quién habla con su servidor al contener la información que necesita en un formato cifrado para garantizar que las cosas sean seguras y compatibles. Esto se hace mejor a través de una conexión encriptada.

Un ejemplo

Andy y Deli están jugando un juego. Andy obtiene un JWT con su información, y Deli obtiene un JWT con su información.

Parte de la información en el JWT es la misma (identificación del juego, metadatos del juego, etc.) y otra parte es única (identificación única del jugador, ip del jugador, otra cosa exclusiva del jugador).

Cuando Andy se comunica, el JWT se envía junto con sus paquetes y verifica su información única. Una vez que se verifica eso, su movimiento se realiza y se reenvía. A continuación, recibe información específica ALTERNA (como la actualización de la hora del último movimiento de este jugador) y se la devuelve, y el movimiento se envía a todos los demás.

Ahora Deli quiere hacer trampa. En su lugar, coloca la identificación única de Andy en su movimiento y la envía para que parezca que Andy hizo un nuevo movimiento en un mal lugar.

El JWT está decodificado, y se ve que Deli está haciendo trampa, por lo que Deli recibe una patada y Andy gana de forma predeterminada desde que Deli envió un comando para un usuario que no es Deli.

Una rosa con cualquier otro nombre

A menudo verá que también se hace referencia a ellas como sesiones de cookies, sesiones sin estado, tokens web de JSON y muchos otros nombres, pero todos tienen la misma idea (y cuando se envían a través de TCP, generalmente están en las cookies)

¿Qué es una sesión sin estado?

Una sesión sin estado es una sesión que vive y muere con su token.
Por lo general, se cifran en el extremo del servidor con un secreto de servidor relacionado con lo que esté sucediendo. Estos tokens no viven en bases de datos, no reflejan ningún tipo de almacenamiento a largo plazo y caducan con el tiempo.

Para mantenerlos seguros, generalmente están encriptados con un conjunto de cifrado sólido, y un secreto de algún tipo que se descifra sobre la marcha, se modifica y luego se vuelve a cifrar. Esta información suele ser un documento JSON que contiene metainformación que no se modifica con frecuencia (si es que se hace) y que se puede enviar de un lado a otro y, dado que está cifrada, significa que cualquier modificación hace que sea nula .

Cualquier modificación a estos los convierte en nuevas sesiones, y cualquier dato en ellas se pierde. Esto significa que si realiza sus comprobaciones y saldos correctamente, incluso puede usarlo como una sesión completa para un usuario en la mayoría de los sitios web.

    
respondido por el Robert Mennell 16.04.2016 - 02:02
fuente

Lea otras preguntas en las etiquetas