Twitter attaqué : fuite de données pour 250 000 comptes

Twitter attaqué : fuite de données pour 250 000 comptes

Changement de mot de passe pour tout le monde !

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

02/02/2013 2 minutes
39

Twitter attaqué : fuite de données pour 250 000 comptes

Twitter vient d'annoncer qu'il avait été la cible d'une attaque ces derniers jours, menant à la fuite d'informations concernant 250 000 comptes d'utilisateurs. Par sécurité, les accès de ces derniers ont été réinitialisés, si vous êtes concernés, vous devriez recevoir un mail détaillant la procédure à suivre.

Bob Lord, qui travaille au sein de l'équipe dédiée à la sécurité de Twitter, vient de se fendre d'un billet sur le blog du service de micro-blogging. Il indique que ses collègues ont détecté des tentatives d'accès aux données utilisateurs cette semaine, dont une qu'ils ont pu interrompre en pleine exécution. Pour autant, une fuite d'information a été découverte.

 

Des pseudos, adresses e-mail, tokens de session et une version chiffrée (avec une composante aléatoire, le salt) du mot de passe ont été récupérés. Ainsi, le mot de passe lui-même ne devrait pas pouvoir être découvert par les attaquants, mais par sécurité Twitter a tout de même réinitialisé les données de connexion des 250 000 comptes concernés. Les utilisateurs touchés sont contactés par courriel afin de leur indiquer la procédure à suivre.

 

twitter over capacite

 

Selon l'équipe du site, ce n'était pas l'oeuvre d'amateurs, et ils pensent ne pas se trouver face à une tentative isolée, d'autres sociétés pourraient faire face à des attaques similaires. Les autorités compétentes ont été contactées afin de donner une suite à cette affaire.

 

Twitter en profite pour rappeler l'importance du choix d'un mot de passe fort (au moins 10 caractères, un mélange alphanumérique contenant des symboles et jouant sur les majuscules minuscules, même si cette définition ne fait pas consensus), qui ne soit pas le même pour l'ensemble des services que vous utilisez.

 

Nous reviendrons sur le sujet dès que nous aurons plus de détails.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (39)


Un lien avec la panne d’hier peut-être ?




une version chiffrée (avec une composante aléatoire, le salt) du mot de passe ont été récupérées. Ainsi, le mot de passe lui-même ne devrait pas pouvoir être découvert





Une version chiffree ou un hash ?

Meme avec un salt, au moins 10% des pwds sont recuperables avec une attaque au dico.





mot de passe fort (au moins 10 caractères, un mélange alphanumérique contenant des symboles et jouant sur les majuscules minuscules, même si cette définition ne fait pas consensus)





Regle de merde, rien ne vaut les passphrases en minuscules (20-30 chars). Soit dit en passant le dernier webmail qui m’a laisse faire ca c’est yahoo, c’est dire … <img data-src=" />








Spow a écrit :



Une version chiffree ou un hash ?

Meme avec un salt, au moins 10% des pwds sont recuperables avec une attaque au dico.







Avec un salt long, il est necessaire d’avoir une rainbow table precalculée par salt possible…

Inutile de dire que meme avec de gros moyens, ils n’auront pas 10% des 250000 mots de passe…









Guiguiolive a écrit :



Avec un salt long, il est necessaire d’avoir une rainbow table precalculée par salt possible…

Inutile de dire que meme avec de gros moyens, ils n’auront pas 10% des 250000 mots de passe…





Sans oublier que le salt en question n’est peut-être pas statique mais au contraire unique par compte et là ça devient beaucoup plus compliqué.









Guiguiolive a écrit :



Avec un salt long, il est necessaire d’avoir une rainbow table precalculée par salt possible…

Inutile de dire que meme avec de gros moyens, ils n’auront pas 10% des 250000 mots de passe…





<img data-src=" />





Rien compris <img data-src=" />









linkin623 a écrit :



<img data-src=" />





Rien compris <img data-src=" />







Moi je vois salt et rainbow dans la même phrase. Si tu veux mon avis, ça a un rapport avec l’usage de substances pas très légale <img data-src=" /><img data-src=" />









John Shaft a écrit :



Moi je vois salt et rainbow dans la même phrase. Si tu veux mon avis, ça a un rapport avec l’usage de substances pas très légale <img data-src=" /><img data-src=" />





<img data-src=" />



Le 02/02/2013 à 01h 51

“Twitter en profite pour rappeler l’important du choix d’un mot de passe fort ”



