Suite à un « bug », GitHub a enregistré des mots de passe en clair dans ses logs

123456Password!

Le 02 mai 2018 à 16h31

3 min

Internet

Plusieurs utilisateurs, dont celui de VeraCrypt, ont reçu un courrier de GitHub les invitant à changer leur mot de passe. En cause, un « bug » provoquant son enregistrement en clair dans les logs de la société. Les risques sont faibles, mais une réinitialisation des mots de passe concernés a été mise en place.

Une des règles de base concernant les mots de passe est de ne stocker qu'une empreinte (hash), comme le rappelait encore récemment la CNIL : « Le mot de passe ne doit jamais être stocké en clair. Lorsque l’authentification a lieu sur un serveur distant, et dans les autres cas si cela est techniquement faisable, le mot de passe doit être transformé au moyen d’une fonction cryptographique non réversible et sûre, intégrant l’utilisation d’un sel ou d’une clé ».

Si dans un monde parfait tout le monde est censé respecter cette règle, des plus basiques rappelons-le, le récent cas des Échos nous rappelle que même en 2018, ce n'est pas toujours le cas. La situation de GitHub est néanmoins différente, même si des mots de passe se sont quand même retrouvés stockés en clair sur ses serveurs.

Pas de fuite de données affirme GitHub

La plateforme a en effet envoyé des e-mails à certains de ses utilisateurs leur demandant de modifier leur mot de passe car, « au cours d'un audit de routine, GitHub a découvert qu'un bug introduit récemment exposait un petit nombre de mots de passe d'utilisateurs à nos logs internes », comme le rapport Bleeping Computer. Ce « bug », pour reprendre la formulation de l'entreprise, se produisait lorsqu'une demande de réinitialisation était lancée par un utilisateur.

Malgré tout, « GitHub stocke les mots de passe des utilisateurs avec des hachages cryptographiques sécurisés (bcrypt) » déclare la société, pour rassurer ses utilisateurs. Elle ajoute que les mots de passe en clair n'étaient accessibles ni au public, ni aux autres utilisateurs de GitHub, ni à la majorité des employés de la société. Néanmoins, « il est très improbable qu'un membre du personnel ait accédé à ces journaux » précise GitHub.

@github asked me to change password. pic.twitter.com/NgRVb2vVCX

— Bobinson K B (@bobinson) 1 mai 2018

Changement de mot de passe obligatoire pour les comptes concernés

Le souci a été corrigé dans la foulée, mais les utilisateurs concernés doivent changer leur mot de passe par mesure de sécurité. « GitHub n'a pas été piraté ou compromis de quelque façon que ce soit » ajoute la société en guise de conclusion.

Parmi les « victimes » se trouve l'outil de chiffrement VeraCrypt (lire nos différents guides). Son développeur, Mounir Idrassi, se veut néanmoins rassurant : « Aucun accès frauduleux au dépôt n'a été trouvé. Nous utilisons une identification à deux facteurs, une clé SSH et la signature GPG pour les commits, le risque est donc faible ».

Nous avons contacté GitHub afin d'avoir de plus amples informations (notamment sur le nombre de personnes concernées et la durée du « bug »), sans réponse pour le moment. Certains de nos confrères américains ont également essayé de contacter la plateforme, également sans succès.

Comme toujours lorsqu'il s'agit de choisir un mot de passe, il est important de respecter certaines règles. Vous pouvez aussi utiliser un gestionnaire pour les retenir à votre place.

Commentaires (37)

ElCroco Abonné

Le 02/05/2018 à 22h49

ouh la ouh la calmons nous ^^’

Un algo est un algo, il peut être  développé dans plus ou moins n’importe quel language. On peut très bien hasher coté client, via javascript (google -> js sha256). Donc, c’est clairement de l’ordre du faisable.

Il est aussi possible de re-hasher une seconde fois coté serveur au besoin :]

