[spip-dev] Sécurité du formulaire de login (Re: V.2.0.5 : passer en https)

Bonjour la liste,

c’est tout simplement ridicule mais si tu maintiens que tu veux une belle porte blindée avec un paillasson devant pour pouvoir y cacher la clé…
maintenant, ne soit pas non plus surpris qu’on te dise que ce que tu veux faire l’est

Je m’étonne qu’on critique le mécanisme de login : Les échanges semblent indiquer qu’il est complètement « ouvert ».

On en avait déjà parlé auparavent : le mot de passe ne circule « jamais » en clair (si l’utilisateur active Javascript), mais encodé en MD5 avec une clef de codage qui n’est pas réutilisable. MD5 étant un algorithme non réversible, il est impossible (ou presque) de retrouver le mot de passe.

Qu’est-ce qui est reproché à ce mécanisme ?
Quelle attaque externe est possible ?

.Gilles

Bonjour la liste,

c’est tout simplement ridicule mais si tu maintiens que tu veux une belle porte blindée avec un paillasson devant pour pouvoir y cacher la clé…
maintenant, ne soit pas non plus surpris qu’on te dise que ce que tu veux faire l’est

Je m’étonne qu’on critique le mécanisme de login : Les échanges semblent indiquer qu’il est complètement « ouvert ».

On en avait déjà parlé auparavent : le mot de passe ne circule « jamais » en clair (si l’utilisateur active Javascript), mais encodé en MD5 avec une clef de codage qui n’est pas réutilisable. MD5 étant un algorithme non réversible, il est impossible (ou presque) de retrouver le mot de passe.

le mécanisme d’identification de SPIP est plus sûr qu’un formulaire ouvert où le mot de passe circule librement, mais moins qu’une identification en https.
Il y a des possibilités de le contourner, en particulier à base de vol de cookie.

Qu’est-ce qui est reproché à ce mécanisme ?
Quelle attaque externe est possible ?

Il faut simplement être cohérent sur le niveau de sécurité. En la matière, la théorie du tonneau percé s’applique : on ne sera jamais plus sûr que l’élément de la chaîne le moins sûr (ie c’est le trou le plus bas qui limite le niveau d’eau dans le tonneau).

Dans le cas de Marc, donc, son https sur les transactions est illusoire dans la mesure où l’identification initiale qui permet de passer ensuite en https n’est faite qu’en http. La sécurité globale de son application n’est donc pas meilleure que celle du formulaire de login lui même.
Dans mon analogie, j’avais bien pris soin de ne pas considérer que la clé était sous le paillasson, mais que la serrure était accessible et donc crochetable.

Cédric

Cédric Morin a écrit :

Il y a des possibilités de le contourner, en particulier à base de vol de
cookie.

l'alea se promène en clair aussi...

Oui Cédric, tu as parfaitement raison, et j’ai bien compris ton analogie … d’autant mieux que je l’ai appliqué lors de la configuration de mon serveur sous Linux Debian, en commançant par fermer tous les ports, pour ne rouvrir que ceux dont j’avais vraiment besoin …

En tout cas, j’ai bien suivi vos conseils à tous et on accède maintenant au site en question par une redirection, quelle que soit l’url, pour abouti à un formulaire en https …

Merci pour tous vos conseils …

Marc