et d’avoir une sécurité forte chez ceux qui les stockent.

Genre c’est l’utilisateur qui est coupable.








linkin623 a écrit :



<img data-src=" />

Rien compris <img data-src=" />









John Shaft a écrit :



Moi je vois salt et rainbow dans la même phrase. Si tu veux mon avis, ça a un rapport avec l’usage de substances pas très légale <img data-src=" /><img data-src=" />





Euh, ma phrase devait pas etre claire peut etre…



Avec une valeur de salt long et generée aleatoirement, le hash du password est securisé contre les attaques par rainbow table…

Parce qu’il faut une rainbow table differente par valeur de salt utilisée…



Alors 250000 passwords a trouver, avec un salt disons de 256 bit, ca nous fait 2^256 tables a precalculer… (meme 48bits, comme le salt sous Linux par defaut, ca reste velu)



Je persiste a penser que 10% de ces mots de passe ne seront pas trouvés par une attaque par rainbow table, et du coup, evidement encore moins facilement par dictionnaire… <img data-src=" />









Guiguiolive a écrit :



Euh, ma phrase devait pas etre claire peut etre…



Avec une valeur de salage long et generée aleatoirement, l’empreinte du mot de passe est sécurisée contre les attaques par table arc en ciel

Parce qu’il faut une table arc en ciel différente par valeur de salage utilisée…



Alors 250000 mots de passe à trouver, avec un salage disons de 256 bit, ca nous fait 2^256 tables a precalculer… (même 48bits, comme le salage sous Linux par defaut, ca reste velu)



Je persiste a penser que 10% de ces mots de passe ne seront pas trouvés par une attaque par table arc en ciel, et du coup, évidement encore moins facilement par dictionnaire… <img data-src=" />







Ah ok, merci pour l’explication. Tu bosses dans le domaine?









Guiguiolive a écrit :



Euh, ma phrase devait pas etre claire peut etre…







A part le coup du rainbow, c’était clair pour moi. C’est juste que je suis d’humeur taquine <img data-src=" /> <img data-src=" />









Guiguiolive a écrit :



Euh, ma phrase devait pas etre claire peut etre…



Avec une valeur de salt long et generée aleatoirement, le hash du password est securisé contre les attaques par rainbow table…

Parce qu’il faut une rainbow table differente par valeur de salt utilisée…



Alors 250000 passwords a trouver, avec un salt disons de 256 bit, ca nous fait 2^256 tables a precalculer… (meme 48bits, comme le salt sous Linux par defaut, ca reste velu)



Je persiste a penser que 10% de ces mots de passe ne seront pas trouvés par une attaque par rainbow table, et du coup, evidement encore moins facilement par dictionnaire… <img data-src=" />







De toute façon, ils ont récupéré une version chiffrée par salt du password. Et étant donné la réputation de Twitter, je doute que le salt de début soit “hackez” et le salt de fin soit “moi”.

Donc entièrement d’accord avec toi. À moins d’utiliser les email pour du spam et faire une recherche Google pour savoir derrière qui se cache les pseudos en espérant qu’ils utilisent leur pseudo comme mot de passe sur d’autres service, au final les informations piratés ne leur serviront à rien.



Ça ne peut être que l’UEJF à tout les coup, quand ils arrivent pas à avoir un truc aller hop le Mossad à l’action.



Il y a aussi les chinois vu l’attaque sur le New York Times, mais eux je ne sais pas qui ils envoient. Des chinois du FBI s’en doute ?


Le 02/02/2013 à 06h 46

waw, si les hackers trouvent les mots de passe, ils pourront avoir accès à tous les tweets !!! <img data-src=" />


Je suis dans les 250 000 comptes, super ! Le bon coté c’est que j’ai un mot de passe différent pour chaque site…


http://passwordmaker.org/ et hop un password par site








khertan a écrit :



http://passwordmaker.org/ et hop un password par site





Comme déjà dit, ce n’est pas forcément la meilleure solution. L’utilisateur va stocker ses mots de passe pour s’en rappeler, et ce pas forcément de manière très sécurisée. Les passphrases peuvent être une bonne alternative, mais il n’y a pas de toutes façon pas de bonne solution : le mot de passe seul c’est une plaie <img data-src=" />









David_L a écrit :



Comme déjà dit, ce n’est pas forcément la meilleure solution. L’utilisateur va stocker ses mots de passe pour s’en rappeler, et ce pas forcément de manière très sécurisée. Les passphrases peuvent être une bonne alternative, mais il n’y a pas de toutes façon pas de bonne solution : le mot de passe seul c’est une plaie <img data-src=" />





