Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Shop Recherche
1802 connectés 

  FORUM HardWare.fr
  Programmation
  PHP

  Bannir efficacement une personne

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Bannir efficacement une personne

n°2369481
Euuuhhh
Posté le 26-11-2020 à 18:43:06  profilanswer
 

Bonjour,

 

Sur 2 de mes sites j'ai actuellement un ou plusieurs idiots qui s'amusent à créer des comptes. Les logins sont de types "xzzyzeorkq" donc random...
Les adresses emails sont bien réelles et je pense qu'elles sont issues de bases piratées qui proviennent certainement du darkweb.
Ce qui étrange, c'est que je ne vois strictement aucun intérêt à cette ou ces personnes de faire ca.
En effet à chaque inscription j'envoie un email de confirmation d'inscription, mais j'ai vérifié, celui-ci n'est pas détourné. Les comptes ne sont pas activés. Du coup, je ne vois pas l'intérêt de faire ca ...  :heink: sauf peut être me faire blacklister mon serveur mail?

 

Actuellement voici les vérifications/blocages que j'ai en place :
-Enregistrement de l'adresse IP pour empêcher une inscription sous 7 jours
-Un cookie enregistré pour empêcher une inscription sous 7 jours
-Captcha

 

J'ai mis plusieurs logs et ce qui est étonnant :
-à chaque inscription c'est un système d'exploitation/navigateur différent (en tout ca c'est assez rare que je retrouve 2 ou 3 inscriptions avec le même OS et navigateur)
-IP différente venant de dizaines de pays différents (moins étonnant)

 

Ca dure depuis 2 semaines et actuellement je ne vois que deux solutions :
-Continuer à supprimer chaque jour les comptes (ca me prend 2 minutes). Si je dois compter, 100/120 comptes par jour créés au total sur les 2 sites.
-Fermer les inscriptions pour peut être stopper ca ?

 

Je ne souhaite pas envisager la seconde solution. Je vais stopper temporairement, mais les mecs reviendront sûrement à la réouverture des inscriptions... Même si parfois ensuite ils passent à autre chose.

 

Auriez-vous des idées sur d'autres méthodes à mettre en place pour tenter d'empêcher ca ? ou au moins ralentir. Si le mec prend 2 minutes à chaque fois à vider ses cookies, le captcha, etc. si je peux faire que ca augmente à 10 minutes :o ils vont peut être se lasser.
Je bloque, je ne vois pas ce que je pourrais faire ..

 

Je vous remercie par avance,


Message édité par Euuuhhh le 26-11-2020 à 18:56:05
mood
Publicité
Posté le 26-11-2020 à 18:43:06  profilanswer
 

n°2369483
TotalRecal​l
Posté le 26-11-2020 à 19:11:36  profilanswer
 

Pour les inscriptions "non validées" plutôt que les supprimer à la main tu ne peux pas faire un script qui vire toutes les inscriptions non validées de plus de 48h (par exemple) ? Ca ne résout pas le pb de fond mais ça fait gagner du temps.
 
Pour la protection, il y a un token invisible dans le formulaire qui sert de protection anti CSRF ?
 
Tu as mis un CAPTCHA (pas forcément un machin abominable "identifiez toutes les photos de péniche", juste une question facile pour un humain mais compliquée pour un bot genre faire une addition, etc) ?


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2369485
Euuuhhh
Posté le 26-11-2020 à 20:25:03  profilanswer
 

Merci pour ta réponse,

 

Pour les inscriptions non validées j'ai un script de nettoyage mais qui se lance tous les 6 mois pour les comptes inactifs, mais je préfère éviter de nettoyer automatiquement, car cela risquerait de pénaliser les "vrais" membres qui ne recoivent pas le mail (ou qui se retrouvent en spam) et demande une activation du compte :/
Après dans ma partie admin j'avais déjà une interface pour supprimer des comptes avec la possibilité de le faire "en masse", donc en fait supprimer les comptes me prend vraiment 2 minutes pour les 2 sites, c'est vraiment rapide.

 

Pour moi surtout, c'est d'essayer de stopper ca car j'ai peur que cela puisse avoir un impacte sur mon serveur mail...

 

Je n'ai pas mis de protection anti CSRF, je vais le faire, mais je ne pense pas que cela change quelque chose :(

 

Oui j'ai un captcha comme expliqué dans mon premier message, c'est simplement une suite de lettre et chiffres à recopier (mais pas le truc dégueulasse illisible :D )

 

C'est pour ca que je pense réellement que ce sont des comptes créés manuellement... d'ailleurs le nombre de compte parle de lui même, une centaine de comptes par jour c'est vraiment "faible"...

 

Je vais tenter l'anti CSRF, mais je sèche totalement sur d'autres techniques à mettre en place :/

 

EDIT : bon je viens d'installer l'anti CSRF et j'enregistre le token en base pour voir ce que ca donne... on verra demain mais j'ai pas grand espoir que cela change grand chose :(


Message édité par Euuuhhh le 26-11-2020 à 21:12:24
n°2369495
B4X
kebab-case
Posté le 26-11-2020 à 23:50:02  profilanswer
 

Le token CSRF ne sert pas à cela. Un token CSRF vise à protéger ton visiteur, càd qu'un acteur malveillant ne sera plus capable de lui faire jouer des requêtes à son insu. Ceci ne résoudra pas TON problème.
Il te faut un meilleur CAPTCHA, de type reCaptcha ou hCaptcha. Ton CAPTCHA est certainement naze. On est en 2020, tes caractères alphanumériques en image, un bot peut les lire en moins d'1s avec un logiciel d'OCR. Une addition n'a rien de "compliquée pour un bot".
100 inscriptions bidons par jour c'est beaucoup. Le risque ici c'est clairement de flinguer la délivrabilité/réputation de tes mails.


---------------
In vanitas veritas.
n°2369501
Euuuhhh
Posté le 27-11-2020 à 08:55:51  profilanswer
 

Je n'étais pas convaincu non plus par le token CSRF car ce n'est pas son utilisation initiale, mais ce token a l'avantage de créer une session, ce qui peut déjà limiter au niveau du robot.
 
D'ailleurs ca semble payer. Sur le site où je l'ai installé, plus aucun compte créé, alors qu'une trentaine de compte a été créé sur l'autre site sur le même laps de temps.
 
Le captcha est peut être pourri en effet. Faut que je vois à le changer :jap:
 
Je vous tiens au courant :)

n°2369507
TotalRecal​l
Posté le 27-11-2020 à 09:40:13  profilanswer
 

B4X a écrit :

Le token CSRF ne sert pas à cela. Un token CSRF vise à protéger ton visiteur, càd qu'un acteur malveillant ne sera plus capable de lui faire jouer des requêtes à son insu. Ceci ne résoudra pas TON problème.
Il te faut un meilleur CAPTCHA, de type reCaptcha ou hCaptcha. Ton CAPTCHA est certainement naze. On est en 2020, tes caractères alphanumériques en image, un bot peut les lire en moins d'1s avec un logiciel d'OCR. Une addition n'a rien de "compliquée pour un bot".
100 inscriptions bidons par jour c'est beaucoup. Le risque ici c'est clairement de flinguer la délivrabilité/réputation de tes mails.


Ca dépend du bot et de si l'attaquant veut se donner la peine de continuer son petit jeu : si le CAPTCHA est chiant à lire ou comprendre le bot sera plus compliqué à coder. Pareil avec un captcha vocal, faut le gérer (à voir si c'est envisageable).
Idem pour le CSRF : même si le but premier est la protection des utilisateurs, pour qu'un bot contourne cette protection il faut qu'il traverse tout le processus d'inscription et génère le token correspondant comme le ferait un utilisateur normal, donc il ne peut pas se contenter de faire le "POST" final. Et avoir un token en session et un en hidden offre des protections un peu complémentaires. Mais effectivement n'importe quel bot bien codé et adapté pour ton cas sera en mesure de contourner ça.

 

