En particulier, on passe par des communications en clair quand les machines du service en ligne renvoie les cookies HTTP qui servent à identifier l'utilisateur quand il revient sur le site et qui évitent ainsi la saisie utilisateur / mot de passe pour une reconnexion. Ces mêmes cookies en clair servent à mettre en place les mécanismes des boutons du type "J'aime" de Facebook avec un utilisateur parfaitement identifié pour assurer une bonne propagation virale auprès de ses amis: j'en avais fait la démonstration explicite point par point dans ce billet.
Le cas est partculièrement dramatique pour Facebook (même si Firesheep fonctionne aussi pour Twitter, Flickr, Google, etc.) dont le succès des boutons Like est énorme:
- 1+ million de sites équipés en moins de 6 mois . A croire que beaucoup d'éditeurs n'ont pas vu ou se moquent du déséquilibre profond du deal proposé par Facebook autour de ces boutons
- 500+ millions d'utilisateurs actifs sur le service
En effet, tout le monde ou presque est sur Facebook, y revient plusieurs fois par jour ou se balade sur un site "Like-enabled" surtout quand il a 5 minutes à perdre avec son iPhone en attendant son train....
Il suffit de cliquer alors sur ces noms d'utilisateurs pour se retrouver instantanément connecter à leur place sur leur compte!
Oooooouch, un méchant coup dans le bas-ventre!
Je pense que l'on est est sur le pied de guerre chez Facebook pour mettre en place la contre-risposte: il y a déjà eu trop de bavures (même si nécessaires ?...) chez eux dans le domaine de la sphère privée!.
Il n'y aura à mon avis pas beaucoup d'autres parades possibles que celle mise en place par Google sur Gmail en janvier de cette année: activer l'encryption de bout en bout par SSL pour parer aux négligences des autres maillons de la chaîne de transmission....
L'objectif de Eric Butler (comme de mon billet d'ailleurs) n'est pas d'inciter au piratage de données personnelles mais plutôt de montrer aux utilisateurs les dangers du laxisme en termes de protection de la sphère privée afin qu'ils se mettent en retour à "tirer les oreilles" des éditeurs de services en ligne pour les forcer à corriger leurs faiblesses puisque leur exploitation est à la portée de tout un chacun!
Dans le cas de Facebook, cela devrait coûter quelques milliers de serveurs additionnels (ajoutés à un parc déjà bien étoffé...) car la compression SSL est particulièrement gourmande en puissance de calcul - Si bien sûr c'est la solution retenue....
Source: blog Media and Tech (par didier durand)
2 commentaires:
On a des chiffres sur le cout supplémentaire lié à l'implémentation SSL? D'après l'EFF, c'est pas si couteux que cela (mais c'est vrai qu'ils prennent l'exemple de Google, pas vraiment représentatif)
Je tiens a préciser que Firesheep ne fonctionne pas uniquement en WiFi comme vous le précisez dans votre article.
Avec un simple ARP spoofing même sur un réseau filaire commmuté (95% des LAN) on peut utiliser firesheep avec succes.
Enregistrer un commentaire