Firesheep
Re: Firesheep
En effet, c'est un problème connu depuis bien longtemps. Espérons que ça décide les sites web à se mettent enfin au cryptage des données.
Le monde se divise en 10 catégories : ceux qui comptent en binaire et ceux qui ne comptent pas en binaire.
Re: Firesheep
Il y a un billet sur Linuxfr.org: http://linuxfr.org/2010/10/29/27514.html
Point intéressant le code: la certa dit:
Si on voit le code on sait comment cela marche non ?
Point intéressant le code: la certa dit:
et dans l'article de Linuxfr, il y a un lien vers le code.Tout d’abord, il s’agit d’un outil non testé et au mode de développement inconnu. On ne reviendra pas ici sur les risques qu’il y a à installer de tels logiciels.
Si on voit le code on sait comment cela marche non ?
Re: Firesheep
En fait, il n'y a rien de nouveau: n'importe qui pouvait faire cela avec Wireshark depuis des années (bien avant que Wireshark s'appelle Wireshark).
Il n'y a pas de miracle: si l'on utilise http avec un cookie de session, il est possible de hijacker la session si on écoute ce qui passe sur le réseau. Donc dès qu'on utilise un cookie pour identifier quelqu'un (et pas seulement l'authentification initiale), il faut passer en https.
Firesheep a le code ouvert et son contenu à été contrôlé: il n'y a pas de soucis avec l'extension elle-même. Tout site prétendant le contraire est à mettre dans la catégorie incompétent et à éviter.
En montrant le problème de manière à ce que n'importe qui puisse le vérifier, Firesheep, qui n'est pas un malware, gêne pas mal de sites web...
Il n'y a pas de miracle: si l'on utilise http avec un cookie de session, il est possible de hijacker la session si on écoute ce qui passe sur le réseau. Donc dès qu'on utilise un cookie pour identifier quelqu'un (et pas seulement l'authentification initiale), il faut passer en https.
Firesheep a le code ouvert et son contenu à été contrôlé: il n'y a pas de soucis avec l'extension elle-même. Tout site prétendant le contraire est à mettre dans la catégorie incompétent et à éviter.
En montrant le problème de manière à ce que n'importe qui puisse le vérifier, Firesheep, qui n'est pas un malware, gêne pas mal de sites web...
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Re: Firesheep
Par qui ? Ici le code est tout petit, donc ça limite le risque, mais l'open source n'est pas une garantie contre la malveillance (et en plus, qui compile son extension soi-même à partir du code source ?)teoli2003 a écrit :Firesheep a le code ouvert et son contenu à été contrôlé
Sinon, une alternative aux cookies, c'est l'authentification HTTP Digest. Il me semble que ce n'est pas vulnérable aux attaques de type rejeu (le cas des cookies).
Une question : est-ce que ce mode d'authentification est aussi vulnérable à ce type d'attaque par wifi ?
Re: Firesheep
Par Mozilla, suite à une demande (refusée) de blacklist. Le code a *vraiment* été contrôlé (et c'est parce qu'il était court que cela a été possible; et regarder si les infos sont envoyées à l'extérieur dans un code non-obscurci, c'est pas la mer à boire, hein), maintenant on peut céder à la paranoïa en disant que le code compilé est différent, mais il a été vérifié qu'il ne se connecte pas à l'extérieur, donc c'est peu probable.calimo a écrit :Par qui ?teoli2003 a écrit :Firesheep a le code ouvert et son contenu à été contrôlé
Cette extension est infiniment plus sûre que toutes les cochonneries ajoutées dans le navigateur par Google, Adobe, Apple, Microsoft ou des trucs comme CoolIris.
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Re: Firesheep
Cela ne joue pas. Les cookies sont utilisés pour passer l'information d'authentification une fois que celle-ci a été faite (c'est nécessaire car le protocole HTTP est un protocole sans état, stateless en anglais). Le HTTP Digest ne sert qu'à l'authentification initiale; il serait impraticable de l'utiliser pour chaque requête, il faudrait entrer son mot de passe chaque fois que l'on clique sur un lien...calimo a écrit : Sinon, une alternative aux cookies, c'est l'authentification HTTP Digest. Il me semble que ce n'est pas vulnérable aux attaques de type rejeu (le cas des cookies).
Une question : est-ce que ce mode d'authentification est aussi vulnérable à ce type d'attaque par wifi ?
De plus le HTTP Digest est vulnérable à une attaque man-in-the-middle, ce qui n'est pas le cas de HTTPS + cleartext suivi de HTTPS + cookie.
Enfin, même si les messages cryptés sont courts et cela ne devrait pas être un problème hors d'un labo, le MD5 n'est plus considéré comme sûr de nos jours (quoique je doute qu'une attaque basée sur la faiblesse du MD5 permette de contourner le HTTP Digest. Je veux juste montrer par là qu'il n'est pas évolutif, contrairement au HTTPS qui peut supporter de nouvelles méthodes de cryptage et possède un système de versioning du protocole TLS utilisé).
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Re: Firesheep
Non, le HTTP Digest n'est pas juste une authentification initiale. Les requêtes suivantes sont également authentifiées (dans un domaine spécifié, évidemment moins souple que les cookies tiers), et je me demande à quel point c'est résistant à un sniffing...teoli2003 a écrit :Cela ne joue pas. Les cookies sont utilisés pour passer l'information d'authentification une fois que celle-ci a été faite (c'est nécessaire car le protocole HTTP est un protocole sans état, stateless en anglais). Le HTTP Digest ne sert qu'à l'authentification initiale; il serait impraticable de l'utiliser pour chaque requête, il faudrait entrer son mot de passe chaque fois que l'on clique sur un lien...
Par exemple, après s'être authentifié, sur une requête suivante Firefox envoie ça :
Code : Tout sélectionner
Authorization: Digest username="calimo", realm="Private access area", nonce="CATHsNWTBAA=75d08e55b1df6d3699f6dfce0b95d63790e09465", uri="/private/index.html", algorithm=MD5, response="1c7529a024a60492dcda2d2f95e8a686", qop=auth, nc=00000004, cnonce="1eed8d3e43cacaa9"
Bien sûr rien n'empêche d'autres attaques, mais c'est quand-même plus compliqué de mettre en place un man in the middle (il faut être là à la connexion initiale, transmettre les requêtes de manière transparente, etc.).
Qui est en ligne ?
Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 12 invités