Adresse IP

[Hideaki]

Hmmm je dirais que je donnerai à l'utilisateur une fonctionnalité du style « terminer toutes mes sessions » comme ça le problème du cybercafé est résolu.

En fait cela ne solutionne pas le problème, pendant que tu joues, tu laisses ta session ouverte tu peux faire plein de choses entre temps, tu ne penseras peut-être pas à te déconnecter de partout après tout, pourquoi tout fermer, comme tu joues sur plusieurs supports

Si vilain_pédo, de son prénom thierry, arrive a prendre la session de bobby alors oui tu as une sacré faille de sécurité. (En considérant bien sur que bobby n'y est pour rien).

Tu vas loin ... sans doute trop ... je vais prendre un cas extrême, le méchant prend le contrôle du pc et fait de vilaine chose avec, exemple du spam XD, tu verras dans tes logs uniquement l'IP du gentil simplet après si tu arrives à les différencier, dépose le brevet

D'autant plus si c'est son père, partageant l'IP de son fils pour allez draguer ses copines

Ici ton argument tombe à l'eau ... ce n'est pas à toi de savoir si c'est le père, le fils ou autre membre qui partage sa connexion internet, c'est au système judiciaire de s'en occuper. D'ailleurs comment pourrais-tu faire la différence ?

En fait, je considérais même comme une possibilité de pouvoir partager un compte pour jouer en coop il y a quelques jours.

Cela peut-être une bonne idée, mais tu pourrais sans doute faire la même chose avec des comptes différents qui jouent sur une même partie.

Parce que mega upload, leur comptes sont payants, vois-tu, c'est normal qu'ils chassent les multi connectés. Mais le jeu que je projette de faire sera gratuit.

Tu peux faire un jeu gratuit avec des bonus payants ou un système de don (en récompensant un peu les donateurs) exemple : payer le serveur.
Que feras tu dans ce cas ?

Que se soit un jeu gratuit ou payant, il est important de mettre en place un bon système de sécurité. Je vois un jeu même gratuit comme un service que tu proposes et ce n'est pas parce que c'est gratuit que tu dois faire l'impasse sur des choses essentielles comme la sécurité.

[niahoo]

Non mais attends, qui parle de faire l'impasse sur la sécurité ?

En fait cela ne solutionne pas le problème, pendant que tu joues, tu laisses ta session ouverte tu peux faire plein de choses entre temps, tu ne penseras peut-être pas à te déconnecter de partout après tout, pourquoi tout fermer, comme tu joues sur plusieurs supports

Et bien, c'est toi qui parlait d'oublier sa session ouverte dans un cyber, non ? Donc, si tu as oublié ta session ouverte, tu la fermes. Ton systeme de n'autoriser qu'une IP à la fois à le même effet, sauf qu'il est imposé.
on peut aussi lister toutes les sessions dernièrement ouvertes et sélectionner celles qu'on veut fermer si vraiment tu tiens à laisser celle du sous-sol avec la pages qui se recharge toute seule toutes les 5 secondes ouverte.

Tu vas loin ... sans doute trop ... je vais prendre un cas extrême, le méchant prend le contrôle du pc et fait de vilaine chose avec, exemple du spam , tu verras dans tes logs uniquement l'IP du gentil simplet après si tu arrives à les différencier, dépose le brevet

Ben, disons que pour poster avec le compte d'un autre joueur, le plus simple est quand-même de lui prendre sa session. (je voulais dire, se connecter avec son compte, je ne faisais pas allusion aux sessions php)

Ici ton argument tombe à l'eau ... ce n'est pas à toi de savoir si c'est le père, le fils ou autre membre qui partage sa connexion internet, c'est au système judiciaire de s'en occuper. D'ailleurs comment pourrais-tu faire la différence ?

Tu n'as pas compris. Je te disais que se baser sur l'IP pour vérifier l'identité d'un joueur je trouvais ça bancal. Premièrement parce que si tu as une faille que un pirate exploite et qu'il arrive à se connecter avec la session de bobby, bobby doit re-entrer son mot de passe à chaque fois qu'il veut faire une action.
Et si c'est la père de bobby qui lui nique sa session, derrière la même box, alors ton systeme de vérification de l'IP devient inutile. L'exemple est plus parlant si toute une cité-U partageant la même box joue à pirater la session de bobby-le-concierge de la cité-U. Mais tu as raison de dire que c'est à la justice de se démerder, seulement ça lui fera une belle jambe à la justice de connaître l'IP dans ce cas là.
D'autre part, ce problème se retrouve aussi en logant l'IP de chaque post, elles seront identiques et donc inutiles. Je voulais simplement montrer que bloquer les gens sur une IP c'est con.

Je ne comprends pas ce que fait le framework dont tu parles. Si c'est le pirate qui se connecte et qui prend le cookie en premier, il empêche bobby de jouer jusqu'au timeout du cookie ? Ou sinon, bobby se connecte en premier, ce qui empêche toute autre IP de se connecter par la suite, jusqu'au timeout du cookie, et dans ce cas bobby ne peut pas se connecter depuis la maison de cindy s'il a oublié de cliquer sur déconnexion ? (c'est pas un troll hein, j'y connais rien réellement)

Cela peut-être une bonne idée, mais tu pourrais sans doute faire la même chose avec des comptes différents qui jouent sur une même partie.

Peux-tu développer ? Effectivement le partage de compte ça peut rapidement devenir compliqué à gérer, surtout en cas de dispute/désaccord entre participants.


Et enfin pour mega upload, un compte MU ça se partage bien, mais un compte MMO beaucoup moins. Si le mec se paye un super bonus en € IRL , partage son compte et se fait niquer ses objets bah tant pis pour lui non ?


Mais bon, après tout, il est possible que je ne racontes que des conneries, il faudra que j'expérimente.

[Hideaki]

Et bien, c'est toi qui parlait d'oublier sa session ouverte dans un cyber, non ? Donc, si tu as oublié ta session ouverte, tu la fermes. Ton systeme de n'autoriser qu'une IP à la fois à le même effet, sauf qu'il est imposé.

Vu que tu as l'habitude de laisser tes connexions ouvertes pourquoi tu vérifierais ^^.

on peut aussi lister toutes les sessions dernièrement ouvertes et sélectionner celles qu'on veut fermer si vraiment tu tiens à laisser celle du sous-sol avec la pages qui se recharge toute seule toutes les 5 secondes ouverte.

Si tu tiens réellement à faire de la multi-session c'est, en effet, ton problème, mais les inconvénients qui irons avec aussi.
Je reprends ton exemple d'une fenêtre qui se recharge toutes les 5 secondes, pour l'exemple on va dire qu'il s'agit d'un chat (c'est le plus simple), le nombre de requête que ton serveur va recevoir explosera. Il y en a d'autres mais j'ai un peu la flemme à les exposés.

