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...
skeye a écrit :
Les mots de passes pas hashés ne doivent apparaitre nulle part dans ta base, point barre.
|
chani_t a écrit :
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...
|
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.