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.
- Mots de passe : on vous aide à choisir le gestionnaire qu'il vous faut
- Choisir un bon mot de passe : les règles à connaître, les pièges à éviter
Commentaires (38)
#1
C’est honorable de prévenir les clients INpactés, combien d’entreprises préfèrent garder ce genre d’erreur sous silence ?
#2
Comment avez vous osé vous servir de mon mot de passe dans votre sous-titre ?
" />
" />
C’est un scandale !!
#3
Utilise un vrai mot de passe comme &aqwézsx ou même pire 1AQW2ZSX, impossible à trouver.
#4
#5
Mais c’est bon, on est protégé par l’exception française. Ça ne correspond pas à la diagonale sur un clavier QWERTY
" />
#6
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
#7
Soyons fous ! Le petit tour azertyiop^$ est un peut trop droit.
#8
moi j’ai pris les cordonné dune étoile xxxxxxxxxxxxxxxxxxxxxx voila le nombre de caractère a trouver
#9
#10
comme dirait les utilisateurs chez moi “rho les mots de passe, on est pas au fbi”
#11
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) ?
#12
#13
#14
#15
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 :
#16
#17
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
#18
#19
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.
#20
#21
#22
#23
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).
#24
Merde, je vais devoir changer mon mot de passe “Miaou1234” en “1234Miaou”.
#25
#26
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
#27
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”.
#28
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)
#29
#30
#31
#32
Tiens, Twitter a eu exactement le même problème…
https://twitter.com/TwitterSupport/status/992132808192634881
#33
#34
#35
Merci pour vos réponses 
" />
" />
Y’en a des belles
#36
#37