Ben, disons que pour poster avec le compte d'un autre joueur, le plus simple est quand-même de lui prendre sa session. (je voulais dire, se connecte avec son compte, je ne faisais pas allusion aux sessions php)

Dans cas là, indique que l'utilisateur A se connecter avec le compte de B, cela évitera la confusion

Tu n'as pas compris. Je te disais que se baser sur l'IP pour vérifier l'identité d'un joueur je trouvais ça bancal. Premièrement parce que si tu as une faille que un pirate exploite et qu'il arrive à se connecter avec la session de bobby, bobby doit re-entrer son mot de passe à chaque fois qu'il veut faire une action.

Oui mais une seule fois la suite de l'explication pour les sessions est plus bas.

Et si c'est la père de bobby qui lui nique sa session, derrière la même box, alors ton systeme de vérification de l'IP devient inutile. L'exemple est plus parlant si toute une cité-U partageant la même box joue à pirater la session de bobby-le-concierge de la cité-U. Mais tu as raison de dire que c'est à la justice de se démerder, seulement ça lui fera une belle jambe à la justice de connaître l'IP dans ce cas là.

Dans le cas du père, le but est juste de trouver le méchant, l'IP désignant le bon endroit à chercher, il n'y a pas de problème.
Dans le cas de la cité U, IP désignera le routeur de celle-ci d'ailleurs comme pour les routeurs des entreprises, ils loggent les IP internes et leurs sorties après ce n'est pas partout comme cela.

