Forum d'entraide PHPFrance

Bonjour à tous

Je suis entrain de mettre au point un système de jeux sous forme de championnat et parrainage sur le site de ma boite.
Les joueurs doivent s'inscrire, s'identifier et jouer à un maximum de jeux pour gagner des points. Côté sécurité, on est pas mauvais.

Mais voilà... je suis confronté à un problème que je qualifierais de fatiguant .
Les parrains récupèrent un pourcentage des gains de leurs filleules et donc des petits malins pourraient s'auto-parrainer et ainsi gonfler artificiellement leurs points.

Comment éviter cela ?
En composant une clef unique par utilisateur... et la dessus je crois avoir tout lu : IP+email+nom+prénom+adresse+numéro de téléphone etc etc...

N'aurais t-il pas un moyen plus simple pour dissuader les éventuels "tricheurs", tout au moins limiter la casse ?

NB : J'ai laissé tomber les IP et les cookies car plusieurs de nos joueurs se partagent un même PC.
Une autre solution serait de faire un "enquête" à chaque inscription... nous n'avons ni l'envi ni le temps de jouer à la DST
... de plus nous avons un potentiel de 4000 joueurs...

Voilà...
Merci par avance

It's Fun to Have Fun But You Have to Know How!

Il manque une option à ton sondage : "Non, pas eu l'occasion"

Pour ton problème, tu pourrais limiter les risques en te basant sur l'adresse de courriel du parrain en rendant celle-ci obligatoire à l'inscription : dans la mesure où un parrain ne peut pas avoir deux adresses sur le même profil, le filleul devra avoir la bonne. Le risque serait qu'un membre s'inscrive plusieurs fois avec plusieurs adresses différentes, mais tu peux faire un comparatif sur les couples adresse/pseudo pour trouver des possibilités de multi-inscriptions.