Là on ne sait pas trop à qui on a affaire ni pourquoi, ni son niveau de motivation pour contourner les protections en place.

 

Et effectivement les envois de mails en masse (surtout vers des vraies adresses de personnes qui n'ont rien demandé puisque tu disais que c'est le cas ?) c'est pas top niveau réputation...


Message édité par TotalRecall le 27-11-2020 à 09:44:58

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2369572
Euuuhhh
Posté le 27-11-2020 à 17:15:22  profilanswer
 

Tout à fait, c'est d'ailleurs pour ca que je l'ai mis en place, même si son utilisation principale n'est pas de bloquer ca, ca peut bloquer un robot. Au moins temporairement (ou faire chier un peu plus quelqu'un qui fait ces créations manuellement).

 

D'expérience, peu importe leur raison, qui sont souvent les mêmes (faire chier, spammer, etc.), du moment qu'on leur créer du boulot, ils abandonnent et trouvent une autre cible plus facile...

 

Il est impossible d'empêcher quelqu'un de vouloir faire chier de toute facon, mais au moins, lui faire perdre un max de temps pour qu'il trouve une autre cible.

 

J'ai également changé le captcha pour la solution google. Le combo de ces deux solutions semblent faire que ca se calme. J'ai eu encore quelques comptes dans l'après-midi (ce qui me fait dire que la création des comptes est manuelle, ce qui ne fait d'ailleurs plus aucun doute !), et je pense que maintenant qu'ils voient qu'il y a quelqu'un derrière, ils vont aller voir ailleurs.

 