Si c'est le pirate qui se connecte et qui prend le cookie en premier, il empêche bobby de jouer jusqu'au timeout du cookie ? Ou sinon, bobby se connecte en premier, ce qui empêche toute autre IP de se connecter par la suite, jusqu'au timeout du cookie, et dans ce cas bobby ne peut pas se connecter depuis la maison de cindy s'il a oublié de cliquer sur déconnexion ? (c'est pas un troll hein, j'y connais rien réellement)

Je crois que tu as mal compris quand je parlais d'invalider la dernière session :
> A se connecte ... il a la session
> B se connecte ... la session de A est invalidé ... B a la session

Je me demandais aussi qu'es ce que tu appelais failles de sécurité car si une personne se connecte avec le login et le password de Mister A ce n'est pas une faille.

Peux-tu développer ? Effectivement le partage de compte ça peut rapidement devenir compliqué à gérer, surtout en cas de dispute/désaccord entre participants.

Cela revient au même que la création d'une guilde dont chaque membre pourrait effectuer des actions, par contre tu seras obliger de mettre en place la synchronisation ( accès concurrentiel ).

Et enfin pour mega upload, un compte MU ça se partage bien, mais un compte MMO beaucoup moins. Si le mec se paye un super bonus en € IRL , partage son compte et se fait niquer ses objets bah tant pis pour lui non ?

Si c'est voulu dommage pour lui, mais si c'est dû a un oublie comme pour le cyber, c'est à toi de limiter les dégâts

[niahoo]

Hmm beau dialogue de sourds. bon j'ai un peu la flemme de continuer mais juste un truc

> A se connecte ... il a la session
> B se connecte ... la session de A est invalidé ... B a la session

