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 ...   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 ils vont peut être se lasser.
Je bloque, je ne vois pas ce que je pourrais faire ..

Je vous remercie par avance,

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) ?

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 )

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

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
 
Je vous tiens au courant

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...

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 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

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

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.

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.

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  

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.

 
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
 

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.

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
"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

Violence    
 

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.

bon, 6 mois déjà...

pour commenter ce que font les géants du web en sécurité pour les accès,
c'est à dire la double authentification , le deuxième mail nécessaire, et le numéro de téléphone , + parfois un captcha ( ou un paiement sinon rien ), c'est dur dur,

la sécurité c'est trés compliqué, et ça fait des "echecs" pour des sites aussi , et là, on parle que de l'inscription à un service web, un site commun d'aujourd'hui. tous les sites.

Le lien de validation est trés pertinent ( une colonne "mail_ok" true : false ) ça remplace la table de "temporary user"

Les cookies , pour un domaine, un serveur , avec les navigateurs actuels,
il est possible d'en accumuler , c'est à dire d'implèmenter des cookies pour plusieurs utilisateurs.
Ce n'est plus unique du tout.

Clairement, quelqu'un veut te faire chi*r , et les mails aléatoires et provisoires ça existes ..., les scripts pour remplir une case vide, ou un duo d'inscription mail + mdp aussi ...
C'est là qu'un captcha ( dynamique / alèatoire ) s'aménes bien, indispensable aujourd'hui.

Pour la petite histoire :
les captcha, les liens pour validation dans la boite mail d'un nouvel utilisateur : c'est anti-bots / anti-scripts / anti automates.
Ce sont des 'human tests'  , seul un humain va se dépétrer de ces vérifications. ( oui, oui , des algos font ça ...  0.5% )

_______
Essayes de voir autour de toi quel olibrius veut t'agacer et boussiller tes journées de travail ....
il( elle ? ) connait l'informatique et sait qui tu es, les outils de hack , le dark web ..
et s'en vantes ... t'a vu le résultat ???
_____________________________

Bosses bien ta séquence de connexion et d'inscription ,
c'est le point de départ pour tout tes futurs utilisateurs.

Pour bien finir , il faut trés bien commencer   ( mais par code informatique ).