Bonjoir,
 
la question ne porte pas spécialement sur PHP, mais bon puisqu'il n'y a pas de section "Conception Web" ou un truc dans le genre  
 
Je dois faire un système de détection de boulets à l'entrée d'un site, et j'ai pensé tout bêtement à ça :
 
l'utilisateur (humain ou programme) donne son login et son mot de passe, je teste leur validité (allure des chaînes) puis leur présence dans le système. A ça je rajoute une page qui teste la capacité de l'utilisateur à lire correctement un message déformé.
Si ça foire pendant une de ces 3 étapes, je rentre les données postées + date et IP dans une table de log et je redirige sur le formulaire d'authentification, le point d'entrée du système.
 
Intérêt :
Je peux regarder combien de fois l'utilisateur a tenté de se logger, en combien de temps et depuis combien d'adresses IP différentes. Je peux également mettre en place une pitite "échelle de risque" pour différencier les utilisateurs inconnus, les connus mais distraits, et les connus parfaitement mais incapables de lire correctement.
Je sais que ces infos isolées ne sont pas forcément très pertinentes, mais couplées elles peuvent quand même donner une idée, savoir si c'est un humain ou un bot, si l'utilisateur retient bien ou mal son mot de passe ( ), si ça bourrine à coup de brute force ou si c'est fait plus discrètement, si ça émet toujours du même endroit, etc...
 
Problème :
Les données peuvent être sensibles, sachant que le mot de passe n'est pas hashé, sinon on peut rien en déduire.
Je ne sais pas si je dois intégrer la table de log à la base existante, ou alors faire une base à part en y incorporant la table des utilisateurs et en rajoutant celle des log dedans, que je tronquerais d'ailleurs toutes les 2-3 semaines par exemple pour pas trop encombrer. Je sais que ça se fait chez les hébergeurs pros de séparer un front d'authentification de l'appli en back dans certains cas, mais je ne connais pas tous les outils qu'ils utilisent pour rendre ce découpage pertinent au niveau de la sécu à part https (j'ai tenté d'en parler à un de nos prestataires pour lui soutirer quelques infos, mais il m'a poliment envoyé chier)
 
Effets "de bord" :
je ne sais pas, je demande...
 
Vala, pour ceux qui ont une expérience et/ou un avis même purement théorique là-dessus, ça m'intéresse vivement

Les mots de passes pas hashés ne doivent apparaitre nulle part dans ta base, point barre.

Idem skeye.. tu hash le mdp que tu stocke dans ta base... aprés ben tu compare les hashs, donc si c'est les même, le mdp est bon sinon ben il ne l'est pas, un point c'est tout... qu'est ce que tu veux faire avec tes mdp en clair ?
 
Quand à la base de log, je pense que tout dépend de la fréquence de fréquentation de ton site... de plus si tu tronque ta table de log, tu pourras difficilement avoir une idée pertinente sur quelques mois de ce qui se passe, tu auras forcément qu'une idée sur une période inférieure à celle de la troncature. (chuis clair.. ?)
 
Aprés pour l'accés au back office, c'est vrai que certain hébergeur passe par du https.. mais la encore tout dépend de la nature de tes infos et de la fréquentation.. Si tu va par la, tu pourrais immaginer une identification par https pour tout le monde, et aprés Id repasser en standard..
(des idées comme ça hein )

Oui c'est ça, en gros ya le front qui fait l'authentification en https, et après on bascule sur le back qui lui est en http classique. Mais il doit bien y avoir d'autres solutions qui justifient ce découpage de la base, et j'ai que peu d'idées là-dessus.
 
Pour la table de logs j'ai dit 2-3 semaines comme ça, effectivement c'est ptet pas assez...
 

Et je ne peux qu'être totalement d'accord avec ce principe
 
Attention, ma table des utilisateurs ne conserve que du hash de mot de passe (biensûr), ya absolument rien de sensible en clair. Je parlais juste de la possibilité de couper cette table de ma base principale et d'aller la coller sur une base de front en https, sans modifier quoi que ce soit à sa structure.

Juste pour préciser que ça se passe pas dans ma table des utilisateurs mais dans ma peut-être future table de logs, ma table à détection de boulets donc, et que tout ça concerne l'étape d'authentification, et rien que ça.
 
Quand je parle de mot de passe stocké en clair, en fait ce ne sont pas les vrais mots de passe, puisque dans cette table de logs ne sont enregistrées que les données qui ne correspondent à personne dans le système. C'est juste une collection de données postées, partiellement ou totalement erronées, ça ne concerne que le login et/ou le mot de passe. Dans cette table jamais un utilisateur qui connaît son login et son mot de passe ne sera enregistré, c'est uniquement les logins et/ou mots de passe foireux que je veux conserver ici, pour les analyser par la suite.
 
Sans conserver ces mots de passe foireux (par rapport au login) en clair, bah je peux pas savoir ce que le gars à l'autre bout à tenté de faire.
Si, par exemple, j'ai enregistré dans ma table de logs 200 connexions foireuses effectuées sur 10 minutes de temps par l'utilisateur "je_suis_connu_du_systeme", et que je peux voir que les mots de passe utilisés sont "aaaaaa", "aaaaab", "aaaaac", etc..., et qu'en plus j'ai toujours la même IP, je peux raisonnablement en conclure que cette IP pue, et que le gars utilise un brute force pour tenter de rentrer dans le système.
Je grossis le trait, mais l'idée c'est d'essayer d'observer et d'enregistrer les comportements des utilisateurs face à ma page d'authentification.
 
 
PS : ça me fait penser qu'au début de mon 1er post j'ai dis une connerie, j'utiliserais cette table de logs que pour 2 étapes, aux moments du test de validité des données postées (la gueule des chaînes) et de celui de leur existence dans la base. Ce sont les seules étapes qui peuvent avoir au moins une donnée postée sensible (login et/ou mdp) incorrecte.
Le 3ème test, celui de lecture d'un message déformé, n'intervient que quand l'utilisateur a déjà été identifié, à ce moment là il faudrait une autre table de logs, uniquement pour ceux qui sont connus du système mais qui savent pas lire, ou qui utilisent un bot, dans laquelle je conserve l'ID de l'utilisateur + date et IP.

Si tu veux pouvoir assurer un suivi d'authentification t'as pas 15 solutions, faut un identifiant unique que tu gardes en session et tu vérifies ques les données permettant d'identifier le client collectées lors de l'authentification changes pas
 
Et si doute tu plombes la session
 
Après à toi de logguer au moins en session les erreurs d'authentifications et d'en déduire une tentative de truandage
 
Après arrivent les problèmes de définir une tentative de truandage: différencier le boulet à 75 de QI, celui pas habitué au web à 90 et celui à 135 qui veut t'enfler...

Tu bloques l'acces au compte a partir de 10 - 15 tentatives de login echouees.
Tu log a partir de 2-9 tentatives foirees et tu connectes ca directement a une table ipfilter ou un htaccess. (humain)
Un ptit script qui croise les donnees du log et quelques controles basta.
Ah oui et configure le firewall pour bannir directement les gars qui arrivent avec un soft multithread