Donc en gros ton framework il ne fait .. rien ? il donne la session au dernier connecté et invalide les précédentes. donc B pique la session (sans avoir le mot de passe évidemment sinon comme tu dis ce n'est pas une faille) et A (bobby, le vrai gentil) se retrouve déconnecté, et ensuite ? il retape son mot de passe toutes les 30 secondes. Ce n'est pas suffisant comme protection.

Je trouve que lui afficher toutes ses connexions courantes – ce qui lui permet au passage de voir qu'il est encore connecté au cyber – est mieux. Dans tous les cas, et c'est ce que je disais, si le pirate est connecté il peut le voir aussi. C'est bien que la faille est ailleurs et bloquer les connexions sur les IP est inutile (dans ce cas là).

Fin bon, dans tous les cas, ça n'épargne pas l'expérience utilisateur du gentil. Après, j'admets volontiers que faute de mieux, à l'invite de session l'utilisateur se rend compte qu'il est déco tout le temps et donc qu'un autre profite de son compte.

Ou alors, comme je l'ai lu ici dans un autre topic, l'utilisateur est sur un iPhone et change d'IP à chaque requete. il envoie son mot de passe et se mange un header location vers /loginok/index, paf il change d'IP et se retrouve sur l'invite de mot de passe en boucle ?

Il y en a d'autres mais j'ai un peu la flemme à les exposés.

Non vas-y, parce que justement je base mon boulot sur un serveur Comet donc les requetes à la seconde il y en a et ce n'est absolument pas un problème. Le serveur web est prévu pour ça.

[Hideaki]

Hmm beau dialogue de sourds. bon j'ai un peu la flemme de continuer mais juste un truc

C'est ce que je me disais, on est d'accord sur ce point

Donc en gros ton framework il ne fait .. rien ? il donne la session au dernier connecté et invalide les précédentes. donc B pique la session (sans avoir le mot de passe évidemment sinon comme tu dis ce n'est pas une faille) et A (bobby, le vrai gentil) se retrouve déconnecté, et ensuite ? il retape son mot de passe toutes les 30 secondes. Ce n'est pas suffisant comme protection.

Comment B pourrait prendre la session de A sans avoir le mot de passe ? Si A retape B est déconnecté ... d'ailleurs à chaque connexion un cookie de sécurité est générée.
Si B sniffe la connexion A cela changera rien au problème quelques soient les moyens déployer, non ?

Je trouve que lui afficher toutes ses connexions courantes – ce qui lui permet au passage de voir qu'il est encore connecté au cyber – est mieux. Dans tous les cas, et c'est ce que je disais, si le pirate est connecté il peut le voir aussi. C'est bien que la faille est ailleurs et bloquer les connexions sur les IP est inutile (dans ce cas là).

Mais le pirate pourra aussi déconnecté le gentil non ? et pourra le déconnecté tout le temps sans que le gentil puisse faire la moindre chose. Je trouve que la multi-session possède plus d'inconvénient dans ce cas même si cela ne changera pas grand chose au final.
D'autres part, je ne bloque pas par rapport à l'ip mais par rapport à la connexion établie, d'ailleurs cela explique pourquoi le papa et son garçon ne peuvent pas jouer en même temps ...

Ou alors, comme je l'ai lu ici dans un autre topic, l'utilisateur est sur un iPhone et change d'IP à chaque requete. il envoie son mot de passe et se mange un header location vers /loginok/index, paf il change d'IP et se retrouve sur l'invite de mot de passe en boucle ?

Les cookies sécurisés servent à cela, IP au départ sert surtout à identifier l'auteur de la connexion.

Non vas-y, parce que justement je base mon boulot sur un serveur Comet donc les requetes à la seconde il y en a et ce n'est absolument pas un problème. Le serveur web est prévu pour ça.

Les serveurs web sont créés pour cela, c'est sûr. As-tu déjà des tests de charge ou de stress d'une application ?

[niahoo]

le papa et son garçon ne peuvent pas jouer en même temps ...

En gros, toute une cité-U à 3000 personnes (oui oui, le jeu dont on parle est super populaire \o/) ne peut pas jouer en même temps ?
après si le public visé est restreint ce n'es pas un problème, mais bon, FAIL quoi.

Ok pour les cookies sécurisés, ça permet de pas se loguer à chaque fois. mais tu esquives ma question: si un mec chope sa session, alors ton gentil user doit retaper son mot de passe à chaque fois ?
je pense qu'on s'en fout de l'IP quoi, faut juste, comme je le disais, traquer les autres failles à mort.

Comment B pourrait prendre la session de A sans avoir le mot de passe ?

ben justement, c'est çà les failles dont on parle. S'il ne peut pas voler de session ça sert à rien chercher à faire de la protection, celle-ci est déjà 100% finie et là tu te contentes effectivement de loguer les IP de connexion.

Pour le serveur web je sais qu'il encaisse facilement 50000 connexions sans broncher. Apres faut avoir le matos qui suit derrière, mais dans une optique de lancement avec 100 users max je pense que je suis tranquille avec un VPS à 1 Go/s trèèèès largement.
Le seul problème c'est le serveur du jeu qui lui doit assurer aussi bien que le serveur web et là c'est moi-même qui le code donc c'est pas gagné du tout ^^

[Hideaki]

En gros, toute une cité-U à 3000 personnes (oui oui, le jeu dont on parle est super populaire \o/) ne peut pas jouer en même temps ?
après si le public visé est restreint ce n'es pas un problème, mais bon, FAIL quoi.

Un cookie sécurisé par session donc ils peuvent tous jouer en même temps mais pas avec le même login.

mais tu esquives ma question: si un mec chope sa session, alors ton gentil user doit retaper son mot de passe à chaque fois ?

J'avais déjà répondu, il me semble, oui il se connectera de nouveau en invalidant la session du pirate après si le pirate lui a volé son mot de passe, il ne reste qu'à l'utilisateur la méthode du mot de passe perdu qui en généra un nouveau mot de passe.

ben justement, c'est çà les failles dont on parle. S'il ne peut pas voler de session ça sert à rien chercher à faire de la protection, celle-ci est déjà 100% finie et là tu te contentes effectivement de loguer les IP de connexion.

si elle est à 100%, IP de connexion ne sera pas suffisante pour ta multi-session.
Bien sûr si le méchant horrible tipiak prend possession de l'ordinateur du 7ème nain de blanche neige à savoir simplet.
La plus part des failles se trouvent entre le clavier et la chaise.

Pour le serveur web je sais qu'il encaisse facilement 50000 connexions sans broncher. Apres faut avoir le matos qui suit derrière, mais dans une optique de lancement avec 100 users max je pense que je suis tranquille avec un VPS à 1 Go/s trèèèès largement.
Le seul problème c'est le serveur du jeu qui lui doit assurer aussi bien que le serveur web et là c'est moi-même qui le code donc c'est pas gagné du tout

50000 connexions, tu veux dire requête ou une simple connexion à ton application ? 50000 requêtes cela ne va pas aussi vite que cela surtout avec les accès en base etc en supposant que ceux qui se connecte, on leur cache optimisé car sinon il y a les images à charger * 50 000 cela représente beaucoup après cela dépend de ton serveur

Après pour 100 utilisateurs cela devrait être suffisant ^^

[niahoo]

J'avais déjà répondu, il me semble, oui il se connectera de nouveau en invalidant la session du pirate après si le pirate lui a volé son mot de passe, il ne reste qu'à l'utilisateur la méthode du mot de passe perdu qui en généra un nouveau mot de passe.

Oui mais là, le pirate, il a trouvé une faille (et n'a pas le mot de passe user), n'oublie pas, donc paf, il reprends la session illico, et bim, l'user doit encoooore retaper son mot de passe. Par contre, du coup ça fonctionne bien, il n'est pas utile dans ce cas le logguer l'IP sur chaque post puisque une seule connexion simultanée est possible). Ça a au moins le mérite d'avertir l'user qu'il y a un problème, mais se reposer là dessus c'est faible je crois, moi c'est tout ce que je disais. Le mec en face peut même être très vicieux et monter un proxy en local chez lui et exploiter une faille pour rediriger l'user sur sa box afin que l'user ait la même IP que lui. Donc voilà, avant de se baser sur l'IP je commencerais par exploiter tous ces genre de tricks pour les empêcher.

Pour le serveur, je parle de pollings simultanés, il faut bien au départ (et de temps en temps) charger une image, un css ou un .js
Mais voilà l'idée c'est d'échanger du JSON gzipé.

Pour la multi-session je me tâte, un systeme de guilde serait pas mal en effet, je regarde la dessus

[Hideaki]

Tout dépend d'où vient la faille du serveur donc chez toi ou chez l'utilisateur ?
Si cela vient d'un problème de l'utilisateur, on ne peut rien faire.
Par contre si cela vient de chez toi :
-> Le problème vient d'un framework,
-> Le problème vient d'un langage ( au hasard PHP ) ou d'un protocole.
Dans les 2 cas, regarder s'il n'y a pas de mise à jour disponible, en attendre une ou suivre les instructions pour le combler en attendant une prochaine mise à jour.
-> Le problème vient de ton code, tu n'as pas su compartimenter correctement les rôles ou que ta conception/réalisation est mauvaise d'où l'intérêt de l'architecture n-tiers ( promis je ne suis pas sponsorisé ).

Pour ton jeu, si tu optes pour la multi-session, comment connaitras-tu le nombre d'inscrit à ton jeu par exemple ?
Tu pourras juste faire une vague évaluation.

Comme cela ne concerne plus les IP, si tu souhaites continuer la discussion, je te propose de soit continuer en MP ou créer un nouveau sujet.

[niahoo]

Ben la faille est sur ton serveur ... si ça vient de l'utilisateur ça ne sert à rien de se compliquer, à moins de lui mettre des messages en rouge fluo partout avec des images démoniaques je vois pas.

Si ça vient de ton code par contre, enfin si tu as bien lu mes posts c'est la situation sur laquelle je me base de puis le début de ma participation à cette discussion – et c'est pourquoi je qualifiais cette dernière de dialogue de sourds – j'expliquais simplement que bloquer sur le simple examen de l'IP ne nuisait finalement qu'à l'utilisateur. Et que dans ces conditions, il fallait alors libérer les IP et donc loguer les IP de tous les posts.

Pour le reste, pas besoin de continuer, je n'ai pas encore réfléchi correctement à ça. (ceci dit, connaitre le nombre de comptes actifs me suffirait pour les stats je suppose)