[RESOLU][UNET] Protéger une variable qui contient le nom de compte

[Farstone]

Salut, j'ai quelques problème a comprendre certaines choses quand il s'agit de serveur authoritative sur UNET, et j'aurais bien besoin de votre aide. J'ai fait un système de Master Server avec Unet , ainsi les joueurs peuvent crée leur propres serveur dédié et le master serveur me permet d'avoir un système de connexion/inscription global, voici un peu comment ça ce passe.
Le master serveur utilise NetworkServer.Listen et j'instancie un NetworkClient sur un autres script qui si connecte(jusque là ça marche).
J'envoie ensuite des messages au master serveur et vice versa pour me connecter ou afficher la liste des serveurs.
Si le client décide de se connecter à un serveur, un autre NetworkClient est instancié pour qu'il puissent aussi rester connecter au master serveur pendant ce temps (si jamais il y a besoin de ban ou autres, ca permet de garder un contrôle)
Et ensuite le client peux se connecter au serveur en gardant le pseudo de son compte lié au Master Server.
Ensuite pour ce qui est des serveur dédier c'est a peut prêt pareil, il utilise 1 NetworkServer et 1 NetworkClient pour rester en communication avec le master serveur.
Donc voilà finalement un système assez simple mais j'aurais besoin d’éclaircissement sur certains point.
Je me demandait dans ma configuration actuel quand même bien basé sur l'utilisation du master serveur, comment je pourrait éviter le joueurs de changer son pseudo sur son client (c'est très important qu'il reste inchangeable) car au moment de la connexion j'envoie les données entrée et demande au master si elle son correcte, si oui il peux ce connecter, mais ou va être stocker ce pseudo chez le joueurs qui serras utilisé pour ce connecter au serveur de jeu, j'avais pensé a lui attribué une ID pour ensuite récupérer le vraie pseudo en ce connectant au serveur de jeu mais sa reste pareil, rien n’empêche de changer l'ID (sans savoir a quel pseudo tu appartient c'est déjà mieux) sachant que le serveur est lui aussi connecté au master il doit bien y avoir un moyen de sécuriser tout ça quand même.
J'ai vraiment du mal quand il s'agit de serveur authoritative (sachant que dans cette example s'en est pas vraiment je ne fait qu'envoyer des messages au master)


Et une petite question en bonus, est-ce que l'utilisation de 2 NetworkClient dans le script du "client" peux poser problème ? J'ai fait des tests et il peuvent effectivement être connecté différemment sans problème mais une fois venu le moment de faire des SceneReady je ne sait pas trop si les 2 ne vont pas être affecté.
Je ne savais pas trop où poser la question étant donné qu'il n'y a pas de codes, mais ça ma quand même semblé être le meilleur endroit car j'attend des réponses potentiellement en c#
Pour ceux que ça intéresse, je me suis énormément inspiré de ce projet offert par un dev Unity pour faire ce système Master Server Sample (Unity Link)

Le texte est long et je ne me suis pas corrigé donc merci d'avoir lu et de vos potentiel futur réponses !

EDIT : Et si je générais une suite de chiffre et de lettres aléatoire a la connexion pour le client, et que je l'utilisait pour savoir vraiment qui il est a la connexion d'un serveur par exemple ça pourrait marcher ou il y a peux être plus simple, ça fait une genre de session ID unique par joueurs un peux compliquer,ensuite en me connectant a un serveur je lui donne cette session ID, il vérifie sur le master serveur qu'elle existe effectivement et renvoie le vrai pseudo du joueurs.

[ZJP]

Les méthodes sont nombreuses (malheureusement?!)
Pour un projet Desktop (souvent mon cas), utiliser les solutions exploitant le CPUID, ou l'Adresse Mac reste une bonne option.

https://www.google.fr/search?q=cpuid+wi ... ial+number
https://www.google.fr/search?source=hp& ... ac+address

Pour les Mobiles, l'IMEI sans doute...
https://www.google.fr/search?q=imei+unity3d

[Farstone]

C'est vrai que ça pourrait être intéressant mais dans quel sens tu le voie ? Forcer le client a donner son adresse mac au master serveur pendant la connexion, pour ensuite faire comme une session id ? Car 1 compte ne peux pas être lié a 1 adresse MAC, sinon mon idée dans l'edit tu en pense quoi, ça pourrait marcher non sachant que c'est le master serveur qui générerais la clef ? Je trouve ça plutôt sécurisé et avec une clef de 20 chiffre ça fait des billiard de possibilités donc pas de danger qu'il trouve celle de quelqu'un d'autres.
Cette clef serras divulguer au client l'utilisant, et au serveur dédié des joueurs (mais pas les client connecté a celui-ci) donc le seul soucis de sécurité c'est si un joueurs possédant un serveur dédié décide de récupérer les sessions ID des joueurs, pour éviter ça, à chaque fois que cette session ID serras solliciter le master serveur devras vérifier si cette clef n'est pas déjà en utilisation. Car au final avoir la session ID de quelqu'un de déconnecté ne sert à rien puisqu'elle sert seulement à stocker le pseudo et d'autres info, une fois la personnes déconnecté la clef est supprimé, et quand elle se connecte une nouvelle est généré selon le nom de compte entré pendant la connexion.

[ZJP]

Honnêtement, j'ai lu ta demande en diagonale car il y a beaucoup d'informations (et la ponctuation n'aide pas vraiment ).

J'ai surtout retenu que tu cherches une solution pour identifier de manière "presque certaine et efficace" un client parmi d'autres et lui attribuer un ID unique.

Un serveur générant l'ID (peu importe la méthode ou l'algorithme ) laisse le problème entier : comment l'associer à coup sur au bon client? (A moins que ce n'est pas vraiment ton principal souci et que j'ai mal interpréter ta demande?)

Forcer le client a donner son adresse mac au master serveur pendant la connexion...

C'est transparent pour le client. Pas de "zone de saisie" accessible, c'est l'API retenue qui accompli le travail. Sinon, cela perd de son intérêt.

[Farstone]

Salut ZJP, et désolé si mon post est mal expliqué, tu pourrait peux être me dire ce qui ne va pas pour les prochains. Pour en revenir à la question, le serveur sait déjà qui tu est car tu va te connecter avec un ndc et un mdp, ensuite le serveur vérifie si tu existe dans la base de données et dans ce cas tu peux te connecté, le problème c'est que je ne veux pas que le client transmette qui il ait seulement avec son pseudo.
Pour te donner un exemple, imaginons qu'un client se connecte et qu'il rejoigne le serveur dédié d'un joueur, c'est le client lui même qui va devoir dire qui il est, et c'est la le problème, si je gère ça seulement avec un nom d'utilisateur, rien n’empêche un pirate de modifier la variable du nom de compte pour ce faire passer pour un autre puisque une fois connecté au serveur on verras le pseudo des autres. C'est pour ça que je veux mettre en place cette sécurité pour éviter que le client transmette c'est information au serveur juste avec un nom de compte, mais plutôt avec une session ID qui elle contient son nom de compte ou "pseudo", et grâce a cette session ID le serveur dédié peux demander au master qu'elle est son pseudo. Mais ça laisse encore une petite faille car le serveur dédié va récupérer l'info de la session ID (Donc un pirate avec un serveur dédié modifier peux la récupérer) d'ou l'envie que cette session ID soit supprimer quand le client est déconnecté et régénérer a la connexion, ou mettre en place un système qui vérifierais a chaque utilisation de cette session ID si il existe déjà quelqu'un l'utilisant. C'est un peux compliquer à expliquer sans faire de pavé avec toutes les situation que j'aimerais éviter déjà que ça commence a être long... Mais j'espère que tu comprend ou je veux en venir.

Et bien sur quand je dit forcer le client à donner son adresse MAC je ne veux pas dire qu'il l'écrive lui même, mais plutôt forcer son PC a me donner l'adresse mac.

[ZJP]

Je vois.

Pas d'autre idée que de combiner PSEUDO + MDP + élément unique (numéro de série : CPU ou CG ou Carte mère ou HD ou..., Mac Address, IMEI etc...).
L'IP n'est pas a retenir car plusieurs personnes/clients peuvent habiter sous le "même toit".

Il y a (sans doute) d'autres options, mais personnellement c'est la méthode que je retient.

[Farstone]

Salut ZJP et merci de ta réponse. Je prenait bien le bon chemin ça me rassure, mais je pense générer une clef aléatoire à chaque connexion pour la rendre unique pour, comme je te l'ai écrit, rendre chaque session unique, même si l'adresse mac suffirait en réalité, elle reste moins sécurisé à mon gout peux être que je chipote un peu mais, on pourrait voir le scénario suivant ce produire :

-Le client se connecte et donne son adr mac comme clé, le master serveur trouve c'est infos utilisable et le stock dans une classe par exemple
-Un pirate connait l'adresse mac du client qui viens de se connecter.
-Le pirate se connecte et change ça clef avec celle du client.
-Il se fait donc passer pour cette personnes sur tout les serveurs de jeu, mais la duré de vie de cette clef est seulement valide tant que le client ciblé est connecté (ça pourrait très bien être l'adresse mac d'un dev dans le pire scénario).


Donc c'est un peux chipoter, mais si on peux rendre le tout plus sécuriser pourquoi s'en priver

Quelques remarque importante cependant :
Le fait que le client donne ça propre clef (donc son adr. mac) n'est pas vraiment moins sécuriser, certes il peux effectivement la changer avec celle d'un autres mais dans tout les cas, elle est quand même stocker côté client comme celle généré aléatoirement, mais je préfère quand même la version ou c'est le master serveur qui s'occupe de lui envoyé ça clef et stocker c'est infos sous cette clef.

Les problèmes que l'ont peux remarquer et qui son inévitable je pense, c'est que la clef a toujours besoin d'être stocker coté client et ensuite la master serveur la valide quand nécessaire. J'ai bien peur d'ailleurs qu'un pirate puissent tout simplement supprimer l'appel de cette fonction qui vérifierais la clef, c'est pourquoi les serveurs dédié la demanderont aussi. Dans ce cas la si la clef n'existe pas ou est déjà utiliser j'aimerais bien sanctionner mais comment ? Puisque la clef a été modifié, il n'y a aucune infos concernant ce compte qui peux être envoyer au master pour dire "banni ce compte". On en revient donc à l'utilisation de l'adresse MAC qui pourras être utilisé comme référence. Mais du coup ça crée un autres problème, si le packet de la clef mac est modifier au moment de la connexion pour une autres totalement bidon, ça reviendrais a dire au master "banni cette clef mac" qui n'existe pas.
C'est un cercle vicieux de laisser ça côté client, j’espère que je ne suis pas partit trop loin dans mes explication et que tu me suis toujours
Je suis vraiment perdu du coup, peux être devrais-je me résigner a laisser cette potentiel faille (quand même dur a exploiter) non punissable ?

[ZJP]

Comme dis, je n'ai pas de meilleurs solutions.

C'est pour un jeu/projet opérationnel?.

[Farstone]

Non c'est un jeu que je dev pour m'améliorer en réseau et dans tout les domaines de Unity, mais je ne compte pas pour autant bâcler le travail et compte bien tout donner.
Bon ZJP merci de ton aide, je pense que je vais laisser cette faille non punissable, a moins qu'une idée ne me vienne en tête pendant le code, de toutes façon avec une clef généré par le serveur, trouver celle d'un autre client serras mission impossible étant donner qu'une clef de 10 lettre/chiffre faire plusieurs billard de possibilité il me semble, et je suis obligé de la fournir au serveur dédié pour identifier le joueur ( a la base mon c'était but ).

[ZJP]

Pour renforcer la sécurité, rien n'oblige a transmettre (dans le cas d'une adresse MAC) que les octets de celle-ci.

"70-1A-04-5F-9B-3B"
peut être
"01FF78122596ACED3B64AE74DC70A0E9 etc etc etc"

Tu peux "noyer" les 12 caractères de l'adresse dans un string de taille quelconque constitué de caractères aléatoires. Seul le serveur connaitra l'emplacement (aléatoire?!) des bons octets.

Bref, des solutions ce n'est pas ce qui manque.....