je viens de commiter quelques modifs sur la page de login :
1) le jajascript est activé par défaut, pas besoin de faire "sauter la
page". Si netscape est pas bon ou si jaja n'ewst pas activé, on se logue
en passant le mot de passe en clair comme avant.
2) la logique est maintenant une série de redirect
login -> spip_cookie -> login?essai_cookie=oui -> index.php3
login -> spip_cookie = envoi du mot de passe (codé md5 si possible)
spip_cookie -> login = retour pour verifier que le cookie est posé
Si OUI -> on va dans l'espace privé index.php3
Si NON -> on tente une authentification http comme autrefois.
3) L'auth http revient donc en cas de galère avec les cookies.
Tout ça ne résoud pas la question de la sécurité en cas d'interception du
cookie de session OU d'une copie de la base.
A mon avis les deux sont importants : des copies de la base se trouvent dans
les sauvegardes, qui peuvent se balader un peu plus largement qu'on ne
voudrait. Surtout, si la base est "vue" par un intrus, ce dernier peut
choper des accès quand il veut sur tous les comptes => c'est plus grave
qu'un chourage de cookie qui affecte un seul rédacteur et dure un temps
limité.
spip_cookie -> login = retour pour verifier que le cookie est posé
Si OUI -> on va dans l'espace privé index.php3
Si NON -> on tente une authentification http comme autrefois.
Heu, il vaut mieux un message d'erreur explicite. Surtout, si
l'auth http n'est pas autorisée, ça va sortir un "internal error"
-> pas très compréhensible
Heu, il vaut mieux un message d'erreur explicite. Surtout, si
l'auth http n'est pas autorisée, ça va sortir un "internal error"
-> pas très compréhensible
Ca implique de procéder en deux temps : message d'erreur s'affichant dans
login.php3, expliquant qu'on peut activer ses cookies et avec un lien vers
"ou alors tenter une authentification http"... qui lui-même retourne sur
login.php3?tenter_auth_http=oui
Ca implique de procéder en deux temps : message d'erreur s'affichant dans
login.php3, expliquant qu'on peut activer ses cookies et avec un lien vers
"ou alors tenter une authentification http"... qui lui-même retourne sur
login.php3?tenter_auth_http=oui
Voilà, c'est dans le cvs. Si vous pouvez faire des essais avec des
navigateurs différents, et sur des serveurs différents, ce serait pas mal.
Tout ça ne résoud pas la question de la sécurité en cas d'interception du
cookie de session OU d'une copie de la base.
Je survole rapidement, mais si le cookie est unique lors d'une session, il y
a toujours le risque de se le faire piquer et qu'il serve à rejouer
l'authentification.
Comme il a déjà été dit, il peut être utile d'y placer des informations
relevant de la connexion de l'internaute, comme l'@IP mais ça pose des
problèmes avec les proxies (notamment les batteries de proxy chez certaines
grosses sociétés).
un hash de quelques informations d'entête peut être utile.
Sinon, quelquechose qui est relativement imparable (je crois), c'est de
changer le cookie à chaque connexion au site (enfin, chaque page PHP
récupérée). Le cookie devient alors une sorte de one time password valable
uniquement pour la connexion suivante.
Si une connexion arrive avec un mauvais cookie, on zappe ce qu'on a en
mémoire (pour éjecter un éventuel attaquant qui aurait sniffé un cookie), et
on repropose l'authentification.
A creuser éventuellement... C'est plus lourd au niveau SGBD, évidemment.
Comme il a déjà été dit, il peut être utile d'y placer des informations
relevant de la connexion de l'internaute, comme l'@IP mais ça pose des
problèmes avec les proxies (notamment les batteries de proxy chez certaines
grosses sociétés).
Oui, c'est le coeur du débat.
un hash de quelques informations d'entête peut être utile.
Lesquelles proposerais-tu ?
Sinon, quelquechose qui est relativement imparable (je crois), c'est de
changer le cookie à chaque connexion au site (enfin, chaque page PHP
récupérée). Le cookie devient alors une sorte de one time password valable
uniquement pour la connexion suivante.
C'est ce qu'on fait.
Si une connexion arrive avec un mauvais cookie, on zappe ce qu'on a en
mémoire (pour éjecter un éventuel attaquant qui aurait sniffé un cookie), et
on repropose l'authentification.
Tu zappes quoi? Toutes les sessions de ce login précis?
