<YannK> J'ai découvert une super série d'un gars sur YT qui fait une suite de vidéos sur les techniques pour créer un MMORPG avec Godot, avec toutes els problématiques serveur (gateway, échnages sécurisés, déplacement de certains services sur le serveur pour éviter els exploits etc. etc.) :
https://www.youtube.com/playlist?list=PLZ-54sd-DMAKU8Neo5KsVmq8KtoDkfi4s <YannK> C'est à la fois très précis niveau implémentation, mais il explique aussi les questions de façon un peu théorique pour qu'on comprenne les raisons de ses choix.
<YannK> Je n'ai pas fini de regarder, mais jusque là j'ai trouvé ça de très très bonne qualité
<YannK> Et du coup, j'y ai appris qu'un serveur seul sous Godot ne peut pas gérer plus de 4095 connections en même temps
<YannK> Et il parle donc des méthodes pour ne pas avoir son architecture limitée par cette contrainte
<Link Mauve> C'est dû à quoi ?
<YannK> La contrainte des 4095 ?
<Link Mauve>: Oui.
<YannK> Hard codé dans Godot, mais je ne sais pas pourquoi
<YannK> Mais de toute façon, on arrive à des goulots bien avant à d'autres niveaux
<YannK> Tycho, si jamais tu as un jour l'envie de regarder cette série, j'aimerais bien ton avis sur son approche de la sécurité car il semble prendre ça très au sérieux
<Tycho> oh god, il y a tellement de contenu...
<YannK> Ah mais carrément, je trouve que c'est une des meilleurs chaines Godot que j'ai trouvées, avec GDQuest
<Tycho> bon, je commence à regarder vite fait
<Tycho> je pense faire mes remarques au fur et à mesure
<Tycho> déjà je ne regarde pas tout, juste els vidéo qui causent de sécu
<Tycho> donc je commance avec « Godot Multiplayer - Player Authentication | Godot Dedicated Server #3 »
<Tycho> à 4:40, il parle de filtrage d'IP afin de ne pas totalement exposer le serveur d'auth : c'est OK, mais perso je pousserai plus loin en regroupant tous les serveurs dans un réseau privé et donc le serveur d'auth ne serait que dans ce réseau local, pas du tout sur internet
<Tycho> et je précise que disposer d'un filtrage par IP alors que l'on est dans le réseau privé peut rester une bonne idée suivant la sensibilité des données
<Tycho> ça ne coûte pas plus cher et ça augmente la sécurité, alors go
<Tycho> à 5:14, il parle d'un token : alors ça se fait et c'est un choix respectable
<Tycho> après, il y a également d'autres méthodes qui sont également cool
<Tycho> le choix de la solution va surtout dépendre ses caractéristiques et des contraintes que l'on a
<Tycho> je ne sais pas si c'est adapté à un MMORPG, mais un biscuit (
https://www.biscuitsec.org/ ) c'est super cool
<Tycho> genre c'est adapté dans le sens où ça aide énormément à scale la solution, après le seul point qui m'inquiète c'est la taille du biscuit qui devra être transmis sur le réseau
<YannK> Super, merci Tycho de ces retours. pourrais-tu juste mettre un tag genre #godotmultiplayerGDCtutorial comme ça je pourrais ensuite compiler tout ça à la fin ?
<Tycho> punaise, j'ai vraiment l'impression qu'il stock le mot de passe en clair
<Tycho> NE JAMAIS FAIRE ÇA
<Tycho> j'ai pas mal attendu afin de voir si c'était temporaire et qu'il allait corriger
<Tycho> ça n'a pas l'air d'être le cas
<Tycho> et bien entendu, la comparaison du mot de passe est faite avec ==, ce qui est totalement sensible à une timing attack
<Tycho> pareil pour le check de l'existence du client, ce qui est fun car il explique pourquoi il ne faut pas laisser savoir si c'est le login ou le mot de passe qui est mauvais
<Tycho> mais bon, c'est moins grave
<Tycho> allez, je passe direct à « Network Token Verification | Godot Dedicated Server #6 »
<Tycho> bon, sa génération de token est pourave
<Tycho> 32 bits d'entropie c'est pas assez
<Tycho> bon, vu qu'il y a un timestamp ça passe, mais du peu que j'ai vu du code ça a l'air potentiellement foireux
<Tycho> sérieusement mec, faut 128 bits d'entropie pour un truc unique et fiable
<Tycho> puis le SHA-256 sert à quedal là
<YannK> Sur le stockage du mot de passe en clair, il explique que c'est mal et pourquoi et ensuite il a une vidéo sur le hash et le salt
<Tycho> ha ok, faudra que je regarde ça alors
<Tycho> punaise, le timestamp qui à l'air sujet au bug de 2038
https://en.wikipedia.org/wiki/Year_2038_problem <YannK> Ses titres sont assez explicites, du coup tu vois comment il développe peu à peu les concepts
<Tycho> rectification : ça semble dépendre d el'implem de l'OS, donc ça doti passer
<Tycho> franchement, la génération du token c'est mauvais
<Tycho> il prend 32 bits, qu'il hash afin d'ateindre une longueur de 256 bits (mais qui ne dispose toujours que de 32 bits d'entropie) qu'il va représenter sur 64 caractères donc 512 bits
<Tycho> bref, prendre 128 bits d'aléat et les représenter en hexa divise la longueur de la première partie du token par 2 et en améliore considérablement la sécurité
<Tycho> à noter que ça ne sert à rien de prendre plus de 128 bits d'entropie
<Tycho> c'est juste de la perte de ressources
<Tycho> fun fact : sa fonction de purge des tokens expirés pourrait etre plus performante
<Tycho> supprimer 1 par 1 chaque token est pourri car sa liste est de base ordonnée (et s'il veut il peut s'en assurer de manière plus fiable), donc il suffit qu'il repère le token valide le plus vieux et qu'il supprime tous ceux qui sont situés avant dans la liste
<Tycho> et du coup regarder la liste par le début ou par la fin se calcule en fonction des usage, faut monitorer et faire des stats afin de savoir lequel des 2 modes est le plus efficient (pareil pour la fréquence de purge d'ailleurs)
<pep.>: TIL biscuit
<Tycho> ouais, un biscuit (ainsi que d'autres technos telles qu'un HMAC, JWT, etc) permettrait d'éviter la boucle qu'il fait pour attendre l'éventuel retard de réception du token par le serveur de jeu
<Tycho> OMFG
<Tycho> la jolie faille :p
<Tycho> je reprend la vidéo après avoir mangé et soudainement, en regardant sa boucle, ça me saute aux yeux
<Tycho> while OS.get_unix_time() - int(token.right(64)) <= 30
<Tycho> vous l'avez ?
<Tycho> token.right(64) ← il utilise une donnée non-authentifiée provenant de l'utilisateur dans un calcul
<Tycho> un token forgé dans lequel on met tout au max et sa boucle ne s'arretera jamais
<Tycho> enfin théoriquement si, mais vu la durée le serveur sera fermé/reboot/whatever bien avant que ça ne s'arrete
<Tycho> lui qui est parano au sujet des DOS causés par des connexions trop longues, il a oublié cet aspect là
<Tycho> au passage, je me demande ce qu'il se passe si le token est plus court que prévu et que du coup il n'y a pas la longueur nécessaire pour juste le timestamp
<YannK> Je crois qu'il fait un tru ensuite contre cet exploit justement, Tycho
<Tycho> sinon, vu que le token est détruit, je confirme que ça peut totalement être remplacé par un mécanisme de HMAC qui est moins sujet à ce genre de problèmes, faut juste prévoir une rotation des clés une fois de temps en temps (par exemple, sur EvE online il y a 1 reboot chaque jour, c'est le moment idéal pour changer la clé)
<YannK> Comme il tente de faire des vidéos pas trop longue, il implémente un concept à la fois, donc des fois il laisse les choses un peu "en l'état", mais il l'expliquait je ne sais plus quand
<Tycho> YannK: exact, il en parle
<Tycho> j'avais juste pas atteint l'endroit
<Tycho> c'est dans la même vidéo, mais un peu plus loin
<YannK> ouf, ça va alors
<YannK> Comme ile me paraissait sérieux, j'ai eu peur qu'il ait laissé un éléphant dans la pièce
<YannK> (ce qui aurait hypothéqué le sérieux de l'ensemble je trouve)
<Tycho> ya encore la génération du token qui est pourrie
<Tycho> et j'ai pas encore vu sa correction sur le stockage du mot de passe
<YannK> Disons que ce qui m'intéresse aussi, c'est la logique générale, si elle te semble sérieuse et cohérente. Les méthodes utilisées pour implémnter la logique m'inquiètent moins car ça peut toujours s'améliorer, comme tu le propose juste en regardant rapidement, déjà
<Tycho> je suis quand même déçu qu'il fasse le test en conservant sa fonction vulnérable à une modification du token
<Tycho> allez hop, go « DTLS Encryption with SSL Certificates | Godot Dedicated Server #7 »
<Tycho> oula, j'aime pas le début
<Tycho> OMFG
<Tycho> un certif auto-signé
<Tycho> désolé mais c'est merdique
<Tycho> NE PAS LIER LA GÉNÉRATION DU CERTIFICAT AU SERVEUR
<Tycho> on fait ça à coté
<Tycho> punaise c'est de la torture cette vidéo de création de certif auto-signé
<Tycho> puis RSA bien entendu, c'est pas mauvais mais c'est pas le plus optimal
<Tycho> et puis RSA 4096, genre le mec crois que parce que 4096 est supérieur à 2048 c'est forcément mieux (pas trop, ça prend juste plus de ressources)
<Tycho> ha, il cause enfin de la différence entre un vrai certif et une bouze auto-signée
<Link Mauve> (Beaucoup plus de ressources.)
<Tycho> le mec qui dit qu'un certif bien signé ça coûte du fric...
<Tycho> dans une vidéo de 2020, donc quand let's encrypt existe déjà
<Tycho> et fournit des certif gratos et qu'en plus c'est automatisable
<Tycho> je me pose des questions sur l'utilisation de DTLS au lieux de TLS
<Tycho> vu qu'il ne chiffre que les communications qui ne sont pas critiques (donc en UDP ou similaire), il n'en met que sur les connexions qui peuvent se permettre d'etre en TCP et donc TLS
<Tycho> peut-etre que c'est une limitation de godot
<Zatalyz> Tycho, tu es OK pour que je mette tout ça sur le forum par la suite ? ça facilitera pour retrouver les infos
<Tycho> Zatalyz: yep !
<Tycho> bon, ya pas de véritable config de DTLS, du coup faut faire confiance à godot
<Tycho> allez, je passe rapidement sur « Create New Account Function | Godot Dedicated Server #8 »
<Tycho> a priori ya pas grand chose d'intéressant mais au cas où je regarde à certains moments
<YannK> C'était surtout l'architecture de connexion sur laquelle j'avais envie d'avoir tes retours, mais si tu es curieux du reste, fais toi plaisir
<YannK> Et du coup tu penses qu'on devrait mettre en place avec un certificat Let'sEncrypt dès le départ ?
<Tycho> allez hop, go sur « Salting and Hashing Passwords | Godot Dedicated Server #9 »
<Link Mauve> YannK, oui, ça ne coûte rien de plus que de l'utiliser pour un site ou quoi.
<Deed>: humm, je vais peut-être dire une bêtise mais je ferai une connexion en "ssh" avec une clé pour la connexion client - serveur
<Tycho> YannK: perso j'utiliserai vraiment un token client signé avec un HMAC plutot que de transférer le token au serveur de jeu, mais sa solution reste correcte, modulo la génération de la partie aléatoire
<Tycho> bon, génération du sel pour le hachage de mot de passe : même erreur
<Tycho> sérieux, c'est quoi la facination morbude des devs pour les fonctions de hachage ?
<Tycho> OH SHIT
<Tycho> sa fonction de hachage maison est, sans surprise, totalement pourrie
<Tycho> après, comme il l'a expliqué avant, les vraies fonctions de hachage ne sont pas implémentées de base
<Tycho> le mec ose comparer sa méthode à la con à bcrypt, ça me tue
<Tycho> rien que sa manière d'intégrer le sel est mauvaise
YannK imagine Tycho en train de faire des bonds sur sa chaise
<Tycho> et du coup ya une autre failel de sécurité qu'il n'a pas vu venir : un utilisateur qui balance un mot de passe volontairement erronné mais absolument énorme (plusieurs milliers de caractères)
<Tycho> sans limite haute, sa fonction de hachage va prendre un temps monstrueux
<Tycho> sérieusement, réimplémenter PBKDF2 c'est pas bien compliqué vu qu'il a déjà les fonctions de hash qui vont bien (et sans doute un HMAC)
<Tycho> en plus (comme PBKDF2), ya juste une protection sur le temps, yen a pas sur l'utilisation de la mémoire
<Tycho> YannK: si tu as la doc du langage python-like qu'il utilise ça m'intéresse
<YannK>
https://docs.godotengine.org <Tycho> merci
<Tycho> grrrrrr, il compare les hash direct avec ==, c'est pas bien >.<
<Tycho> bon, il y a les HMAC de base, c'est cool
<Tycho> sérieux, il aurait pu au moins utiliser ça
<Tycho> tiens, ya un constant_time_compare donc, dès qu'on touche à de la crypto, faut l'utiliser au lieux de ==
<Tycho> au passage, la partie crypto dispose aussi d'un generate_random_bytes, ce qui semble bien mieux que ses truc d'int random
<Tycho> bon, du coup je vais m'arreter là je pense
<Tycho> YannK: du coup, tu penses utiliser son système en corrigeant les soucis ou bien passer sur ma méthode à base de HMAC ?
<YannK> Je te fais confiance pour les meilleurs choix à faire en terme de sécurité
On en est très loin de faire le système, mais de savoir qu'on peut faire un truc très propre en restant dans Godot pour tous les éléments me plait bien. Si tu n'y vois rien de réellement problématique dans l'infra proposée et les seules problématiques comme étant améliorables à un niveau acceptable, ça me va parfaitement
<YannK> Je compilerai tes remarques sur HMAC et Let's Encrypt en particulier pour lui faire un retour
<Zatalyz> L'idée est plus de voir quelle architecture sera correcte pour tout ça
<YannK> C'est ça, si on peut avoir un seul environnemùent de développement avec des fonctions intégrées qui se complètent, j'aime bien
<Zatalyz> là, il semble y avoir des bases desquelles partir, modulo plus d'attention à certains aspects de sécurité (genre le choix des librairies, si j'ai compris, mais pas que)
<YannK> Surtout que Godot a bossé sur cette partie pour la 4.0
<Zatalyz> plus le temps passe et moins vous gardez de trucs du Nel par contre. Bon, ok, sur la partie sécu c'est aussi bien, mais...
<Deed> j'allais le dire Godot 4 a bien bosser ce côté
<Tycho> en totu cas godot n'a pas l'air d'avoir intégré de fonction de hachage de mots de passe :/
Zatalyz se demande si un jour elle verras le MMORPG
<YannK> C'est à dire qu'on a un dev qui bosse sur Godot, là contre 0 qui étudient NeL, donc je préfère aller par là
<YannK> (l'article sur le Multiplayer dans Godot 4 :
https://godotengine.org/article/multiplayer-changes-godot-4-0-report-3 )
<Deed> Zatalyz: on s'appuie sur NeL pour l'exemple quand même
<YannK> Tout à fait Deed, je suis d'ailleurs en train de réfléchir à la façon dont on pourrait se baser sur les datasheets en XML pour penser une achitecture des données dans Godot
<Zatalyz> oui
<YannK> Tycho, dans l'article, il y a un exemple de code avec une méthode appelée dtls_server_setup ça te plaît ?
<Tycho> YannK: quel article ?
<YannK> Celui que je viens de partager
<Tycho> ha, vu
<Tycho> je regarde
<Tycho> nope, ça load juste la clé privée et le certif
<Tycho> confirmé :
https://docs.godotengine.org/en/latest/classes/class_enetconnection.html#class-enetconnection-method-dtls-server-setup <Zatalyz> Le souci c'est le manque de monde. Chaque chose qu'on recode autrement demande du travail (sans parler de tout le reste : penser au gameplay, au gamedesign, au monde, etc). Donc attention, la priorité doit vraiment être d'avoir un bout de démo qui fasse envie. Il faut laisser de côté toutes les fonctionnalités secondaires pour éviter de perdre du temps dessus. Et le réseau, c'est un gros bout, donc je préfère vraiment qu'on s'y attaque quand il y aura du monde (ou alors si quelqu'un n'est motivé que par ça), mais qu'avant on est un bout de carte joli où se balader (même si on ne fait pas grand chose de plus)
<YannK> Ah oui. Ça n'a rien à voir avec le premier client sur lequel on bosse, Zatalyz
<Zatalyz> oui oui, je sais, mais je préfère bien enfoncer le clou
<YannK> C'est juste pour savoir si on sera coincé par Godot à un moment ou pas. Et là il semblerait qu'on puisser petit à petit développer tout ce dont on aura besoin dedans, sans devoir chercher de quoi le compléter
<Zatalyz> Oui, moins on a besoin de recoder des bloc, mieux c'est aussi;
<Zatalyz> là, de ce que dit Tycho (tu me corrige si j'ai mal compris), il y aurait des blocs à coder pour utiliser des librairies de crypto correctes ; mais, sachant ça, on peut y remonter à godot, les orienter vers les bonnes solutions, et espérer que d'ici à ce qu'on bosse sur le réseau, ça soit implémenté
<YannK> Il y a plein de parties dans le NeL qui sont des outils que Godot intègre nativement, donc si ils conviennent, autant prendre els fonctions les plus haut-level du NeL et els réimplémenter dans Godot proprement plutôt que de chercher à bidouiller en connectant ce qu'on peut à un NeL boiteux
<Zatalyz> oui
<Tycho> Zatalyz: pour le token d'auth basé sur un HMAC c'est simple à faire car godot intègre ce qu'il faut, je peux meme contribuer
