Discussion :

[Katleen Erna]

Des hackers volent plus de 30 millions de mots de passe sur le site de RockYou, où les informations étaient stockées en clair

Plusieurs hackers, dont un connu sous le pseudo "igigi", ont réussi à pénétrer dans la base de données du site de RockYou. Le site appartient à la firme du même nom, qui est le plus gros fournisseur d'applications pour les réseaux sociaux.

Les pirates ont eu la surprise de constater que sur les serveurs auxquels ils avaient désormais accès, les informations relatives aux comptes des clients (y compris les mots de passe) étaient stockés... en clair !

Leur prise n'est pas négligeable car elle porte tout de même sur plus de 30 millions de comptes : 32 603 388 précisément.

Aussi incroyable que cela puisse paraître, les mots de passe étaient conservés dans un fichier texte non codé, accompagnés des identifiants leur correspondants (les adresses mails avec lesquelles les personnes s'étaient enregistrées sur le site).

Nul doute que de telles combinaisons login/password sont valables sur d'autres endroits de la toile, particulièrement sur les sites de réseaux sociaux, car la majorité des internautes utilise un seul et unique mot de passe pour protèger tous ses comptes virtuels.

L'attaque fut conduite par injection SQL au début du mois. Quand l'équipe technique de RockYou découvrit la faille , le 4 décembre, elle décida de fermer temporairement le site avant d'annoncer plus tard dans un communiqué que "le problème était résolu".

L'entreprise s'est ensuite refusée à tout commentaire.

Les hackers ayant réalisé l'exploit menacent de divulguer en public les informations relatives à ces millions de comptes, si la firme "ment à ses consommateurs".

Il est vivement recommandé à toute personne s'étant inscrite sur le site de RockYou, ou possédant un compte sur l'une de ses applications, de changer rapidement de mot de passe. Leurs comptes pourraient en effet être infiltrés par les pirates, et servir ensuite à ces derniers pour voler d'autres informations.

Les données volées dans le cas présent n'étaient ni financières, ni trop sensibles (pas de vol de numéro de sécurité sociale, par exemple) ce qui pousse à croire que le geste ne fut pas motivé par des visées mercantiles, mais plutôt par une envie de pointer des doigts les dysfonctionnements des réseaux sociaux.

Cet incident rappelle une fois de plus la grande dangerosité des injections SQL pour les sites internet des grandes entreprises, qui y restent trop souvent vulnérables. Cette menace arrive en tête de celles rencontrées sur Internet depuis plusieurs années.

Source : Le blog du hacker igigi

De quelle manière protègez-vous vos différents comptes sur Internet ? Utilisez-vous un mot de passe différent pour chaque site ?

[Génoce]

Apparemment ils en sont pas a leur coup d'essai :p.

Ça leur fera une leçon quand même... stocker les mdp en clair...

Personnellement j'ai un mot de passe diffèrent pour chaque site, par exemple dans mon mdp dvp y a dvp .

[Inazo]

Bonjour à tous,

C'est toujours aussi stupéfiant de voir ça. Mais c'est triste il y a deux semaine j'ai vu un MCD arrivé comme ça le mec avait prévu un champ INT 10 pour les mots de passe.

Et la question : "Tu les hash comment tes MDP ? Tu as un code crypto perso pour faire tous rentrer en INT 10 ?"

Réponse : "Crypter pour quoi faire ?"

Véridique et affolant.

Cordialement,

[spidermario]

Pour éviter les injections SQL, il suffirait de ne pas utiliser de requêtes SQL créées à la volées. En Erlang avec Mnesia, par exemple, la base de donnée est interrogée directement en Erlang.

[bombseb]

je comprend pas comment certains peuvent encore se faire avoir avec les failles de type injections SQL...

ils avaient pas l'option "magic quotes" ?

[shkyo]

Encore une confirmation affligeante que le facteur sécurité le plus critique reste le facteur humain !!!
Qui a une fâcheuse tendance à vouloir faire au plus simple histoire de ne pas s'embêter... (et je reste polis !)

[chemanel]

je comprend pas comment certains peuvent encore se faire avoir avec les failles de type injections SQL...

ils avaient pas l'option "magic quotes" ?

ça c'était l'injection du bon vieux temps

LoL, a mon avis, maintenant, il y a moyen de faire vraiment plus compliquer, on pourrait par exemple, dans un environnement .NET essayer de modifier le ViewState, pour que les objets qui se mettront a jour avec des "fausses" données puisse provoqué l'injection...

[Invité]

je comprend pas comment certains peuvent encore se faire avoir avec les failles de type injections SQL...

Le plus incompréhensible c'est le stockage en clair des mots de passe

Combien de fois j'ai reçu des emails de confirmation / rappel avec mon mot de passe en clair dans le mail...

[spidermario]

Le plus incompréhensible c'est le stockage en clair des mots de passe

Combien de fois j'ai reçu des emails de confirmation / rappel avec mon mot de passe en clair dans le mail...

D'ailleurs, dans la plupart des cas, il est impossible d'avoir sur le site en question un mot de passe qui n'a jamais été envoyé par e-mail, car il est réenvoyé sitôt changé

[zais_ethael]

Béh oui mais faut dire aussi qu'on le dit assez peu. Beaucoup de développeurs croient encore que l'utilisation des fonctions encrypt() et decrypt() de Mysql est suffisante pour avoir des mots de passes "sécurisés". Mais bien entendu pour un pirate qui a un accès total à la machine, base de données et code inclut c'est de la rigolade.

La seule solution un tant soit peu respectueuse des utilisateurs est de mettre en place un système ou même le gars qui a développé le programme et qui administre la machine serait totalement incapable de retrouver ce mot de passe (au fond, qu'est-ce qui nous dit que ce n'est pas une personne mal intentionnée comme une autre?). Avec une bonne fonction md5 et un peu d'astuce c'est très facile à faire, mais allez expliquer au client que "non non, il est impossible de retrouver les mots de passe, c'est même fait exprès".

[s4mk1ng]

Bon bah ça va pas me faire pleurer ils l'ont bien cherché...

[Skyounet]

a mon avis, maintenant, il y a moyen de faire vraiment plus compliquer, on pourrait par exemple, dans un environnement .NET essayer de modifier le ViewState, pour que les objets qui se mettront a jour avec des "fausses" données puisse provoqué l'injection...

Oui mais là l'injection sera traitée au niveau ADO.NET, et si le codeur a bien fait son travail (utilisation de DbParameter par exemple) y'aura pas de problème (sauf problème dans le framework mais y'en a pas à ce niveau à ma connaissance).

Mais oui je pense qu'il existe maintenant des techniques plus sophistiquées.

[chemanel]

Oui mais là l'injection sera traitée au niveau ADO.NET, et si le codeur a bien fait son travail (utilisation de DbParameter par exemple) y'aura pas de problème (sauf problème dans le framework mais y'en a pas à ce niveau à ma connaissance).

Mais oui je pense qu'il existe maintenant des techniques plus sophistiquées.

Oui j'suis d'accord avec toi, ici c'était un exemple rapide, mais t'as tout a fait raison en disant "si le codeur a bien fait son travail" ... C'est ça le vrai problème, ici dans la news, c'est le même problème, les mot de passe + emails traités en clair dans un fichier texte... C'est clairement un problème de développement !

[dams78]

Qu'est ce que ça peut m'énerver tout ces sites (et pas forcément des site "amateurs") qui conservent les mots de passe en claire.

J'en connais un (orienté linux en plus), qui tous les mois m'envoie par email mon user et mot de passe, super!!!!