Dans les problèmes de double-compte il n'y a aucune solution efficace à 100%, à part rendre l'inscription payante (auquel cas si double-compte il y a, tu t'en fous chaque compte a rapporté autant que les autres).

Une des solutions les plus efficace est de stocker les mots de passe en clair et de détecter les similarités sur IP/login/email/password. Avec un algorithme grossier tu peux faire une première détection, puis déterminer les vrais double-comptes "à la main" tu n'y couperas pas : aucune détection de ce type n'est possible sans intervention humaine.

Dans les problèmes de double-compte il n'y a aucune solution efficace à 100%, à part rendre l'inscription payante (auquel cas si double-compte il y a, tu t'en fous chaque compte a rapporté autant que les autres).

Une des solutions les plus efficace est de stocker les mots de passe en clair et de détecter les similarités sur IP/login/email/password. Avec un algorithme grossier tu peux faire une première détection, puis déterminer les vrais double-comptes "à la main" tu n'y couperas pas : aucune détection de ce type n'est possible sans intervention humaine.

D'accord, sauf sur les pass en clair: un pass codé/hashé/crypté, s'il est le même au départ sera le même à l'arrivée. et on ne conserve jamais les pass en clair!

A+

Pascal

D'accord, sauf sur les pass en clair: un pass codé/hashé/crypté, s'il est le même au départ sera le même à l'arrivée. et on ne conserve jamais les pass en clair!

C'est ce que je pensais mais Merrick le webmaster de jdr-delain.net m'a clairement fait changer d'avis.
Il administre un jpc et le problème de double-comptes est épineux. La plupart du temps les utilisateurs de double-compte utilisent le même mot de passe, mais également souvent des mots de passe très proches ("monmdp1", "monmdp2"), le hash dans ce cas là nous fait perdre complètement cette possibilité de détection.

Comme l'art de détecter les double-comptes est déjà éminemment délicat, il s'agit de disposer du maximum d'informations disponibles, mais il y a des solutions (parfois un peu tordues) pour avoir les infos hashées sur le serveur, et garder une copie "en clair" sur une base non publiée. J'avais fait ça il y a quelques années : sur la base les mots de passe étaient hashés, et sur un fichier du serveur j'ajoutais à la ligne des requêtes "REPLACE INTO ..." à chaque création/modification de mot de passe. Régulièrement je me connectais pour récupérer ce fichier et exécuter les requêtes sur ma base locale ( il aurait été possible de faire un robot mais j'avais la flemme, d'autant que cette solution n'a pas duré longtemps, je l'avais mise en place pour le rappel de mdp, j'ai vite réalisé qu'on pouvait se contenter d'en générer un nouveau aléatoire )



Quoiqu'il en soit, imagine que j'ai un triple-compte chez toi :
- le soir je me connecte à la maison, avec un login et un mot de passe (dont je n'ai pas besoin de me souvenir, mon navigateur le fera très bien pour moi)
- le matin ou l'après-midi quand j'ai le temps, au boulot je me connecte, avec autre un login et un mot de passe (dont je n'ai toujours pas besoin de me souvenir, mon navigateur le fera très bien pour moi)
- entre midi et deux je me connecte avec la connexion wi-fi du mac-do, ou je fais un tour au cyber-café et là j'utilise un 3e compte (le seul dont j'ai besoin de me souvenir pour le coup).

Comment vas-tu détecter ça ? Le seul moyen sera l'analyse des transactions entre les différents comptes, et pour ça l'algorithme de pré-détection dépendra complètement de ton site, et l'intervention humaine sera absolument indispensable.

Et dis-toi bien que les fanas des double-compte (en particulier si possibilité de récompense il y a) sont largement capables de suivre le scénario que je t'ai indiqué ^^

avec le scénario, OK

A+

Pascal

avec le scénario, OK

Non non mon scenario ne justifie pas plus de stocker les mdp en clair ou en crypté, puisque dans ledit scenario, l'utilisateur n'a à réellement se souvenir que d'un mot de passe, les autres étant stockés. Il peut donc utiliser 3 mots de passe différents, et là tout algorithme basé sur la comparaison des données utilisateur (IP, email, login, mot de passe, etc...) échouera.

C'était juste pour préciser que la seule manière efficace c'est l'accumulation de toutes ces méthodes :
- détection basée sur les données utilisateurs.
- détection basée sur les transactions entre utilisateurs.
- détection humaine, basée sur des schémas générés automatiquement (par exemple, schéma des transactions entre joueurs).
- tri "humain" dans les comptes détectés par les méthodes automatiques.

En clair : si tu veux une méthode qui soit réellement efficace fais un doctorat sur le thème et encore il ne sera appliquable qu'à ton schéma de données.

Ne t'inquiète donc pas trop des "failles" de telle ou telle méthode, il y en aura toujours. Le plus efficace pour limiter les double-comptes n'est pas d'essayer de les détecter ou de les empêcher, mais de réduire leur intérêt :
- inscription payante / abonnement
- intérêt d'avoir deux comptes vraiment minime (limiter les interactions entre joueurs par exemple).

Le plus efficace pour limiter les double-comptes n'est pas d'essayer de les détecter ou de les empêcher, mais de réduire leur intérêt :
- inscription payante / abonnement
- intérêt d'avoir deux comptes vraiment minime (limiter les interactions entre joueurs par exemple).

Merci à tous je vais suivre ces derniers conseils. =D>
Ces jeux me permettent juste de mieux faire connaître le site de la boite (http://www.2amath.fr) à ses clients (et à leurs amis).
Je ne peux pas encore envisager de mettre l'inscription payante mais l'idée est à retenir.
En suivant vos conseils, j'ai du revoir l'algorithme pour minimiser la multiplicité des comptes.
Idées :
+ Le nombre de filleuls par parrain est limité
+ On remet un bonus aux parrains pour chaque nouveau filleul (plus de pourcentage des gains des filleules)
+ Il y aura un super gros lot pour le gagnant et d'autres lots pour ses filleuls ; c'est à ce moment là qu'on vérifiera ceux qui seraient fictifs.

Merci de votre réactivité

Pour la thèse sur le sujet, je crois qu'il y a matière car le contrôle d'un jeu d'utilisateurs uniques fait parti des grandes énigmes d'Internet (même si il existe la notion des certificats qui résout un peu le problème). Il faudrait créer une ID sur net, le participant n'aurait qu'à saisir son code et mot de passe pour être intégralement identifié (en tout cas sur ces données publiques, visibles)... un peu comme microsoft et le compte msn.

Il y en aurait beaucoup à dire... merci encore pour tout !

Un problème sans solution est un problème mal posé.