Le coup de la passphrase avec une attaque par dico bien pensée ça devrait être facilement (d’un point de vue matériel) crackable non?



Parce que même si tu ponctue ta phrase avec des caractères spéciaux, on pourrait imaginer de faire un algo probabiliste (les gens vont plus souvent utiliser #@-_”&‘()=² entre des mots de dico et mettre une majuscule en début de mot ou à la fin) et ça diminue drastiquement le temps nécessaire pour trouver le mot de passe.



Avec la pass phrase en théorie l’entropie est du genre “quantité de mot dans le dictionnaire de la langue” exposant “nombre de mot” la quantité de mot dans une langue est sensé être bien plus élevée que les 128 caractères affichables de l’ascii



Donc des probabilités peuvent réduire la recherche à un certain vocabulaire mais ce nombre de mot dans un vocabulaire restera toujours plus élevé que le nombre de caractères utilisables dans un mot de passe après la longueur de la phrase correspond à peu prêt a la sécurité de la longueur du mot de passe…



Si en plus certains s’amusent à mélanger les langues, de l’argot, du patois, ou une orthographe propre…



L’algo nécessaire pour les probabilités sera surement plus intéressant à utiliser dans la recherche linguistique que par des pirates, donc ça pourrait pas faire de mal que les pirates participent à la recherche linguistique <img data-src=" />








kypd a écrit :



(…)



Donc des probabilités peuvent réduire la recherche à un certain vocabulaire mais ce nombre de mot dans un vocabulaire restera toujours plus élevé que le nombre de caractères utilisables dans un mot de passe après la longueur de la phrase correspond à peu prêt a la sécurité de la longueur du mot de passe…



Si en plus certains s’amusent à mélanger les langues, de l’argot, du patois, ou une orthographe propre…



L’algo nécessaire pour les probabilités sera surement plus intéressant à utiliser dans la recherche linguistique que par des pirates, donc ça pourrait pas faire de mal que les pirates participent à la recherche linguistique <img data-src=" />







Cela suppose donc que la passphrase n’est strictement aucun sens, et avec suffisamment de mots et si possible de langue différentes (Sinon d’un point de vue probabiliste, tu réduit énormément le temps de calcul en utilisant des algo sur des chaines de markov type viterbi ou baum-welch). Sachant qu’il faut tout de même en avoir une différente par site web, on se retrouve avec une difficulté identique à celle d’un mot de passe basé sur des caractères (En gros au lieu d’écrire ton mot de passe, tu écris son moyen mnémotechnique). Et niveau déchiffrement du mot de passe, la seule “sécurité” en plus si je puis dire, c’est qu’à priori le hacker ne sait pas si c’est un mot de passe standard ou une passe phrase. Une sorte de sécurité par l’obscurité (ce qui, pour une action de masse est une vraie sécurité, si tu te considère dans le 0,001% des utilisateurs qui ne font pas comme les autres), un peu d’ingénierie sociale peut contourner cette sécurité.









Skeeder a écrit :



Le coup de la passphrase avec une attaque par dico bien pensée ça devrait être facilement (d’un point de vue matériel) crackable non?



Parce que même si tu ponctue ta phrase avec des caractères spéciaux, on pourrait imaginer de faire un algo probabiliste (les gens vont plus souvent utiliser #@-_”&‘()=² entre des mots de dico et mettre une majuscule en début de mot ou à la fin) et ça diminue drastiquement le temps nécessaire pour trouver le mot de passe.





Une passphrase n’est pas forcément simpliste, mais effectivement et comme dit plus haut, il n’y a pas de bonne solution, le souci étant le mot de passe unique comme moyen de sécurisation.









David_L a écrit :



Une passphrase n’est pas forcément simpliste, mais effectivement et comme dit plus haut, il n’y a pas de bonne solution, le souci étant le mot de passe unique comme moyen de sécurisation.





Cela en poursuivant la réflexion de mon précédent post, peut être que c’est une meilleure solution si cette technique d’écriture de mot de passe reste marginale. Peut être que le risque c’est certain services qui limitent le nombre de caractères pour un mot de passe.









Skeeder a écrit :



Cela en poursuivant la réflexion de mon précédent post, peut être que c’est une meilleure solution si cette technique d’écriture de mot de passe reste marginale. Peut être que le risque c’est certain services qui limitent le nombre de caractères pour un mot de passe.





Tu veux parler des banques et de leurs solutions à 6 chiffres ? <img data-src=" />









David_L a écrit :



Tu veux parler des banques et de leurs solutions à 6 chiffres ? <img data-src=" />







Genre ma banque, HSBC… 4 ou 6 chiffres seulement ! Vraiment de la merde…









creatix a écrit :



Genre ma banque, HSBC… 4 ou 6 chiffres seulement ! Vraiment de la merde…







Je crois que pour HSBC (FR) tu peux mettre ce que tu veux en passant sur “Global View”, t’as toujours un mot de passe de 8 caractères max, mais tu as une question secrète personnalisée que tu es obligé de rentrer pour te connecter au site.



Sur HSBC au Royaume-uni, il y a une authentification à deux facteur (mot de passe + token), je pense qu’ils devraient généraliser ça pour ce genre de services en ligne.









kypd a écrit :



L’algo nécessaire pour les probabilités sera surement plus intéressant à utiliser dans la recherche linguistique que par des pirates, donc ça pourrait pas faire de mal que les pirates participent à la recherche linguistique <img data-src=" />







Après les Pirates de la Silicon Valley… les Pirates de la Lexicographie ! <img data-src=" />









Yzokras a écrit :



“Twitter en profite pour rappeler l’important du choix d’un mot de passe fort ”



et d’avoir une sécurité forte chez ceux qui les stockent.

Genre c’est l’utilisateur qui est coupable.





D’une part ce n’est pas forcément la faute à Twitter : cela peut résulter d’une faille dans un logiciel bien connu utilisé par le serveur (de l’OS jusqu’au serveur http, etc). Ensuite il ne faut pas se leurrer : quoi que tu fasses, quelqu’un finira toujours par trouver un moyen d’entrer. C’est comme si le flic t’engueulait parce que tu viens de te faire cambrioler.



Ça arrive, c’est tout. Twitter a bien réagi et le minimum a été volé grâce aux mesures préventives de sécurité en place (sel, séparation des données, etcetera).







Guiguiolive a écrit :



Je persiste a penser que 10% de ces mots de passe ne seront pas trouvés par une attaque par rainbow table, et du coup, evidement encore moins facilement par dictionnaire… <img data-src=" />





Oh ! Je pense qu’ils n’essaieront même pas les rainbow table mais utiliseront directement les dicos et la force brute. Si c’est du SHA-1, une pile de GPU de quelques milliers de dollars peut en tester plusieurs dizaines de milliards par seconde, de quoi cracker de bons mdp de huit caractères à la chaîne.









HarmattanBlow a écrit :



Oh ! Je pense qu’ils n’essaieront même pas les rainbow table mais utiliseront directement les dicos et la force brute. Si c’est du SHA-1, une pile de GPU de quelques milliers de dollars peut en tester plusieurs dizaines de milliards par seconde, de quoi cracker de bons mdp de huit caractères à la chaîne.





Ils vont mouliner longtemps les GPU puisqu’ils n’ont accès qu’à des mdp salés





Si leur valeur de salage n’a rien à voir avec l’username ou l’email de l’user, ils peuvent se gratter pour obtenir quoi que ce soit





plus important encore, quel est l’intérêt d’avoir accès à des comptes twitter









psikobare a écrit :



plus important encore, quel est l’intérêt d’avoir accès à des comptes twitter







Y a de bonnes chances que les logins/MdP soit valables ailleurs <img data-src=" />









HarmattanBlow a écrit :



Oh ! Je pense qu’ils n’essaieront même pas les rainbow table mais utiliseront directement les dicos et la force brute. Si c’est du SHA-1, une pile de GPU de quelques milliers de dollars peut en tester plusieurs dizaines de milliards par seconde, de quoi cracker de bons mdp de huit caractères à la chaîne.





L’attaque par dico, il y a peu de chances, vu que l’attaque par rainbow table est justement une amelioration de l’attaque par dico pour permettre de s’attaquer a des hash sans avoir un dico complet.



Pour le bruteforce, si tu consideres les mots de passe de 8 caracteres seuls, pourquoi pas… Mais la, une fois le salage effectué, tu peux tres bien considerer que le salt est le mot de passe, et le mot de passe le salt…



Car le principe du salage est: hachage = fonction_de_hashage(mot_de_passe + salt)



Si le salt est long, 128 ou 256bit, ca te fait un mot de passe costaud. Rajouté a ca, un mot de passe de 8 caracteres alphanumeriques (environ 40bit pour une combinaison de chiffres et de lettre minuscules uniquement) qui “salt” le vrai salt de 256bit, et sachant que les gars n’ont AUCUNE idée de ce qu’ils cherchent (chaque salt etant unique, chaque hash est completement unique, meme avec le meme mot de passe), ils ne trouveront rien… <img data-src=" />









psikobare a écrit :



Si leur valeur de salage n’a rien à voir avec l’username ou l’email de l’user, ils peuvent se gratter pour obtenir quoi que ce soit







La plupart du temps, le salt est stocké dans le hash. Dans un shadow on a \(id\)salt$hashed.



Si le salt est un secret suffisamment long, non présent dans la db, et que les hackers ne l’ont pas récupéré là où il est stocké, alors en effet rien ne va tomber.



Si le salt est stocké dans la db, même différent pour chaque utilisateur, cela n’empêche que les attaques utilisant des rainbow tables. Une attaque par dictionnaire reste tout à fait possible. C’est ce qu’HarmattanBlow voulait dire, je pense.









NeVeS a écrit :



Si le salt est stocké dans la db, même différent pour chaque utilisateur, cela n’empêche que les attaques utilisant des rainbow tables. Une attaque par dictionnaire reste tout à fait possible. C’est ce qu’HarmattanBlow voulait dire, je pense.





En fait c’est surtout que j’ai trop souvent vu ce que tu décris : sels stockés dans la DB, concaténés avec le hash ou calculés depuis le nom d’utilisateur. Mais ici on peut espérer que Twitter avait bien fait les choses et stocké les sels sur un autre serveur, ce qui est recommandé.










NeVeS a écrit :



Si le salt est un secret suffisamment long, non présent dans la db, et que les hackers ne l’ont pas récupéré là où il est stocké, alors en effet rien ne va tomber.



Si le salt est stocké dans la db, même différent pour chaque utilisateur, cela n’empêche que les attaques utilisant des rainbow tables. Une attaque par dictionnaire reste tout à fait possible. C’est ce qu’HarmattanBlow voulait dire, je pense.





les gars de twitter sont des gens sérieux, et les salt n’ont aucun intérêt à être dans la même bdd



enfin, on en saura plus plus tard



C’est la faute du Krakatoa à l’Est de Java (le fail d’Oracle)



Il est entré en irruption <img data-src=" /><img data-src=" /><img data-src=" /> spontanée de DDOS (sûrement) <img data-src=" />








Spow a écrit :



Une version chiffree ou un hash ?

Meme avec un salt, au moins 10% des pwds sont recuperables avec une attaque au dico.







Regle de merde, rien ne vaut les passphrases en minuscules (20-30 chars). Soit dit en passant le dernier webmail qui m’a laisse faire ca c’est yahoo, c’est dire … <img data-src=" />







Petit joueur mon MDP a ma Webmail fait 97 Caractères Alpha-Caractéro-Casso-Numérique <img data-src=" /> <img data-src=" />



Avec une mnémotechnie qui m’oblige à changer le quart des caractères chaque mois <img data-src=" />



Non, non… Je ne travaille pas au gouvernement et je ne suis pas non plus un terroriste <img data-src=" />









g30lim4 a écrit :



Petit joueur mon MDP a ma Webmail fait 97 Caractères Alpha-Caractéro-Casso-Numérique <img data-src=" /> <img data-src=" />



Avec une mnémotechnie qui m’oblige à changer le quart des caractères chaque mois <img data-src=" />



Non, non… Je ne travaille pas au gouvernement et je ne suis pas non plus un terroriste <img data-src=" />







Bravo ton mot de passe est crackable en 10 milliard d’années au lieu de 5 millions … très utile.









bzc a écrit :



Bravo ton mot de passe est crackable en 10 milliard d’années au lieu de 5 millions … très utile.







J’aime faire durer les plaisirs <img data-src=" />









David_L a écrit :



Comme déjà dit, ce n’est pas forcément la meilleure solution. L’utilisateur va stocker ses mots de passe pour s’en rappeler, et ce pas forcément de manière très sécurisée. Les passphrases peuvent être une bonne alternative, mais il n’y a pas de toutes façon pas de bonne solution : le mot de passe seul c’est une plaie <img data-src=" />







Justement le but n’est pas de stocker le mot de passe … Un mot de passe principal sert à hasher le pass principal plus le nom du site … et après il y a une extension firefox qui demande le mot de passe principal pour saisir le mot de passe hasher sur le site (et il y a aussi des apps mobile pour chaque plateforme)