Un hash coté client + un second coté serveur, ça permet (si je dis pas trop de bêtise ^^ ) de se protéger mieux si la BDD se fait voler : Un hacker aura le hash(hash(motdepasse). Du coup, il devra bruteforcer 2 fois pour avoir le clair. On peut même hasher 1000x d’affilée hein ^^

Sinon, pour répondre à Gemini_Power :

Gemini_Power a écrit :

Normalement, si je me trompes pas, dans les bonnes pratiques, les mots de passe ne circulent jamais par le réseau (même en SSH).

Théoriquement, il doit être hashé côté client (navigateur) avant d’être envoyé vers le serveur (et peut même être rehashé côté serveur) pour être mis en base. Et pareil lors du login.

Dans les meilleures pratiques oui. Ca permet d’éviter de voir les pass se balader tranquillement sur le réseau en vas de MITM (SSL). Dans la vraie vie, google envoyait le pass en clair il y a encore ²⁄₃ ans (validé via les dev tools, évidemment, j’ai aucune trace donc faut me croire sur parole, libre à toi). Heureusement, ils ont changé leur fusil d’épaule.

Facebook par contre l’envoie bien en clair. Si si. Je viens de vérifier à l’instant.

Attention cependant, quand je dis en clair, je ne parle pas de chiffrement SSL/TLS bien évidemment. Ce sont deux choses totalement séparées (modèle OSI tout ça tout ça). Les risques sont de plus amoindris car les gros sites comme FB utilisent du HSTS, ce qui limite grandement le MITM SSL.

127.0.0.1

Le 03/05/2018 à 00h07

Gemini_Power a écrit :

Théoriquement, il doit être hashé côté client (navigateur) avant d’être envoyé vers le serveur (et peut même être rehashé côté serveur) pour être mis en base. Et pareil lors du login.

Faire un Hash coté client ca ne sert a rien sauf dans le cadre d’un protocole challenge/response. Et même dans ce cas le serveur doit connaitre le mot de passe d’origine (en clair).

Sinon, un hash coté client, c’est juste un password comme un autre = une séquence hexa envoyée par le client au serveur pour authentifier l’utilisateur. Et n’importe quel client qui enverra cette même séquence hexa sera authentifié.

Firefly' Abonné

Le 03/05/2018 à 03h39

Et en fonction du genre de personne que c’est, ( si il trim les 0 ) on peu même enlever toute celles dont une des 6 coordonnées commence par un 0

Et même je commencerais par trier les étoiles par “popularité” pour tester les mdp

flan_ Abonné

Le 03/05/2018 à 04h58

Gemini_Power a écrit :

Question (sincère) quand même:

Comment cela se fait que le site a été capable d’enregistrer un mot de passe clair, même dans un log ?

Normalement, si je me trompes pas, dans les bonnes pratiques, les mots de passe ne circulent jamais par le réseau (même en SSH).

Théoriquement, il doit être hashé côté client (navigateur) avant d’être envoyé vers le serveur (et peut même être rehashé côté serveur) pour être mis en base. Et pareil lors du login.

Le bug aurait été de le transmettre en réseau avant hash vers le serveur (ou passer une copie par le réseau lors de la remise à jour) ?

Hasher le mot de passe n’a aucun intérêt au contraire. Enfin, c’est pire vu que ça tue l’intérêt du hashage. Avec ton idée , si tu récupères le hash, tu peux directement te connecter avec le hash en le fournissant au serveur sans faire l’étape de hash en JS (normal, il est déjà hashé).

En SSH avec mot de passe, c’est pareil mais si c’est de l’authent par clefs le fonctionnement n’a plus rien à voir et il n’y a effectivement plus de transfert de mot de passe.

xxxo

Le 03/05/2018 à 05h52

Hasher un hash c’est une très mauvaise idée généralement, notamment avec certains algorithmes qui ne gèrent pas certains caractètres. La “norme” actuelle c’est bcrypt qui se charge de créer et d’enregistrer le salt et qui est lent ce qui fait que contrairement à un SHA quelconque, vérifier un bcrypt peut prendre un temps assez long (configurable) ce qui fait qu’un hacker potentiel ne pourra pas tester 700 millions de hash par seconde mais seulement 1. Du coup si la bdd est piratée on ne peut que très difficilement trouver des mots de passe.

Ensuite même si c’est possible de hasher côté client généralement c’est SSL qui se charge de sécuriser le mot de passe entre le client et le serveur parce que bah comme dit plus haut le double hachage c’est pas bon et comme on veut que ce qui touche à la sécurité soit géré par le serveur et pas par le client (qui pourrait être malveillant).

On peut trouver plein d’infos sur le net qui expliquent tout ça mieux que moi et avec beaucoup plus de mots et en anglais.

Ricard

Le 03/05/2018 à 06h27

Flykz a écrit :

puisqu’il faut saler le hash, si on sale coté client c’est potentiellement moins sécurisé s’il y a du rétro engineering derrière.

Si des gens ont plus d’infos " />

Perso, pour un hashé, je sale (bien évidement), je poivre et une pointe de Tabasco. Et c’est bien le serveur qui me l’apporte, je suis client après tout" />

Sinon, avec des frites, ou des haricots verts, ça passe bien aussi.

Voilà, c’est les seules infos que j’ai, si j’ai pu t’aider. " />

Ricard

Le 03/05/2018 à 06h31

Firefly’ a écrit :

Et en fonction du genre de personne que c’est, ( si il trim les 0 ) on peu même enlever toute celles dont une des 6 coordonnées commence par un 0

Et même je commencerais par trier les étoiles par “popularité” pour tester les mdp

Sérieux, vous vous faites chier pour rien.

Les étoiles n’existent pas, puisque c’est un complot des réptiliens qui essayent de nous faire croire que la terre est ronde, alors que tout le monde sait bien que la terre est plate." />

Ricard

Le 03/05/2018 à 06h34

xxxo a écrit :

On peut trouver plein d’infos sur le net qui expliquent tout ça mieux que moi et avec beaucoup plus de mots et en anglais.

Donc moins compréhensible. Si tu as en français, je prends.

ErGo_404

Le 03/05/2018 à 07h24

Quand tu hashes tu peux rajouter un sel, qui peut être public mais qui peut tout aussi bien rester privé, ce qui rajoute encore une couche d’obfuscation à ta couche de sécurité forte. Du coup vaut mieux hasher côté serveur. Le MitM n’est quand même pas à la portée de tout le monde quand tu fais du HTTPS bien configuré.

Et par ailleurs le double hash est déconseillé, de même que pour le chiffrement. Sur certains algos, hasher x fois ou chiffrer x fois rend le message plus vulnérable à une attaque que le hasher une seule fois (ou chiffrer une seule fois).

MeowMeow

Le 03/05/2018 à 07h38

Merde, je vais devoir changer mon mot de passe “Miaou1234” en “1234Miaou”.

anagrys Abonné

Le 03/05/2018 à 08h43

Ricard a écrit :

Perso, pour un hashé, je sale (bien évidement), je poivre et une pointe de Tabasco. Et c’est bien le serveur qui me l’apporte, je suis client après tout" />

Sinon, avec des frites, ou des haricots verts, ça passe bien aussi.

Voilà, c’est les seules infos que j’ai, si j’ai pu t’aider. " />

" /> " />

Firefly' Abonné

Le 03/05/2018 à 09h30

l’intérêt d’un sel public est fortement réduit quand même non ? ok ça evite la comparaison avec une bdd de mdp pré hashé mais la regérération de hash avec le sel + dictionaire/bdd ça va assez vite de nos jours

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 03/05/2018 à 09h48

C’est forcément le serveur qui doit hacher, sinon c’est fonctionnellement équivalent à stocker le mot de passe en clair… 

Si le hachage se fait exclusivement au niveau du client :

  1) L’utilisateur tape son password “MDP123”

  2) Le client hache le password vers 0x12345678 et l’envoie au serveur

  3) Le serveur vérifie qu’il y a bien 0x12345678 dans la database

