Suite à un « bug », les mots de passe des utilisateurs de Twitter se sont retrouvés dans les logs internes de la société. Si aucune fuite n'est à déplorer, il est évidemment conseillé de le changer. Le réseau social donne quelques conseils (triviaux) et se veut rassurant.
Deux jours après GitHub, c'est au tour de Twitter d'être victime d'un « bug » concernant le stockage des mots de passe de ses utilisateurs. Cette fois-ci, la société s'est par contre fendue d'un billet de blog pour expliquer le problème. Il faut dire que l'ampleur ne semble pas la même, tous les utilisateurs étant potentiellement concernés.
Des mots de passe enregistrés avant la fin du « hachage »
« Nous avons récemment identifié un bug qui stockait des mots de passe en clair dans nos logs internes. Nous avons corrigé le bug, et notre enquête ne montre aucune indication de violation ou d'abus » explique Parag Agrawal, directeur technique.
Bien évidemment, et comme le précise la CNIL, un mot de passe ne doit jamais être stocké en clair, que ce soit dans les logs ou dans la base de données des utilisateurs. La pratique reste néanmoins courante, comme nous l'avions vu avec le cas du journal Les Échos il y a quelques jours. Vous pouvez d'ailleurs nous signaler des sites concernés via l'adresse :
[email protected]
Mais ici, ces recommandations étaient bien respectées. Comme GitHub, les mots de passe passent « à travers un processus appelé hachage en utilisant une fonction bcrypt », avant d'être enregistrés sur les serveurs de Twitter. Problème : « en raison d'un bug, les mots de passe ont été écrits dans les logs avant la fin du processus de hachage ».
Logs nettoyés, réinitialisation recommandée du mot de passe
La société explique avoir identifié elle-même cette faille, mais ne précise pas si elle a lancé une enquête suite à la révélation de GitHub. Les mots de passe concernés ont évidemment été supprimés et des actions mises en place afin d'éviter que ce genre de bug ne se reproduise.
Se pose alors la question de la consultation de ces logs par des employés de l'entreprise, un point qui n'est pas évoqué. Dans le cas de GitHub, seul « un petit nombre de mots de passe d'utilisateurs » était concerné, avec une réinitialisation du mot de passe obligatoire. De son côté, Twitter ne donne aucun chiffre, mais recommande « par précaution » à l'ensemble de ses utilisateurs de changer leur mot de passe, sans les y obliger.
Il reste appréciable que la société communique publiquement sur ce bug, contrairement à GitHub qui s'est contenté d'envoyer des emails aux personnes concernées.
I should not have said we didn’t have to share. I have felt strongly that we should. My mistake. https://t.co/Cqbs1KiUWd
— Parag Agrawal (@paraga) 3 mai 2018
Il est évidemment recommandé de faire de même sur l'ensemble des sites où vous avez utilisé le même mot de passe... ce qui n'est pas une bonne pratique pour rappel. Un mot de passe doit en effet être le plus souvent unique pour éviter qu'en cas de fuite, des pirates puissent accéder à d'autres services avec un effet boule de neige.
Un mot de passe par site, activez la double authentification
Le réseau social termine son billet par des excuses et des recommandations basiques en pareille situation : changer votre mot de passe, en choisir un suffisamment robuste, utiliser un gestionnaire de mot de passe pour vous aider dans cette tâche et enfin activer la double authentification.
Des recommandations qui s'appliquent finalement à l'ensemble des sites où cela est possible. Nous avons d'ailleurs publié un dossier complet sur le sujet :
Commentaires (38)
#1
Après GitHub ils se sont tous dit on va faire un tour dans nos logs voir ce qui s’y passe ?
Ou, on le sait pas encore mais c’est une librairie de logging (ou autre) commune à GH et Twitter qui en serait la cause ? Ce qui ferait que potentiellement des milliers d’autres sites pourraient être touchés ?
#2
Pas cool de Twitter d’être aussi obscur, la gestion du problème est pas digne.
Est-ce un bug de la dernière version ou carrément une erreur de conception qui vient tout juste d’être identifiée ?
Pourquoi n’ai-je pas encore reçu de mail de leur part ? Est-ce vraiment à la presse de m’apprendre l’info ?
#3
J’ai reçu une notification plein écran en ouvrant l’app iPhone en ce qui me concerne, hier soir.
#4
De mon coté aussi j’ai dessuite vérifié si nos logs ne contenaient pas les mot de passe mais tout est bon chez nous " />.
Pas besoin forcement d’une lib commune mais tu as vite fait d’enregistrer tous les paramètres envoyé en cas de crash ou d’erreur serveur sans penser que tu vas, sans le vouloir, peut être enregistrer les infos de login si le problème était à ce niveau.
#5
Yes, pareil de mon côté. En revanche aucune info sur le pourquoi…
“Ho tiens, le hasard fait que c’est le bon moment pour vous de changer de MdP” " />
#6
Ah si, j’ai reçu exactement la même info que je lis dans cet article : bug de mots de passe en clair en interne mais une enquête a permis de déterminer qu’il n’y a pas eu de fuite. Etrange cette communication à différents niveaux.
#7
Et surtout, est-ce que le Schmilblick gazouille ?
#8
Bon, je n’ai ni compte Facebook, ni compte Twitter…
J’ai pensé à plusieurs reprises m’en ouvrir un, mais là, ça me refroidit, et pas qu’un peu.
Et ça fait plus de vingt ans que l’on dit que la centralisation sur le net, c’est le mal ! Reste-il encore des gens qui en doutent après tout cela ?
#9
“bug”, c’est le nouveau nom de stagiaire ?
#10
#11
A quand la fin de mdp ?
La multiplication de ceux-ci et la complexification rends impossible a un être humain de se souvenir de tous.
Le système arrive a ses limites.
#12
Et mettez la 2FA
#13
Les hackers n’ont plus besoin d’accéder aux BDD, il suffit de pomper les logs :/
#14
#15
Comme quoi le problème n’est pas d’avoir des mots de passe ou pas avec des caractères tordus.
" />
#16
Me concernant j’ai eu :
une notification dans l’appli
une notification en pleine page en arrivant sur leur site
la réception d’un email rattaché au compte
#17
Peut-être apprendre une méthode plutôt qu’une masse de mot de passes sinon ?
#18
« Nous avons récemment identifié un bug qui stockait des mots de
passe en clair dans nos logs internes. Nous avons corrigé le bug, et
notre enquête ne montre aucune indication de violation ou d’abus »
J’ai activé les alertes mail lorsque je me connecte à Twitter et je ne sais pas si c’est lié à cette histoire mais il y a deux jours j’ai eu 3 alertes de connexion en pleine nuit alors que je dormais (entre 1h30 et 2h30), je l’ai remarqué le matin en consultant mes mail. Du coup j’ai comme un gros doute sur leur dernière affirmation :/
#19
#20
Je suis probablement un peu bête mais est-ce que loguer le résultat du hash d’un mot passe à un quelconque intérêt ? Garder la trace que la fonction hash a fonctionné ok mais avoir le hash dans le log je comprends pas …
#21
Le stagiaire qui a fait ca devait s’appeler Jean Michel Fail ! " />
#22
Ce qui est grave c’est que, comme à chaque fois où on colle ça sur le dos d’un prétendu stagiaire, c’est que c’est pas la faute d’un stagiaire…" />
#23
De son côté, Twitter ne donne aucun chiffre, mais recommande « par précaution » à l’ensemble de ses utilisateurs de changer leur mot de passe, sans les y obliger.
Comment ça, “Twitter recommande” ? Pour vous un billet de blog suffit à communiquer aux millions des utilisateurs ?
Parce que moi je n’ai reçu aucune notif ni e-mail.
Sinon, il n’est pas précisé depuis quand le bug existait. Si c’est 2 jours, ça va, ça peut au final peu d’inscrits, mais si c’est depuis le début, ça déconne vraiment…
#24
Non ce n’est pas la faute d’un stagiaire, mais le cumul d’erreur d’un dev et d’un admin.
GitHub et Twitter utilisent la même library qui malheureusement écrit le mdp (clair+hashé) dans le log avec le niveau INFO, au lieu du niveau DEBUG. Et comme en production on laisse le logger en niveau INFO, le mdp se retrouve dans le fichier log.
(a votre avis: True/False news ? hé… hé…)
#25
C’est à se demander comment c’est possible.
Des mots de passe non-hashé, sans sel ? A mon avis, c’est plutôt dû à une action délibérée, le “bug” n’étant qu’une bonne excuse…
#26
J’ai changé mon mot de passe de password à drowssap
Nickel.
#27
#28
#29
Non. Faire une “public disclosure”… c’est le mal.
Disons que pour avoir la source, il faudrait me payer ruby sur l’ongle.
#30
De mon côté, j’ai pas de compte Twitter ni Github, mais j’ai, pour la première fois, eu une connexion ratée sur mon compte wikipédia. Coïncidence ou quelqu’un qui aurait récupéré des login/mdp et les teste un peu partout ?
#31
#32
Personnellement c’est Dashlane qui m’a prévenue qu’il était grand temps que je change mon mot de passe. Aucun mail de Twitter. Après je me connecte une fois tous les 6 mois, donc ils m’ont peut-être mis dans la case “On verra plus tard” " />
#33
Moi je ne change pas. Changer les mots de passe il n’y a rien de tel pour les oublier.
#34
0000, puis 1111, etc.
C’est facile à retenir ou retrouver et on peut en changer régulièrement… " />
Ou sinon, un gestionnaire de mots de passe, ça permet d’avoir des mots de passe forts et de n’avoir à en retenir qu’un seul. Seul inconvénient c’est qu’il devient un SPOF.
#35
Oui, c’est ce qui m’inquiète… en plus un gestionnaire de mots de passes implique soit risquer de trimballer le gestionnaire de mots de passes avec un smartphone qui peut facilement être volé, soit ne pas pouvoir accéder à une bonne partie de ses comptes en dehors de chez soi !
Bon, je suppose que la solution c’est de chiffrer le smartphone et de ne pas utiliser un système de déverrouillage facile à contourner (mais donc aussi facile à utiliser!) - pas comme le schéma qui peut être retrouvé sans trop de difficulté à partir de la trace des doigts, et pas comme une montre connectée qui a une trop grande portée de déverrouillage!
#36
Ou bien gestionnaire en webapp (Keeweb, par exemple), avec fichier hébergé en ligne (par soi-même ou un commerçant pour les plus confiants). C’est plus ou moins gratuit et plus ou moins confidentiel selon le choix fait.