Bug Twitter : la sécurité dès la conception et par défaut doit devenir une réalité 

Twitter a annoncé une anomalie ce matin. Quelles données personnelles sont exposées ? Quel est l'impact pour les internautes ? Comment les grandes marques du web gèrent-elles la plus grande exigence des internautes. Nicolas Chagny analyse les enjeux de ce "bug", et le besoin croissant de transparence des utilisateurs d'internet.

Il y a quelques jours, Twitter a annoncé par un tweet une anomalie de sécurité découverte dans son système : « Nous avons récemment trouvé un bug qui faisait que des mots de passe non cryptés étaient stockés dans un log interne. Nous avons corrigé ce bug et n’avons aucune indication de fuite ou d’usage mal intentionné par quiconque. Par précaution, nous vous conseillons de changer votre mot de passe, ainsi que sur tout autre service où ce mot de passe est utilisé ». https://twitter.com/twittersupport/status/992132808192634881

Le tweet en question renvoie vers un article de blog de Parag Agrawal, directeur technique de Twitter, qui expose plus en détail la méthode de cryptage utilisée par Twitter et le fait que les mots de passe aient été stockés en clair dans leur logs internes avant cryptage. Il indique aussi qu’ils ont eux-mêmes découvert ce bug, l’ont corrigé et nettoyé les logs. Il explique enfin comment sécuriser son compte Twitter.

C’est juste un log, ma bonne dame !

Un « log » : pour le commun des mortels, cela ne veut rien dire, mais pour qui a touché un jour à l’informatique, cela veut dire beaucoup. Pourquoi ? Parce que toutes nos actions génèrent des quantités impressionnantes de logs. Un log, c’est une trace. Stockée dans un fichier texte, dans une base de données où via des protocoles spécialisés, ces traces indiquent chaque action unitaire faite sur un service. Elles servent à l’ensemble de l’éco-système informatique pour détecter des anomalies et stocker des informations préventivement, pour remonter une attaque, par exemple. Le développeur du logiciel choisit ce qu’il met dans sa trace, pour le besoin futur. 

Ces fichiers de logs existent par milliers : sur votre ordinateur, dans les routeurs, chez votre fournisseur d’accès et dans les applications que vous utilisez. Ces fichiers de logs sont ensuite compressés et stockés, soit selon le délai nécessaire par l’application, soit selon le délai légal, pour les fournisseurs d’accès, par exemple.Peu se soucient de ce qu’ils contiennent réellement. A minima, un horodatage et une indication de qui fait l’action (au hasard, une adresse IP). Puis il contient ce que l’on veut tracer à l’instant précis pour un hypothétique besoin futur.Ainsi, selon l’envie du moment du développeur qui a écrit la ligne de code générant le log, celui-ci peut contenir diverses informations et, peut-être même, des données personnelles. A noter toutefois que certains logs sont normalisés, comme les logs des serveurs web.

La réaction massive et préventive de Twitter

On ne peut que saluer la communication de Twitter sur l’existence de cette anomalie. C’est sans doute sous la pression des multiples scandales de Yahoo!, ou plus récemment de Facebook - même si Cambridge Analytica n’a rien à voir avec une faille, ou bien sous la pression mise par les européens avec le Règlement RGPD, que Twitter décide de communiquer. Par contre, la communication reste laconique sur le nombre de comptes concernés (donc tous ?) ainsi que sur les mesures de sécurité associées au stockage et à l’accès à ces traces. Par cette communication, Twitter souhaite-il se mettre à l’abri d’un scandale futur si l’on découvrait que quelqu’un a eu accès à ces traces ? Aucun moyen de le savoir à ce stade, mais Twitter a fait le choix d’une communication massive et préventive sur une anomalie qu’il aurait pu passer sous silence, la violation des données n’étant pas avérée. Les préconisations sont saines en matière de sécurité : changer le mot de passe, et changer partout où ce même mot de passe a été utilisé.

Comment éviter le pire ?

Le Règlement RGPD introduit les notions de « Privacy by Design » et de « Security by Default». Ainsi, à compter de l’entrée en application du règlement le 25 mai, ces approches prévoyant la prise en compte de la protection des données personnelles et de leur sécurité dès la conception d’une application et par défaut, seront une réalité pour les sociétés installées  en Europe et pour quiconque y opère. Cela implique de sensibiliser chaque développeur d’application sur la sécurité de chaque action. Le développeur qui a introduit ce log chez Twitter a sans doute cru bien faire en y stockant le mot de passe en clair. Espérons qu’avec la prise de conscience massive et la communication liée au RGPD, on évitera ce type d’anomalie si anodine en soit et si possiblement grave de conséquence. Chaque société doit aussi se poser la question de sa politique de stockage et d’accès aux logs des applications : contenus des traces, délai de stockage, règles d’accès, politique de destruction.

Les utilisateurs d’Internet doivent maintenir la pression sur les opérateurs techniques et fournisseurs d’applications pour obtenir toujours plus de transparence sur ce qui est fait de leurs données personnelles et exiger qu’elles soient traitées avec le plus haut niveau de sécurité. La transparence exige aussi de savoir reconnaître et communiquer sur ses erreurs. C’est la condition pour la confiance. C’est la seule condition pour garantir l’avenir d’Internet.