FAIL ! Si un pirate obtient une copie de la database, il peut se logger en envoyant 0x12345678 au serveur sans avoir besoin de connaître “MDP123”.

 

 

 

 

tyrus Abonné

Le 03/05/2018 à 10h16

Il y a le très bon article d’aeris sur le sujethttps://blog.imirhil.fr/2015/10/27/stockage-mot-passe.html si vous voulez savoir comment bien gérer le stockages des mots de passe (ou plus exactement leurs hash)

FunnyD

Le 03/05/2018 à 13h02

Ricard a écrit :

Perso, pour un hashé, je sale (bien évidement), je poivre et une pointe de Tabasco. Et c’est bien le serveur qui me l’apporte, je suis client après tout" />

Sinon, avec des frites, ou des haricots verts, ça passe bien aussi.

Voilà, c’est les seules infos que j’ai, si j’ai pu t’aider. " />

Bienvenue sur RestoInpact

Ricard

Le 03/05/2018 à 13h05

FunnyD a écrit :

Bienvenue sur RestoInpact

Blurp

versgui Abonné

Le 02/05/2018 à 16h37

C’est honorable de prévenir les clients INpactés, combien d’entreprises préfèrent garder ce genre d’erreur sous silence ?

gavroche69 Abonné

Le 02/05/2018 à 16h59

Comment avez vous osé vous servir de mon mot de passe dans votre sous-titre ?

C’est un scandale !! " />

" />

tazvld Abonné

Le 02/05/2018 à 17h17

Utilise un vrai mot de passe comme &aqwézsx ou même pire 1AQW2ZSX, impossible à trouver.

gavroche69 Abonné

Le 02/05/2018 à 17h27

tazvld a écrit :

Utilise un vrai mot de passe comme &aqwézsx ou même pire 1AQW2ZSX, impossible à trouver.

Je vois que Monsieur aime les diagonales… " />

Amabaka Abonné

Le 02/05/2018 à 17h42

Mais c’est bon, on est protégé par l’exception française. Ça ne correspond pas à la diagonale sur un clavier QWERTY " />

Jarodd Abonné

Le 02/05/2018 à 18h41

Ce « bug », pour reprendre la formulation de l’entreprise, se

produisait lorsqu’une demande de réinitialisation était lancée par un

utilisateur.

Ca tombe bien, la plupart des gens conservent le même mot de passe pendant des années, sans jamais le réinitialiser " />

tazvld Abonné

Le 02/05/2018 à 18h44

Soyons fous ! Le petit tour azertyiop^$ est un peut trop droit.

askana

Le 02/05/2018 à 18h53

moi j’ai pris les cordonné dune étoile xxxxxxxxxxxxxxxxxxxxxx    voila le nombre de caractère a trouver 

gavroche69 Abonné

Le 02/05/2018 à 19h20

tazvld a écrit :

Soyons fous ! …

Histoire de mettre les hackers en échec je suppose… " />

anonyme_6d3c8325027b08b8beb8eb7f143f3660

Le 02/05/2018 à 20h09

comme dirait les utilisateurs chez moi “rho les mots de passe, on est pas au fbi”

Gemini_Power Abonné

Le 02/05/2018 à 20h22

Question (sincère) quand même:

Comment cela se fait que le site a été capable d’enregistrer un mot de passe clair, même dans un log ?

Normalement, si je me trompes pas, dans les bonnes pratiques, les mots de passe ne circulent jamais par le réseau (même en SSH).

Théoriquement, il doit être hashé côté client (navigateur) avant d’être envoyé vers le serveur (et peut même être rehashé côté serveur) pour être mis en base. Et pareil lors du login.

Le bug aurait été de le transmettre en réseau avant hash vers le serveur (ou passer une copie par le réseau lors de la remise à jour) ?

Flykz

Le 02/05/2018 à 21h38

Gemini_Power a écrit :

Question (sincère) quand même:

Comment cela se fait que le site a été capable d’enregistrer un mot de passe clair, même dans un log ?

Normalement, si je me trompes pas, dans les bonnes pratiques, les mots de passe ne circulent jamais par le réseau (même en SSH).

Théoriquement, il doit être hashé côté client (navigateur) avant d’être envoyé vers le serveur (et peut même être rehashé côté serveur) pour être mis en base. Et pareil lors du login.

Le bug aurait été de le transmettre en réseau avant hash vers le serveur (ou passer une copie par le réseau lors de la remise à jour) ?

C’est pas spécialement mon domaine de compétences (la sécurité et les algos) mais dans ma tete le hachage se fait coté serveur, pas client, mais je me sens un peu con de pas m’être fait la remarque avant " /> a première vue j’aurais dit que les algos sont pas implémentables en JavaScript et qu’on se repose sur ssl pour éviter les man in the middle.

Par contre non, pas de “re-hachage” coté serveur, c’est haché une fois et pis c’est terminé.

Dans un autre ordre d’idée, puisqu’il faut saler le hash, si on sale coté client c’est potentiellement moins sécurisé s’il y a du rétro engineering derrière.

Si des gens ont plus d’infos " />

127.0.0.1

Le 02/05/2018 à 21h59

askana a écrit :

moi j’ai pris les cordonné dune étoile xxxxxxxxxxxxxxxxxxxxxx voila le nombre de caractère a trouver

