Comment empêcher l'usurpation d'identité dans un jeu multijoueur?

Je pense aux clients usurpant des adresses IP, trompant les autres clients qu'ils sont le serveur; ce genre de choses. (Je ne sais pas grand-chose à ce sujet, donc si c'est complètement faux, veuillez me corriger.)

Que dois-je faire pour éviter cela? Parce que c'est un jeu en temps réel, si je devais utiliser le cryptage, j'utiliserais quelque chose de rapide et sécurisé comme RC4. Dois-je crypter les données des paquets avec une clé, que le serveur donne au client?

Si cela fait une différence, j'utilise UDP.

Une solution possible consiste à authentifier l'utilisateur à l'aide de TCP + TLS; puis, dans le même canal, utilisez quelque chose comme Diffie-Hellman pour négocier une clé symétrique. Enfin, cryptez chaque paquet UDP à l'aide d'un algorithme symétrique comme RC4.

Techniquement, vous n'avez pas besoin d'utiliser TCP + TLS pour négocier la clé symétrique si vous utilisez quelque chose comme SRP - rappelez-vous simplement que Diffie-Hellman propre est vulnérable à une attaque MITM .

Vous pouvez aller encore plus loin et utiliser le champ SEQ personnalisé dans vos paquets UDP (si vous utilisez une forme d'UDP fiable) pour implémenter une forme de cryptage en mode compteur - où vous ajoutez le numéro SEQ à la clé négociée pour chaque paquet; ce qui rend d'autant plus difficile le montage d'une attaque en texte brut connu.

Ne laissez pas votre serveur simplement distribuer des clés à volonté - un serveur «usurpé» pourrait tout aussi facilement distribuer sa propre clé; en défaisant le but de tout votre schéma de chiffrement. Le seul moyen sûr consiste à utiliser TLS ou la connaissance mutuelle (comme un mot de passe / hachage).

J'ai une formation éloignée (il y a 2 ans) dans le piratage, les paquets les plus difficiles à craquer (et ce que je vous suggère d'utiliser) utilisent une méthode de cryptage à clé symétrique que Jonathan Dickinson a décrite en bref. Vous devez utiliser TCP + TLS comme il l'a également mentionné. Cependant, il a dit une contre-séquence.

Je me suis heurté à des moments où un système de "preuve de piratage" des programmeurs était facilement usurpé parce qu'ils ont un système de comptage assez étrange pour que je puisse le casser sans connaissances en programmation et sans logique algébrique de première année. Tant que vous choisissez une méthode séquentielle appropriée, votre cible doit recevoir les données exactement comme prévu, ce qui signifie également que vous devez utiliser TCP pour les opérations les plus sécurisées.

De retour sur la voie de "dans mes expériences", un système que j'ai trouvé fonctionne de manière fantastique. Une méthode séquentielle basée sur le temps envoyé et le temps attendu. Étant donné que les paquets doivent toujours être reçus dans le bon ordre, usurper un paquet était alors presque impossible car je ne pouvais jamais prédire quand un paquet serait envoyé et quand il était attendu (entre un paquet et un autre) sans pirater au préalable le programme client.

La réponse courte

En bref: chaque structure de paquet aurait également un horodatage comme quand elle a été envoyée à la milliseconde. C'est sacrément simple et il est vraiment facile de vérifier si un temps est avant / après un autre temps. La raison pour laquelle cela est si logique est que le serveur peut toujours recevoir des paquets dans l'ordre avec usurpation d'identité, sans le temps d'authentification.

Ce n'est évidemment pas la seule méthode séquentielle ou même la meilleure de toutes les méthodes. C'est juste un que j'ai trouvé qui fonctionne très bien. Combiné avec TCP + TLS, vous ne devriez pas avoir trop de problèmes.

Personnellement, je n'irais pas trop loin trop tôt. Même si vous cryptez vos paquets comme Jonathan le recommande, les pirates comme mon frère accèderont simplement aux données des paquets avant qu'elles ne soient cryptées. Si des utilisateurs malveillants veulent entrer, ils trouveront un moyen d'entrer.

Maintenant que ce n'est pas le cas, il existe des moyens pour les développeurs indépendants de minimiser les dommages que les utilisateurs malveillants peuvent faire. Vous devriez probablement crypter vos paquets sortants, mais cela n'arrêtera que certains types d'attaques, ne vous laissez pas tromper en pensant que c'est désormais "anti-piratage". Pour vraiment désactiver les pirates, donnez aux clients le moins de contrôle possible pour changer la donne. L'un de ces gros MMO permettait aux clients de dire au serveur combien d'XP ils avaient gagné. Devinez ce qui s'est passé là-bas? Ne fais pas ça. Laissez le client dire au serveur qu'il veut lancer un super-sort sur la créature, puis laissez le serveur résoudre l'action, puis ajoutez l'XP lorsque la créature est morte. Les clients doivent être des terminaux légers, stupides, capables d'envoyer et de recevoir des commandes et de faire des prédictions (si nécessaire).le jeu et réagir aux commandes envoyées par les clients.

Les grandes sociétés de jeux utilisent ce qui précède en plus de quelque chose comme VAC ou PunkBuster pour empêcher les pirates connus de continuer à perturber les clients payants. Le fonctionnement de ces mesures de sécurité est gardé assez secret, mais je connais une méthode qu'ils utilisent: ils analysent les applications en cours d'exécution et les comparent à des listes de hacks connus. Une fois que vous avez été surpris en train de tricher, vous ne pourrez pas rejoindre les serveurs sécurisés VAC / PunkBuster.

Connexes: la logique du jeu sur le serveur! Bon ou Mauvais?