On pourrait remplacer MD5 par un SHA-256
Pour info SHA-1 est utilisé par SSL pour encoder les données. NIST recommande de ne plus l’utiliser à partir de 2010.
(sur leur page dédiée à la crypto : http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html)
côté PHP, on a $sha256b= base64_encode(bin2hex(mhash(MHASH_SHA256,$phrase)));
bien sûr, mais la librairie mhash() n’est pas toujours installée.
Si ce n’est pas le cas, on peut toujours utiliser cette implémentation : http://www.nanolink.ca/pub/sha256/
C’est illusoire. A partir du moment où la transaction http elle même n’est pas sécurisée, il y a des failles, à commencer par le cookie posé par SPIP et qui circule en clair une fois que le visiteur est reconnu. Il ‹ suffit › de le voler pour accèder à la session du visiteur.
C’est illusoire. A partir du moment où la transaction http elle même n’est pas sécurisée, il y a des failles, à commencer par le cookie posé par SPIP et qui circule en clair une fois que le visiteur est reconnu. Il ‹ suffit › de le voler pour accèder à la session du visiteur.
On peut s’authentifier de cette façon ?
Actuellement je vois 3 infos : spip_accepte_ajax, spip_admin, spip_session
On a aucune info de login, à moins que spip_session soit réexploitable : si c’est le cas, pourquoi ne pas stocker complètement la session côté serveur (soit en MySQL soit avec la session PHP) ?
On peut s'authentifier de cette façon ?
Actuellement je vois 3 infos : spip_accepte_ajax, spip_admin, spip_session
On a aucune info de login, à moins que spip_session soit réexploitable : si
c'est le cas, pourquoi ne pas stocker complètement la session côté serveur
(soit en MySQL soit avec la session PHP) ?
On peut s’authentifier de cette façon ?
Actuellement je vois 3 infos : spip_accepte_ajax, spip_admin, spip_session
On a aucune info de login, à moins que spip_session soit réexploitable : si
c’est le cas, pourquoi ne pas stocker complètement la session côté serveur
(soit en MySQL soit avec la session PHP) ?
Tu geres le « connecter plusieurs jours » comment ?
Arf, quelque chose que je n’utilise jamais
Sans cookie en effet c’est impossible.
Reste le problème du vol de cookie : n’y a-t-il pas un moyen pour empecher ça ?
Si c’est vrai qu’on peut piquer la session d’un autre utilisateur avec un cookie qu’on aura récupéré, je ne vois pas pourquoi on se fatigue avec un formulaire avec MD5 etc…
A la limite, l’utilisation de ce cookie devrait être optionnelle, et ne le prendre en compte que si l’utilisateur coche l’option « resté connecté plusieurs jours ».
En l'occurrence ça n'a rien à voir : le cookie sert à dire quelle
session on gère. Pas de cookie, pas de session. Vol de cookie, vol de
session. Mais il faut aussi voler l'IP et la configuration du
navigateur.
Si c'est vrai qu'on peut piquer la session d'un autre utilisateur avec un
cookie qu'on aura récupéré, je ne vois pas pourquoi on se fatigue avec un
formulaire avec MD5 etc..
Voler une session c'est immédiat, et pas exploitable au-delà de la
durée de la session. Dans l'espace privé quand deux clients ont la
même session, on en tue une : à priori ça conduit au fait que celui
qui s'est fait pirater se fait déconnecter, et donc s'en rend compte.
Si tu voles une session tu ne disposes pas d'infos qui te permettent
de te reconnecter plus tard -- ni sur un autre site où le même
utilisateur disposerait du même mot de passe.
Si tu voles une session tu ne disposes pas d'infos qui te permettent
de te reconnecter plus tard
Il « suffit » de modifier le mot de passe, non ?
Oui, mais dans ce cas la victime se rend compte qu'elle s'est fait
pirater. C'est le mieux qu'on sache faire en cas de vol de cookie :
que ça ne passe pas inaperçu. Si vous avez une méthode qui permet
vraiment de faire mieux que ça, donnez-la.
Pour le changement de mot de passe on pourrait redemander l'ancien.
Pour les actions sensibles (genres reset base ...) idem. Le rappel de l'authent etant un des moyen de limiter l'impact du vol de session.
Si tu voles une session tu ne disposes pas d'infos qui te permettent
de te reconnecter plus tard
Il « suffit » de modifier le mot de passe, non ?
Oui, mais dans ce cas la victime se rend compte qu'elle s'est fait
pirater. C'est le mieux qu'on sache faire en cas de vol de cookie :
que ça ne passe pas inaperçu. Si vous avez une méthode qui permet
vraiment de faire mieux que ça, donnez-la.
Pour le changement de mot de passe on pourrait redemander l'ancien.
+1
Pour les actions sensibles (genres reset base ...) idem. Le rappel de l'authent etant un des moyen de limiter l'impact du vol de session.