Cool, 12 caractères… donc surement RA+DE d’une étoile proche.

Et c’est parti… !!!!

Geolim4

Le 02/05/2018 à 22h17

versgui a écrit :

C’est honorable de prévenir les clients INpactés, combien d’entreprises préfèrent garder ce genre d’erreur sous silence ?

C’est ce que je me suis dis aussi, j’ai toujours admiré leur transparence (Bug Bounty) au même titre qu’OVH…

Gilbert_Gosseyn Abonné

Le 03/05/2018 à 15h29

" />

slasher-fun

Le 03/05/2018 à 20h31

Tiens, Twitter a eu exactement le même problème…

Twitter

Geolim4

Le 03/05/2018 à 21h40

slasher-fun a écrit :

Tiens, Twitter a eu exactement le même problème…

TwitterYep idem:

TwitterSacré coïncidence quand même ??

ForceRouge Abonné

Le 04/05/2018 à 07h05

127.0.0.1 a écrit :

Faire un Hash coté client ca ne sert a rien sauf dans le cadre d’un protocole challenge/response. Et même dans ce cas le serveur doit connaitre le mot de passe d’origine (en clair).

Sinon, un hash coté client, c’est juste un password comme un autre = une séquence hexa envoyée par le client au serveur pour authentifier l’utilisateur. Et n’importe quel client qui enverra cette même séquence hexa sera authentifié.

Bien sûre que ça sert à quelque chose de faire un hash client et hash serveur.

Effectivement un hackeur n’aura qu’à reverse le hash côté serveur.

Mais ça permet à l’entreprise qui gère le serveur de se dédouaner complètement du vol de mot de passe d’origine puisqu’elle ne le verra jamais. Donc même en cas de bug ou de malhonnêteté des admin qui gère les log, le mot de passe d’origine sera protégé

Flykz

Le 04/05/2018 à 21h48

Merci pour vos réponses " />

Y’en a des belles " />

Cashiderme

Le 05/05/2018 à 00h53

ForceRouge a écrit :

Bien sûre que ça sert à quelque chose de faire un hash client et hash serveur.

Effectivement un hackeur n’aura qu’à reverse le hash côté serveur.

Mais ça permet à l’entreprise qui gère le serveur de se dédouaner complètement du vol de mot de passe d’origine puisqu’elle ne le verra jamais. Donc même en cas de bug ou de malhonnêteté des admin qui gère les log, le mot de passe d’origine sera protégé

Le mot de passe d’origine ne sert plus à rien, puisqu’il est remplacé par le hash depuis le client. Ça dédouane de rien du tout. Sauf subtilités de l’infrastructure qui m’échappent.

ForceRouge Abonné

Le 05/05/2018 à 08h10

Cashiderme a écrit :

Le mot de passe d’origine ne sert plus à rien, puisqu’il est remplacé par le hash depuis le client. Ça dédouane de rien du tout. Sauf subtilités de l’infrastructure qui m’échappent.

La grande majorité des gens utilise le même mot de passe partout. L’objectif, c’est qu’on ne puisse pas connaître le mot de passe d’origine pour l’utiliser sur d’autre site. Dans le cas de github de cette news, avec le double hash, uniquement les comptes sur github se serait fait troué. La tu peux être sure qu’une bonne partie des mots de passe trouvés dans les logs fonctionnent sur la boite mail associé au compte.

Un exemple:

Mon mot de passe que j’utilise sur plusieurs site:

— Nu1t6uDjKFc5rgwt

Le hash (sha1sum tout con) de mon mot de passe calculé coté client:

— 9cf95dacd226dcf43da376cdb6cbba7035218921

Le hash du hash de mon mot de passe enregistré coté serveur:

— f2d498468a98439a911c4b3a9e486f6c072d77fc

Le seul truc qui transitera à chaque login, pouvant être snifé, ou stocké dans des logs coté serveur, c’est 9cf95dacd226dcf43da376cdb6cbba7035218921. Tu ne pourras pas retrouvé mon mot de passe d’origine, et donc l’attaque sera restreinte à github uniquement.

De plus, je peux toujours prouver qu’un compte m’appartient avec mon mot de passe d’origine. Chose que le possesseur des hash ne pourra pas faire.

Donc, oui, ce n’est pas la solution ultime, mais ça ne sert pas à rien.