Hmm beau dialogue de sourds. bon j'ai un peu la flemme de continuer mais juste un truc
Donc en gros ton framework il ne fait .. rien ? il donne la session au dernier connecté et invalide les précédentes. donc B pique la session (sans avoir le mot de passe évidemment sinon comme tu dis ce n'est pas une faille) et A (bobby, le vrai gentil) se retrouve déconnecté, et ensuite ? il retape son mot de passe toutes les 30 secondes. Ce n'est pas suffisant comme protection.
Je trouve que lui afficher toutes ses connexions courantes – ce qui lui permet au passage de voir qu'il est encore connecté au cyber – est mieux. Dans tous les cas, et c'est ce que je disais, si le pirate est connecté il peut le voir aussi. C'est bien que la faille est ailleurs et bloquer les connexions sur les IP est inutile (dans ce cas là).
Fin bon, dans tous les cas, ça n'épargne pas l'expérience utilisateur du gentil. Après, j'admets volontiers que faute de mieux, à l'invite de session l'utilisateur se rend compte qu'il est déco tout le temps et donc qu'un autre profite de son compte.
Ou alors, comme je l'ai lu ici dans un autre topic, l'utilisateur est sur un iPhone et change d'IP à chaque requete. il envoie son mot de passe et se mange un header location vers /loginok/index, paf il change d'IP et se retrouve sur l'invite de mot de passe en boucle ?
Citation :> A se connecte ... il a la session
> B se connecte ... la session de A est invalidé ... B a la session
Donc en gros ton framework il ne fait .. rien ? il donne la session au dernier connecté et invalide les précédentes. donc B pique la session (sans avoir le mot de passe évidemment sinon comme tu dis ce n'est pas une faille) et A (bobby, le vrai gentil) se retrouve déconnecté, et ensuite ? il retape son mot de passe toutes les 30 secondes. Ce n'est pas suffisant comme protection.
Je trouve que lui afficher toutes ses connexions courantes – ce qui lui permet au passage de voir qu'il est encore connecté au cyber – est mieux. Dans tous les cas, et c'est ce que je disais, si le pirate est connecté il peut le voir aussi. C'est bien que la faille est ailleurs et bloquer les connexions sur les IP est inutile (dans ce cas là).
Fin bon, dans tous les cas, ça n'épargne pas l'expérience utilisateur du gentil. Après, j'admets volontiers que faute de mieux, à l'invite de session l'utilisateur se rend compte qu'il est déco tout le temps et donc qu'un autre profite de son compte.
Ou alors, comme je l'ai lu ici dans un autre topic, l'utilisateur est sur un iPhone et change d'IP à chaque requete. il envoie son mot de passe et se mange un header location vers /loginok/index, paf il change d'IP et se retrouve sur l'invite de mot de passe en boucle ?
Citation :Il y en a d'autres mais j'ai un peu la flemme à les exposés.Non vas-y, parce que justement je base mon boulot sur un serveur Comet donc les requetes à la seconde il y en a et ce n'est absolument pas un problème. Le serveur web est prévu pour ça.