Sinon oui, les adresses semblent réelles (d'ailleurs un compte a été activé), et de ce que je vois, ca semble des bases piratées...et à mon avis pas toute jeunes (vu certains domaines de fournisseurs)..

 

Mes sites eux-mêmes ne sont pas tout jeune :D ils ont plus de 15 ans, donc je suis souvent cible de ce type d'attaques. Les hackeurs doivent s'attendre à des sites qui ne sont plus entretenus...

 

Bon en tout cas pour l'instant ca semble se calmer... J'espère en tout cas, si je peux éviter de devoir checker ca tous les jours!

 

Merci à vous en tout cas :jap:


Message édité par Euuuhhh le 27-11-2020 à 18:32:37
n°2369584
rufo
Pas me confondre avec Lycos!
Posté le 27-11-2020 à 19:05:55  profilanswer
 

Peut-être essayer une méthode fingerprint en détectant les extensions du navigateur si tes attaquants font ça manuellement. C'est sûr que si ce sont des bots, ça sert à rien.
J'avais lu une étude qui expliquait que les certaines grosses plates-formes, pour identifier de manière unique un utilisateur sans cookie ou autre ID, utilisant les extensions installées car cet ensemble était en général unique à chaque utilisateur...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2369621
Euuuhhh
Posté le 28-11-2020 à 09:30:37  profilanswer
 

rufo a écrit :

Peut-être essayer une méthode fingerprint en détectant les extensions du navigateur si tes attaquants font ça manuellement. C'est sûr que si ce sont des bots, ça sert à rien.
J'avais lu une étude qui expliquait que les certaines grosses plates-formes, pour identifier de manière unique un utilisateur sans cookie ou autre ID, utilisant les extensions installées car cet ensemble était en général unique à chaque utilisateur...


J'y avais pensé et j'ai essayé comme expliqué dans mon premier message, malheureusement à chaque fois une config différente :( j'avais retrouvé que 2/3 fois une config identique, seulement :/


Message édité par Euuuhhh le 28-11-2020 à 09:30:47
n°2369627
rufo
Pas me confondre avec Lycos!
Posté le 28-11-2020 à 09:54:37  profilanswer
 

Quand t'as parlé de conf, je pensais que tu t'étais plutôt basé sur des trucs classiques comme l'OS, le user-agent, la résolution de l'écran (bref, des trucs facilement falsifiables)... Du reste, c'est ce que tu mets, tu ne parles pas que tu récupérais les plugins ou extensions de navigateur installées.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
mood
Publicité
Posté le 28-11-2020 à 09:54:37  profilanswer
 

n°2371392
potemkin
Optimisateur relativiste.
Posté le 13-12-2020 à 15:06:16  profilanswer
 

C'est certainement des ouvertures de compte automatisées (très simple de randomiser les user agent pour simuler des configs différentes à chaque essai), bref ce type de détection n'est pas assez fiable pour y mettre une logique de sécurité derrière, tout au plus adapter le comportement de ton site pour les vrais utilisateurs.
 
Ton captcha n'est peut-être pas assez complexe, ou daté.
 
Par contre il y a un gros problème : je crois comprendre que tu crées les comptes indépendamment de l'activation par l'email reçu. Mauvaise pratique. La création effective ne doit intervenir QUE lorsque le lien d'activation est validé.
L'insertion du compte en BDD doit donc être déclenchée par le lien du mail. Et là encore, tu devrais avoir une autre page intermédiaire derrière.
 
Exemple 1 : les informations de ton utilisateur sont injectées dans ton URL (un GET avec les paramètres en query type https://xxx/signup/validation?name= [...] hin.com... , voir un unique param userinfo={prop1:x,prop2:y} où tu auras JSON encodé en une seule chaîne l'ensemble des params), qui redirige vers une page publique qui reconstruit le formulaire et contient un bouton de validation (qui envoie le POST de création).
 
Exemple 2 sans page intermédiaire : à la création du compte, tu stockes les infos dans une table temporaire (contenant toutes les infos du formulaire + un token unique (ça peut être un bête timestamp salé avec l'email utilisateur). Chaque entrée a un TTL de N heures (effacement automatique, cela conditionnera la validité du lien). Le lien envoyé par email contient le token (identifiant te permettant de faire le lien avec les infos user), et l'appel de cette URL déclenche la création du compte si le token est encore valide (= la ligne n'a pas été dégagée à cause de son TTL expiré).
Le risque avec cette méthode, est que si l'email existe vraiment, certains providers mail risquent de l'activer malgré tout : pour raisons de sécurité, les emails sont scannés, et les liens (GET) s'y trouvant sont parfois appelés automatiquement.

Message cité 1 fois
Message édité par potemkin le 13-12-2020 à 15:24:00
n°2371435
B4X
kebab-case
Posté le 13-12-2020 à 19:49:59  profilanswer
 

Ce ton impérieux pour raconter que du caca :love:  
L'exemple 1 complètement débile et useless :love:  
L'exemple 2 encore plus avec la table temporaire :love:  
 
On dirait un mishmash de best practices mal comprises et implémentées n'importe comment :love:


---------------
In vanitas veritas.
n°2371439
potemkin
Optimisateur relativiste.
Posté le 13-12-2020 à 20:02:51  profilanswer
 

Merci pour ton intervention, maintenant je suis impatient de lire comment tu implémentes cette mécanique, avec une j'imagine une approche tellement en avance sur ce qui se fait partout :love:  

n°2371440
rufo
Pas me confondre avec Lycos!
Posté le 13-12-2020 à 20:13:36  profilanswer
 

Franchement, les infos du compte passés en GET, oui, c'est pas une bonne pratique surtout avec le coup de la reconstruction d'un formulaire derrière, clairement :/
C'est un coup à ce que des bots te pourrissent la BD.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2371444
Euuuhhh
Posté le 13-12-2020 à 20:31:42  profilanswer
 

potemkin a écrit :

C'est certainement des ouvertures de compte automatisées (très simple de randomiser les user agent pour simuler des configs différentes à chaque essai), bref ce type de détection n'est pas assez fiable pour y mettre une logique de sécurité derrière, tout au plus adapter le comportement de ton site pour les vrais utilisateurs.
 
Ton captcha n'est peut-être pas assez complexe, ou daté.
 
Par contre il y a un gros problème : je crois comprendre que tu crées les comptes indépendamment de l'activation par l'email reçu. Mauvaise pratique. La création effective ne doit intervenir QUE lorsque le lien d'activation est validé.
L'insertion du compte en BDD doit donc être déclenchée par le lien du mail. Et là encore, tu devrais avoir une autre page intermédiaire derrière.
 
Exemple 1 : les informations de ton utilisateur sont injectées dans ton URL (un GET avec les paramètres en query type https://xxx/signup/validation?name= [...] hin.com... , voir un unique param userinfo={prop1:x,prop2:y} où tu auras JSON encodé en une seule chaîne l'ensemble des params), qui redirige vers une page publique qui reconstruit le formulaire et contient un bouton de validation (qui envoie le POST de création).
 
Exemple 2 sans page intermédiaire : à la création du compte, tu stockes les infos dans une table temporaire (contenant toutes les infos du formulaire + un token unique (ça peut être un bête timestamp salé avec l'email utilisateur). Chaque entrée a un TTL de N heures (effacement automatique, cela conditionnera la validité du lien). Le lien envoyé par email contient le token (identifiant te permettant de faire le lien avec les infos user), et l'appel de cette URL déclenche la création du compte si le token est encore valide (= la ligne n'a pas été dégagée à cause de son TTL expiré).
Le risque avec cette méthode, est que si l'email existe vraiment, certains providers mail risquent de l'activer malgré tout : pour raisons de sécurité, les emails sont scannés, et les liens (GET) s'y trouvant sont parfois appelés automatiquement.


 
Ce n'était pas une création automatique puisque même avec le captcha google des comptes ont été créés.
Quant à la création immédiate du compte, c'est peut être une mauvaise pratique en terme d'optimisation de la base de données, mais c'est comme ca que je procède et ca ne gêne en rien, même avec plus de 500k inscrits sur mes sites, ils sont hébergés sur un petit kimsufi et ils tournent très bien. Je ne compte pas les forums (fabriqué maison) qui tournent très bien avec des dizaines de millions de messages et des dizaines de milliers d'utilisateurs.
Les comptes sont quoi qu'il arrive supprimés automatiquement au bout de 6 mois d'inactivité.
 
Lors de l'inscription, le membre reçoit un email pour activer son compte avec un hash unique. C'est largement suffisant.
Certes le compte est créé même sans activation du compte, mais à part pour de l’optimisation de BD (dont honnêtement je m'en fiche un peu pour les raisons citées plus haut), ca n'impacte en rien la sécurité des sites.
 
Les formulaires ne peuvent pas être saisies via un get. Je ne le permet pas.
 
Les sites ont certes presque 20 ans, mais je n'ai pas développé ca comme un goret quand même :o
 

n°2371722
TotalRecal​l
Posté le 16-12-2020 à 11:31:32  profilanswer
 

B4X a écrit :

Ce ton impérieux pour raconter que du caca :love:
L'exemple 1 complètement débile et useless :love:
L'exemple 2 encore plus avec la table temporaire :love:

 

On dirait un mishmash de best practices mal comprises et implémentées n'importe comment :love:

 

Euh, l'exemple 1 avec tout en GET et rien dans la base je trouve ça infâme, pour des tas de raison (url dégueulasse, très limité en volume de donnée manipulable, maintenance horrible, risque de foirer les caractères spéciaux, porte ouverte aux injections et aux bidouilles même par un utilisateur legit, etc).

 

L'exemple 2 avec le fait de créer les nouveaux utilisateurs dans une table distincte jusqu'à la finalisation, à la limite pourquoi pas si on veut bien isoler les choses.
Idéalement derrière le lien d'activation on peut ajouter un bouton de confirmation ou bien une vérification du navigateur qui appelle (pour exclure les bots).

 

Mais dans tous les cas vu que tu n'apportes pas le moindre argument concret pour défendre ta position et vu l'agressivité dont tu fais preuve de façon purement gratuite envers quelqu'un que tu ne connais probablement même pas, je pense qu'on va laisser la modération juger de la forme de ton post, à défaut d'avoir un fond très intéressant.


Message édité par TotalRecall le 16-12-2020 à 11:34:15

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2371725
Modération
Posté le 16-12-2020 à 11:52:53  answer
 

B4X a écrit :

Ce ton impérieux pour raconter que du caca :love:  
L'exemple 1 complètement débile et useless :love:  
L'exemple 2 encore plus avec la table temporaire :love:  
 
On dirait un mishmash de best practices mal comprises et implémentées n'importe comment :love:


Ou bien tu justifies ces remarques acerbes avec une explication qui fera autorité, ou bien c'est un petit TT de 15 jours. Tu as jusqu'à la fin de la journée.

n°2371735
potemkin
Optimisateur relativiste.
Posté le 16-12-2020 à 12:57:07  profilanswer
 

Euuuhhh a écrit :

 

Ce n'était pas une création automatique puisque même avec le captcha google des comptes ont été créés.
Quant à la création immédiate du compte, c'est peut être une mauvaise pratique en terme d'optimisation de la base de données, mais c'est comme ca que je procède et ca ne gêne en rien, même avec plus de 500k inscrits sur mes sites, ils sont hébergés sur un petit kimsufi et ils tournent très bien. Je ne compte pas les forums (fabriqué maison) qui tournent très bien avec des dizaines de millions de messages et des dizaines de milliers d'utilisateurs.
Les comptes sont quoi qu'il arrive supprimés automatiquement au bout de 6 mois d'inactivité.

 

Lors de l'inscription, le membre reçoit un email pour activer son compte avec un hash unique. C'est largement suffisant.
Certes le compte est créé même sans activation du compte, mais à part pour de l’optimisation de BD (dont honnêtement je m'en fiche un peu pour les raisons citées plus haut), ca n'impacte en rien la sécurité des sites.

 

Les formulaires ne peuvent pas être saisies via un get. Je ne le permet pas.

 

Les sites ont certes presque 20 ans, mais je n'ai pas développé ca comme un goret quand même :o

 


 

L'exemple 1 est foireux je te l'accorde, je l'ai ajouté après l'ex 2 en voulant rajouter une version simplifiée. Enfin, foireux dans le sens où il ne peut exister seul et nécessite une info intermédiaire entre la demande de création de compte et l'activation. Et puisque ça implique de conserver de la donnée, on revient sur la table intermédiaire (quasi-équivalent déporté de ce que tu fais déjà sur la table principale). Et donc en effet le lien de l'email ne contiendrait qu'un token/hash/id/whatever. Et je le redis car rencontré en Prod dans ma boite : les liens présents dans les emails peuvent être parsés par des bots, d'où le besoin (dans ma proposition) d'une page tampon avec un bouton de validation. Table qui + est auto-gérée (via les TTL).

 

Je trouve dommage la posture "ça marche comme ça depuis X mois/années/siècles donc aucune raison de changer". Il  y a 1001 façons d'obtenir un même résultat, tous ne sont évidemment pas égaux.

 

"même avec le captcha google des comptes ont été créés" c'est pour ça que je questionnais la techno de captcha utilisée. Si trop datée, il est très probable que des bots sachant la bypass, rendant la sécurité inutile.

 

Avoir une BDD "saine" est de bon goût, si ce n'est pas pour la place (négligeable) que prennent les données, au moins pour l'exploitation que tu peux en faire. Tu parles de 500k inscrits, mais combien d'utilisateurs humains ? 499k? 200k? 1k? Impossible à savoir, sauf à croiser avec une donnée arbitraire comme l'activité (et encore, c'est toujours biaisé). Ta mécanique de nettoyage après X temps d'inactivité est une chose, mais qui répond à un autre besoin, ou est justement une conséquence d'une BDD ayant l'insertion facile :D
"ca n'impacte en rien la sécurité des sites" peut-être bien, mais ça t'amène des problématiques. Tu pourrais ignorer le problème et ne rien chercher à nettoyer d'ailleurs.

 

A la question "comment bannir efficacement un user" je répondais simplement par une autre question : "qu'est-ce qui t'a amené dans cette situation ?". Pour moi clairement la trop grande souplesse de création de compte.
Le captcha pourrait-être amélioré et résorber le problème aujourd'hui, ça n'empêcherait pas qu'à l'avenir, les bots apprennent à les passer à nouveau. Une bonne sécurité… de niveau 1.

 

Bref, tu as eu une proposition qui répond à ton problème, libre à toi d'en chercher une autre, ou ne rien changer :jap:

 

Message cité 1 fois
Message édité par potemkin le 16-12-2020 à 13:02:28
n°2371736
potemkin
Optimisateur relativiste.
Posté le 16-12-2020 à 12:57:49  profilanswer
 

Modération a écrit :


Ou bien tu justifies ces remarques acerbes avec une explication qui fera autorité, ou bien c'est un petit TT de 15 jours. Tu as jusqu'à la fin de la journée.


Violence  :love:  
 

Spoiler :

Je n'ai pas alerté pour info :o

n°2371737
B4X
kebab-case
Posté le 16-12-2020 à 13:01:34  profilanswer
 

Il va d'abord nous préciser très en détail pourquoi "La création effective ne doit intervenir QUE lorsque le lien d'activation est validé", ainsi que cette "table temporaire". Et ceci immédiatement. [:cetrio:4]  
Je sollicite une "explication qui fera autorité" pour ces 2 points, et je la veux sans délais. [:cetrio:4]  
Je viendrais ensuite apprécier ses explications "avant la fin de la journée", et si j'estime ses efforts satisfaisants alors je produirais une réponse + académique [:cetrio:4]  
 
[:itm]


---------------
In vanitas veritas.
n°2371740
Modération
Posté le 16-12-2020 à 14:05:22  answer
 

B4X a écrit :

Il va d'abord nous préciser très en détail pourquoi "La création effective ne doit intervenir QUE lorsque le lien d'activation est validé", ainsi que cette "table temporaire". Et ceci immédiatement. [:cetrio:4]  
Je sollicite une "explication qui fera autorité" pour ces 2 points, et je la veux sans délais. [:cetrio:4]  
Je viendrais ensuite apprécier ses explications "avant la fin de la journée", et si j'estime ses efforts satisfaisants alors je produirais une réponse + académique [:cetrio:4]  
 
[:itm]


Ne retourne pas la situation. C'est toi qui contredit Potemkin de façon assez cavalière. Donc étant son contradicteur, c'est à toi d'appuyer tes dires. Lui il a donné une solution, toi elle ne te convient pas. A toi d'apporter un argumentaire à ta tartine de caca. C'est comme ça que fonctionne un débat contradictoire.

n°2371820
Euuuhhh
Posté le 17-12-2020 à 13:40:37  profilanswer
 

potemkin a écrit :

 

L'exemple 1 est foireux je te l'accorde, je l'ai ajouté après l'ex 2 en voulant rajouter une version simplifiée. Enfin, foireux dans le sens où il ne peut exister seul et nécessite une info intermédiaire entre la demande de création de compte et l'activation. Et puisque ça implique de conserver de la donnée, on revient sur la table intermédiaire (quasi-équivalent déporté de ce que tu fais déjà sur la table principale). Et donc en effet le lien de l'email ne contiendrait qu'un token/hash/id/whatever. Et je le redis car rencontré en Prod dans ma boite : les liens présents dans les emails peuvent être parsés par des bots, d'où le besoin (dans ma proposition) d'une page tampon avec un bouton de validation. Table qui + est auto-gérée (via les TTL).

 

Je trouve dommage la posture "ça marche comme ça depuis X mois/années/siècles donc aucune raison de changer". Il  y a 1001 façons d'obtenir un même résultat, tous ne sont évidemment pas égaux.

 

"même avec le captcha google des comptes ont été créés" c'est pour ça que je questionnais la techno de captcha utilisée. Si trop datée, il est très probable que des bots sachant la bypass, rendant la sécurité inutile.

 

Avoir une BDD "saine" est de bon goût, si ce n'est pas pour la place (négligeable) que prennent les données, au moins pour l'exploitation que tu peux en faire. Tu parles de 500k inscrits, mais combien d'utilisateurs humains ? 499k? 200k? 1k? Impossible à savoir, sauf à croiser avec une donnée arbitraire comme l'activité (et encore, c'est toujours biaisé). Ta mécanique de nettoyage après X temps d'inactivité est une chose, mais qui répond à un autre besoin, ou est justement une conséquence d'une BDD ayant l'insertion facile :D
"ca n'impacte en rien la sécurité des sites" peut-être bien, mais ça t'amène des problématiques. Tu pourrais ignorer le problème et ne rien chercher à nettoyer d'ailleurs.

 

A la question "comment bannir efficacement un user" je répondais simplement par une autre question : "qu'est-ce qui t'a amené dans cette situation ?". Pour moi clairement la trop grande souplesse de création de compte.
Le captcha pourrait-être amélioré et résorber le problème aujourd'hui, ça n'empêcherait pas qu'à l'avenir, les bots apprennent à les passer à nouveau. Une bonne sécurité… de niveau 1.

 

Bref, tu as eu une proposition qui répond à ton problème, libre à toi d'en chercher une autre, ou ne rien changer :jap:

 



Ma posture n'est pas "ça marche comme ça depuis X mois/années/siècles donc aucune raison de changer" mais "Ca fonctionne très bien comme ca et c'est largement optimisé et viable pour ne pas changer".

 

Ta manière de faire je n'en veux pas pour la simple et bonne raison qu'elle ne m'apportera rien sauf gagner 0.0000001s d’exécution de page et me faire perdre des dizaines d'heures de travail avec des bugs potentiels. Mes sites Internet sont stables, ce n'est pas mon activité principale, alors je n'ai pas besoin de faire plus ni de me créer des potentiels bugs pour que dal. Je me passe des explications sur pourquoi je ne souhaite pas faire cela pour la structure de mes sites Internet, les calculs, etc. car le sujet de ce topic n'est pas l'optimisation de mes sites internet ni comment ils sont construits.

 

Au niveau sécurité, je pense que tout a été dit. La création de compte était manuelle, j'ai changé le captcha pour un plus performant, le mec à compris qu'il y avait quelqu'un derrière et il a arrêté.
Les comptes fictifs ou flood ca ne reste jamais en base, tout simplement parceque derrière une trentaine de personnes sont présentes pour faire ce type de vérification chaque jour. Et, les comptes inactifs sont supprimés au bout de 6 mois.
Ta proposition, au niveau sécurité ne m’intéresse pas car elle n'apporte rien de plus que ce que je fais déjà ;)
Des membres dans ce sujet ont apportées des propositions, des idées, que j'ai suivi, le problème est aujourd'hui clos.


Message édité par Euuuhhh le 17-12-2020 à 13:43:02
mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  PHP

  Bannir efficacement une personne

 

Sujets relatifs
Développer efficacement sur 2 PCCherche personne pour décrypter fichier
[VBA Excel] Tirage de personne en aleatoire selon 2 conditionsPersonne motivé sur projet
Recherche personne pour rejoindre un projetCakePhp faire un sommaire filtre pour personne
[Aide]Cherche une personne pour configuration JoomlaRecherche Personne doué en XML
Cherche personne expérimentée en VBS pour un petit coup de main !Besoin d'une personne pour me créer une page accès membre.
Plus de sujets relatifs à : Bannir efficacement une personne


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR