Facebook a stocké en clair des mots de passe de « centaines de millions d'utilisateurs »

Facebook a stocké en clair des mots de passe de « centaines de millions d’utilisateurs »

Et des dizaines de milliers pour Instagram

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

22/03/2019 6 minutes
70

Facebook a stocké en clair des mots de passe de « centaines de millions d'utilisateurs »

Facebook avait sur ses serveurs les mots de passe en clair de centaines de millions d'utilisateurs. Le réseau social se veut rassurant : ils n'étaient pas accessibles de l'extérieur. Selon le spécialiste Brian Krebs, plus de 20 000 employés de Facebook pouvaient tout de même y accéder. 

Depuis des années, les failles de sécurité sont monnaie courante, avec des causes et conséquences plus ou moins graves selon les cas. Facebook vient de définir un nouveau record : « dans le cadre d'un examen de sécurité de routine en janvier, nous avons constaté que certains mots de passe d'utilisateurs étaient enregistrés de manière lisible dans nos serveurs internes », explique la société. C'est évidemment contraire aux règles de sécurité. 

Hasard ou non, ce communiqué officiel a été publié à 16h28, soit 11 minutes seulement après un billet du spécialiste en sécurité Brian Krebs où il dévoilait justement cette sombre histoire. Si la version officielle reste très sommaire, le chercheur donne plus de détails.

Les utilisateurs de Facebook et Instagram touchés

« Ne jamais stocker le mot de passe en clair » est une mesure de sécurité élémentaire selon la CNIL : « 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é ».

Le réseau social tente de limiter la casse : les mots de passe n'étaient pas accessibles par des personnes extérieures à Facebook. Il affirme également n'avoir à ce jour aucune preuve que des personnes internes auraient abusé ou utilisé à mauvais escient ces informations. Une enquête est toujours en cours. 

Bien évidemment, ce défaut de sécurisation a été corrigé et les utilisateurs concernés vont être contactés. Aucune campagne de réinitialisation des mots de passe n'est prévue pour l'instant. L'ampleur des dégâts a par contre de quoi laisser perplexe : « Nous estimons que nous allons notifier des centaines de millions d'utilisateurs de Facebook Lite, des dizaines de millions d'autres versions de Facebook et des dizaines de milliers d'utilisateurs Instagram ».

La société de Mark Zuckerberg en a profité pour examiner la manière dont sont stockées d'autres données, notamment les jetons d'identification, en procédant à des correctifs lorsque cela était nécessaire. Nous n'avons pas plus de détails sur ce point. 

Dans tous les cas, Facebook ne précise pas comment – et depuis quand – des centaines de millions de mots de passe en clair se sont retrouvés sur ses serveurs.

20 000 employés Facebook auraient eu accès aux mots de passe 

Sur son blog, Brian Krebs donne bien plus de détails. Tout d'abord, les premiers mots de passe enregistrés en clair remonteraient à 2012 et 200 à 600 millions d'utilisateurs seraient concernés. Plus de 20 000 employés de Facebook auraient eu la possibilité d'y accéder.

Selon une source interne participant à l'enquête, les journaux indiqueraient qu'environ 2 000 ingénieurs ou développeurs auraient effectué près de neuf millions de requêtes sur des jeux de données contenant les mots de passe en clair. 

Dans une interview accordée à Brian Krebs, Scott Renfro, ingénieur logiciel chez Facebook, explique que sa société ne souhaite pour l'instant pas communiquer sur des chiffres précis. Il confirme qu'une campagne de réinitialisation des mots de passe n'est pas à l'ordre du jour, car ils ont été enregistrés « par inadvertance » et qu'il n'y a « aucun risque réel ». C'est probablement aussi une manière de limiter la panique chez les utilisateurs et de tenter de minimiser ce manque flagrant de sécurité. Dans tous les cas, vous pouvez toujours le faire de manière préventive. 

Quand Facebook assure la promotion du chiffrement et de la sécurité

Dans son billet de blog, Facebook rappelle ensuite qu'il connait parfaitement les pratiques élémentaires de sécurité. Les mots de passe sont normalement hachés, salés et la fonction de dérivation de clé scrypt est utilisée. Le spécialiste Stéphane Bortzmeyer revient sur le fonctionnement de cette dernière dans ce billet de blog.

Comme pour faire tenter d'oublier qu'il a enregistré des millions de mots de passe en clair dans ses bases de données, Facebook détaille les différentes couches de sécurités mises en place : détection d'activité suspecte, envoi d'alerte en cas de connexions non reconnues, vérification des identifiants ayant fuité sur Internet pour trouver des correspondances avec des comptes et enfin la double authentification (SMS, application, clés U2F). Si ce n'est pas déjà fait, c'est surement une bonne idée d'activer cette dernière fonctionnalité.

Pour rappel, nous avons publié il y a quelque temps un guide sur le choix d'un bon mot de passe et d'un gestionnaire, avec des tests de plusieurs d'entre eux :

Un cas pas isolé, mais d'une ampleur inédite

D'autres sociétés ont connu des problèmes similaires, notamment Twitter et GitHub au cours de l'année dernière. Dans les deux cas, les mots de passe en clair étaient enregistrés par mégarde dans les logs des serveurs à cause d'un « bug ». Mais aucun des deux n'arrive à la cheville de Facebook, ni en quantité (plusieurs centaines de millions) ni en durée (depuis 2012). 

Par contre, comme nous avons pu le voir avec les Échos en avril dernier (corrigé depuis) certains stockent encore par défaut des mots de passe en clair dans leur base de données. Si vous êtes confrontés à ce genre de mauvaise pratique – par exemple si le mot de passe est renvoyé par email en cas d'oubli – nous avons mis en place une adresse email dédiée pour que vous puissiez nous en informer :

[email protected]

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les utilisateurs de Facebook et Instagram touchés

20 000 employés Facebook auraient eu accès aux mots de passe 

Quand Facebook assure la promotion du chiffrement et de la sécurité

Un cas pas isolé, mais d'une ampleur inédite

Commentaires (70)


Ce qui est fou c’est qu’il y à aucune moulinette qui vérifie chaque jours sur les mots de passe dans la bdd ne “pings” pas avec des mots commun piochés dans un simple dictionnaire. Après je suppose que pouvoir récupérer les mot de passe doivent être très restreint au niveau employés. Par contre quand je vois le “caca” ( j’ai pas dis que c’est mieux ailleurs ) qu’est facebook sur plein de choses, j’ai du mal à comprendre ce que font actuellement les 45.000 employés qui bossent pour eux.


Ce que tu dis ne m’étonne pas, ça ne me viendrait pas à l’idée de stocker des mots de passe en clair et donc ça ne me viendrait pas à l’idée de vérifier régulièrement qu’ils le sont.

Je ne comprends même pas comment c’est possible qu’ils ne se soient pas rendu compte de ça avant, en travaillant sur leur code …


Avec un bon salaire, les gens sont prêt à faire n’importe quoi.








ErGo_404 a écrit :



Ce que tu dis ne m’étonne pas, ça ne me viendrait pas à l’idée de stocker des mots de passe en clair et donc ça ne me viendrait pas à l’idée de vérifier régulièrement qu’ils le sont. Je ne comprends même pas comment c’est possible qu’ils ne se soient pas rendu compte de ça avant, en travaillant sur leur code … 





 Je comprend tout à fait comment ce genre de chose peut apparaitre. Quand tu développe un système, parfois tu stocke les mot de passe en clair dans une table ou une cellule pour faire des tests. Ensuite tu hésite à virer le truc ou non et un jours quelqu’un coche la mauvaise case ou écrit le mauvaise bout de code et ça ce réactive.



C’est surement la crème qui dois bosser sur leur bdd, après ça reste quand même bien chiant à manipuler et plus t’a d’utilisateur plus ça deviens critique. Je suppose que la plupart des mecs qui doivent toucher à la bdd ça ce fait surement uniquement par du code avec de grosse restriction. A ce niveau je suis même pas sur qu’il y à une interface graphique. Si t’a que 10% des personnes touchées et que c’est arrivé à une période bien précise, même avec un accès complet c’est un coup de bol si tu vois un passe défiler en consultant la bdd.



Pour résumer, c’est le genre de bug spécifique ou si tu ne le cherche pas tu est quasiment sur de ne jamais le trouver et ou peut de gens ont la possibilité de faire une recherche.



Après il est possible que ça sois un bug volontairement introduit pour récupérer un paquet d’information pour profiler les gens encore plus précisément, ou alors tout simplement les revendre.



Mais quand le code qui vérifie le mot de passe est exécuté, on pourrait imaginer que ça soit le même code pour tout le monde et donc, qu’il échoue sur les mots de passe en clair (si les autres sont hashés).

Mais j’imagine que leur base de code est un poil plus complexe et qu’ils gèrent plusieurs formes de hash selon les époques et donc qu’ils gèrent aussi les versions non hashées.


La sécurité n’est pas leur business, donc personnellement ça ne me choque pas qu’ils n’y aient pas fait attention pendant un temps. Il faut régulièrement se battre pour tester que les trucs “pas possibles” ne sont effectivement pas possibles, et ça prend du temps et de l’argent.


Comme quoi ils ont raison de faire un audit <img data-src=" />



Maintenant quand tu vois que leur stack technique et leurs pratiques sert de référence à tous les branleurs fans d’agile de conférences devops et autres architectes branchés qui se la pètent à expliquer la vie à l’industrie tu te dis que la maintenance logicielle a de beaux jours devant elle <img data-src=" />



Eux et netflix <img data-src=" />


Non, l’ensemble des développeurs étant passé sur un code qui stocke en clair des infos d’identifications sans avoir averti devraient prendre la porte immédiatement.

Il y a un minimum tout de même <img data-src=" />



Et une boite web par définition est aussi dans le business de la sécurité, de gré ou de force.


je crois que la référence côté stack technique c’est plutôt Amazon. Et effectivement Netflix pour l’agile, même s’ils sont très, très loin dans le domaine.

(et d’ailleurs, ils tournent sur Amazon…)








skankhunt42 a écrit :



Je comprend tout à fait comment ce genre de chose peut apparaitre. Quand tu développe un système, parfois tu stocke les mot de passe en clair dans une table ou une cellule pour faire des tests. Ensuite tu hésite à virer le truc ou non et un jours quelqu’un coche la mauvaise case ou écrit le mauvaise bout de code et ça ce réactive.



C’est surement la crème qui dois bosser sur leur bdd, après ça reste quand même bien chiant à manipuler et plus t’a d’utilisateur plus ça deviens critique. Je suppose que la plupart des mecs qui doivent toucher à la bdd ça ce fait surement uniquement par du code avec de grosse restriction. A ce niveau je suis même pas sur qu’il y à une interface graphique. Si t’a que 10% des personnes touchées et que c’est arrivé à une période bien précise, même avec un accès complet c’est un coup de bol si tu vois un passe défiler en consultant la bdd.



Pour résumer, c’est le genre de bug spécifique ou si tu ne le cherche pas tu est quasiment sur de ne jamais le trouver et ou peut de gens ont la possibilité de faire une recherche.



Après il est possible que ça sois un bug volontairement introduit pour récupérer un paquet d’information pour profiler les gens encore plus précisément, ou alors tout simplement les revendre.







Mouais, enfin si le but c’est de controler la bonne saisie d’un password, une simple fonction de crc32 et stockage du resultat suffit pour qu’il y ait un minimum de securité, du moins pour eviter de garder le pwd sous le coude.

c’est le b a-ba d’une connexion, apres on colle des fonctions plus complexes, du sel, etc.

A la limite dans la premiere version de facebook, sur le campus, on aurait pu imaginer que les mecs qui ont codé ca rapidos puissent laisser des trous de secu comme ca. Mais a partir du moment ou c’est devenu une entreprise, il est evident que tout a ete reecrit propre et je ne comprends pas comment les nouveaux devs aient pu laisser passer ca.



<img data-src=" /> <img data-src=" />


La sécurité, c’est le business de toute entreprise dont le modèle économique repose sur la collecte massive de données privées.


Encore un coup d’un stagiaire ? <img data-src=" />








sergekaramazov a écrit :



La sécurité, c’est le business de toute entreprise dont le modèle économique repose sur la collecte massive de données privées.



La sécurité, c’est le business de toute entreprise dont le modèle économique a un besoin massif de l’informatique.



  &nbsp;<img data-src=">  



(formulation plus claire, vu que la mise en forme ne semble pas fonctionner)



Tu ne peux pas faire de moulinette de ce type puisque normalement tu stockes les mots de passe hachés et salés. Sauf à rehacher /saler chacun des mots de la liste à chaque fois, ce qui demandrait trop de ressources processeur, où à stocker la base hachée et salée pour chaque utilisateur, ce qui demanderait trop d’espace disque. C’est un peu le principe du hachage salage pour qu’un pirate qui aurait récupéré la base de données ne puisse pas le faire en temps raisonnable justement <img data-src=" />

Dans le cas de facebook j’ai cru comprendre le stockage n’est d’ailleurs pas dans la BDD elle-même mais plutôt dans des fichiers annexes type logfiles.








ErGo_404 a écrit :



Mais quand le code qui vérifie le mot de passe est exécuté, on pourrait imaginer que ça soit le même code pour tout le monde et donc, qu’il échoue sur les mots de passe en clair (si les autres sont hashés).





Si le mot de passe en clair est aussi long qu’un hash alors il sera enregistré.

&nbsp;





momal a écrit :



A la limite dans la premiere version de facebook, sur le campus, on aurait pu imaginer que les mecs qui ont codé ca rapidos puissent laisser des trous de secu comme ca. Mais a partir du moment ou c’est devenu une entreprise, il est evident que tout a ete reecrit propre et je ne comprends pas comment les nouveaux devs aient pu laisser passer ca.&nbsp;





Et combien de temps entre la version campus et la version sécurisée ? Quand au nouveaux devs, tout dépend du nombre et de leur accréditation. J’ai certains potes ils doivent signer un formulaire en trois exemplaires pour ouvrir quelques fichier textes et peut être en modifier un par la suite, avec une belle doc de 10 pages et deux semaines d’attente pour un déploiement.



Je suppose que sur une boite comme facebook il y à des warning si tu cherche trop dans les fichier, surtout les bases de données et encore plus les mots de passes.



Et tout le monde cri au loup : “c’est des noob chez facebook”.



Sauf que:

&nbsp;

&nbsp;Y’a peu de gens qui font ce qu’ils font et plus d’un ici n’en est pas capable. Donc voila pour les commentaires de ce genre issus du poullailler.



C’est devenu monnaie courante ces problèmes. Bien malheureusement.



&nbsp;Quand on voit la problématique du libre ou tout le monde peut relire le code mais que pas grand monde le fait. Quid de Npm/NodeJs ? Il y a plus d’un religieux du Js qui l’a bien fermé et qui a plus ou moins pissé dans son froc ce jour là. Ou encore SCP qui récemment a probablement du décrocher le record de longévité de présence d’une faille.

&nbsp;

&nbsp;Quand on voit la problématique entrepreneuriale du “pas le temps de niaiser”. On finit toujours par faire un truc à l’arrache et ça finit mal. Comme toujours.



Donc voila c’est pas que chez FB. Du bug et de la faille il y en a des tas dans un tas de logiciels. Suiffit de regarder les traqueur de bug des dites suite logicielles.

&nbsp;

&nbsp;Ces facteurs principaux devraient forcer a repenser les modèles de production/developpement… ce ne sera pas le cas. Et dans un mois peut-être on aura un autre sujet du genre; et le poulailler cocotera de plus belle.

&nbsp;

&nbsp;


Ca veut dire que personne chez Facebook ne regarde les logs depuis 2012 ?

<img data-src=" />


Ce qui m’étonne le plus dans la news, c’est que 20000 employés auraient eu accès aux mots de passe.








Poppu78 a écrit :



Dans le cas de facebook j’ai cru comprendre le stockage n’est d’ailleurs pas dans la BDD elle-même mais plutôt dans des fichiers annexes type logfiles.





Je suis fatigué de ce genre de pinaillage qui mène à nul part… Bdd au sens large sachant que tout aussi est stocké dans des fichiers.









TexMex a écrit :



Et tout le monde cri au loup : “c’est des noob chez facebook”.



Sauf que:

&nbsp;

&nbsp;Y’a peu de gens qui font ce qu’ils font et plus d’un ici n’en est pas capable. Donc voila pour les commentaires de ce genre issus du poullailler.



C’est devenu monnaie courante ces problèmes. Bien malheureusement.



&nbsp;Quand on voit la problématique du libre ou tout le monde peut relire le code mais que pas grand monde le fait. Quid de Npm/NodeJs ? Il y a plus d’un religieux du Js qui l’a bien fermé et qui a plus ou moins pissé dans son froc ce jour là. Ou encore SCP qui récemment a probablement du décrocher le record de longévité de présence d’une faille.

&nbsp;

&nbsp;Quand on voit la problématique entrepreneuriale du “pas le temps de niaiser”. On finit toujours par faire un truc à l’arrache et ça finit mal. Comme toujours.



Donc voila c’est pas que chez FB. Du bug et de la faille il y en a des tas dans un tas de logiciels. Suiffit de regarder les traqueur de bug des dites suite logicielles.

&nbsp;

&nbsp;Ces facteurs principaux devraient forcer a repenser les modèles de production/developpement… ce ne sera pas le cas. Et dans un mois peut-être on aura un autre sujet du genre; et le poulailler cocotera de plus belle.

&nbsp;

&nbsp;





Alors ça c’est de l’argumentation en béton!!!!!



Stocker les mots de passe en clair, c’est un gros fail. C’est tout. Et peu importe ce que fait facebook! C’est pareil pour tout le monde, tous les sites.



Sinon y a l’API&nbsp;haveibeenpwned.com qui permet de tester les mots de passes compromis, je pense que c’est pas mal pour vérifier la sécurié.


Petit abus de language selon moi, qui me fait penser que certains cherchent le sensationnalisme.

“Stocker” me fait penser qu’ils ont étés enregistrés dans le but d’être exploité tel quels. “Sauvegardé” me parait plus correct, ils ont été enregistré par inadvertance dans un flux de donné qui se trouvaient contenir les mots de passe mais le but n’était pas de les exploiter.



Bref, je ne suis absolument pas pro Facebook, mais y’a un moment on pourrait prendre tout ça pour de la mauvaise foi…








jojofoufou a écrit :



Petit abus de language selon moi, qui me fait penser que certains cherchent le sensationnalisme.

“Stocker” me fait penser qu’ils ont étés enregistrés dans le but d’être exploité tel quels. “Sauvegardé” me parait plus correct, ils ont été enregistré par inadvertance dans un flux de donné qui se trouvaient contenir les mots de passe mais le but n’était pas de les exploiter.



Bref, je ne suis absolument pas pro Facebook, mais y’a un moment on pourrait prendre tout ça pour de la mauvaise foi…





<img data-src=" />

&nbsp;

les mots de passe ne sont pas “enregistrés par inadvertance”. Si un site ne stocke pas ton mot de passe, bah tu n’auras tout simplement pas accès au site en question!

Après stockage vs sauvegarde : pour moi la sauvegarde est une copie de l’exemplaire de stockage. Mais on s’en fou un peu.

&nbsp;









jeje07bis a écrit :



Alors ça c’est de l’argumentation en béton!!!!!



Stocker les mots de passe en clair, c’est un gros fail. C’est tout. Et peu importe ce que fait facebook! C’est pareil pour tout le monde, tous les sites.





Qui a dit le contraire?

Il faut LIRE attentivement pour trouver mon propos qui englobe bien plus de chose que FB.









TexMex a écrit :



Et tout le monde cri au loup : “c’est des noob chez facebook”.



Sauf que:

 

 Y’a peu de gens qui font ce qu’ils font et plus d’un ici n’en est pas capable. Donc voila pour les commentaires de ce genre issus du poullailler.



C’est devenu monnaie courante ces problèmes. Bien malheureusement.



 Quand on voit la problématique du libre ou tout le monde peut relire le code mais que pas grand monde le fait. Quid de Npm/NodeJs ? Il y a plus d’un religieux du Js qui l’a bien fermé et qui a plus ou moins pissé dans son froc ce jour là. Ou encore SCP qui récemment a probablement du décrocher le record de longévité de présence d’une faille.

 

 Quand on voit la problématique entrepreneuriale du “pas le temps de niaiser”. On finit toujours par faire un truc à l’arrache et ça finit mal. Comme toujours.



Donc voila c’est pas que chez FB. Du bug et de la faille il y en a des tas dans un tas de logiciels. Suiffit de regarder les traqueur de bug des dites suite logicielles.

 

 Ces facteurs principaux devraient forcer a repenser les modèles de production/developpement… ce ne sera pas le cas. Et dans un mois peut-être on aura un autre sujet du genre; et le poulailler cocotera de plus belle.





Non.



Stocker les mots de passe en clair c’est même pas une erreur de débutant. Même quand je faisais du code quand j’étais ado je faisais pas ça. Stocker des mots de passe hachés c’est juste :




  • très facile et à la portée de n’importe quel dev débutant (donc l’excuse de faire à l’arrache ne tient pas)

  • le comportement par défaut (et jamais désactivable) de n’importe quel framework

  • un truc que t’apprends au pire en première année d’études info



    Ya que deux options pour que des mdp se retrouvent en clair :

  • du code écrit par des non devs (ce dont je doute un peu chez FB)

  • une action volontaire



    Quand aux 9 millions de requêtes effectuées par 2000 ingés qui sont mentionnés dans l’article, c’est impossible statistiquement que :

  • aucun dev honnête n’aie remonté le problème

  • aucun dev malhonnête n’aie dumpé le tout sur une clé USB.



Très largement dans le domaine de la maintenance de SI, une fois accrédité tu as accès à tout.

Quand je faisais de la maintenance du SI d’un opérateur telco j’avais accès à l’ensemble des données personnelles de dizaines de millions&nbsp; de clients ( Adresse / Date de naissance, Données bancaires, ….). Et l’accès à la base tous les sous traitants et employés de l’opérateur y avait accès ( Soit directement via SQL soit via webServices).

&nbsp;

&nbsp;

&nbsp;


Les mots de passe étaient a priori contenu dans des fichiers de logs, et la finalité n’était pas d’authentifier les utilisateurs en utilisant ces donnés.



les mots de passe utilisateurs étant eux stockés hashés

&nbsp;


Déjà difficile à admettre s’agissant d’une petite boite alors qu’à mon échelle de total amateur je respecte ce béaba y compris s’agissant des logs, alors venant d’une boite comme facebook, là on touche le fond aussi bien pour le manquement en lui-même que s’agissant de la durée <img data-src=" />


Justement,&nbsp;


Lire commentaire #25



Mais b; vous lisez un peu ?

&nbsp;

J’ajouterai à mon commentaire initial (#17) :

Le plus beau est que plus d’un se sent pousser des ballz d’expert en sécurité alors que les détails du désordre ne sont pas bien connus ou connus tout court. Si ce n’est de la part des communicants d’un coté ou de ce qui filtre du coté des véritables expert en sécurité. Bref savoir toute la vérité la dessus sera encore bien difficile. Et il y a fort à parier que ce phénomène (et son origine) est la résultante d’un concourt de circonstances décrites plus haut.



Vous consultez à combien les kikis ? Peut-être que FB pourrait débloquer une ligne budgétaire pour améliorer la sécurité en consultant les avis des commentateurs sur NextInpact. 300€ de l’heure ?

&nbsp;







&nbsp;


C’est la théorie, je répond sur le côté pratique :)

Je serais pas surpris qu’en fouillant leurs archives il y ait un mail qui pointe le problème et qui a été oublié dans un coin.&nbsp;


Arf, edit trop tard :(



Je disais, les équipes chez Facebook fonctionnent comme de petites entreprises,&nbsp; avec chacune leurs objectifs, leurs besoins…



J’imagine dans ce cas qu’une équipe qui bossait sur la version web mobile a simplement eu besoin de logger les requêtes, elle à utilisé le produit d’une autre équipe en l’utilisant de manière incorrecte, ce qui a fait que des informations sensibles ce sont retrouvés non obfusqués dans ces fichiers de logs


En stage depuis 2012 ? <img data-src=" />








jeje07bis a écrit :



<img data-src=" />

&nbsp;

les mots de passe ne sont pas “enregistrés par inadvertance”. Si un site ne stocke pas ton mot de passe, bah tu n’auras tout simplement pas accès au site en question!

Après stockage vs sauvegarde : pour moi la sauvegarde est une copie de l’exemplaire de stockage. Mais on s’en fou un peu.

&nbsp;





Euh je suis pas certain de saisir ta nuance, en aucun cas le site n’a besoin de stocker ton mot de passe, ta fonction traite uniquement le mot de passe pour le saler et le hasher et comparer dans la db ce hash.

Ou alors tu veux parler du bref instant où le mot de passe est transmis, chose que l’on peut limiter en utilisant javascript (jquery ou autre) pour faire un hash depuis le client et envoyé uniquement ce hash (certes désactivable, mais pourquoi le client prendrait la peine de se démunir volontairement).









jojofoufou a écrit :



Les mots de passe étaient a priori contenu dans des fichiers de logs, et la finalité n’était pas d’authentifier les utilisateurs en utilisant ces donnés.



les mots de passe utilisateurs étant eux stockés hashés

&nbsp;





Il y a quelques années j’avais eu le cas sur un vieux Windows: quand on tentait de se connecter au FTP, si l’authentification ratait, dans le log FTP on voyait: tentative de connexion: login xxxx mot de passe yyyyyy …

donc on avait les mots de passe que tentaient les gens. Et donc souvent les mots de passe des autres systèmes.



Et on ne l’avait jamais voulu.



oui enfin, par essence, FTP transmet tout en clair <img data-src=" />








brice.wernet a écrit :



Il y a quelques années j’avais eu le cas sur un vieux Windows: quand on tentait de se connecter au FTP, si l’authentification ratait, dans le log FTP on voyait: tentative de connexion: login xxxx mot de passe yyyyyy …

donc on avait les mots de passe que tentaient les gens. Et donc souvent les mots de passe des autres systèmes.



Et on ne l’avait jamais voulu.





Oui mais comme tu le rapportes tu avais lu tes logs, alors d’accord tu fais généralement pas une lecture détaillée tous les jours, mais j’imagine que pour FB ça reste néanmoins faisable d’au moins échantillonner régulièrement.



Perso c’est comme ça que j’ai vu que dans mon log y avait mon pass en clair parce que j’avais mal bricolé mon script et paramétré mon serveur.









TexMex a écrit :



Et tout le monde cri au loup : “c’est des noob chez facebook”.



Sauf que:

&nbsp;

&nbsp;Y’a peu de gens qui font ce qu’ils font et plus d’un ici n’en est pas capable. Donc voila pour les commentaires de ce genre issus du poullailler.



&nbsp;

&nbsp;





Le problème ici n’est pas de prouver qu’on fait mieux ou autre chose, c’est juste de se demander comment un site regroupant des milliards de comptes a fait une erreur… de débutant ? LE be à ba de la sécurité informatique.



Ça a beau être une entreprise valorisée pas loin des 500 milliards de dollars, ça reste des humains, et les humains font des erreurs :p


C’est quand même une boulette énorme et qui est très étonnante d’une boîte comme Facebook.

Je les porte pas dans mon coeur et pourtant, il faut bien avouer qu’ils ont tout un tas de cadors au dev…

La seule explication possible : un manque total de gouvernance (c’est sans doute un gros mot dans le monde des internets innovants ;)). Chaque équipe doit opérer indépendamment, et du coup il suffit d’un mouton noir pour en arriver là…



Mais le plus étonnant pour moi, c’est qu’ils ne lancent pas une campagne de réinitalisation de mots de passe.

En plus avec Facebook Login, ça pourrait avoir des impacts sur plein de sites, je suppose (?).

A mon avis ils vont devoir revenir en arrière là-dessus.








jojofoufou a écrit :



Ça a beau être une entreprise valorisée pas loin des 500 milliards de dollars, ça reste des humains, et les humains font des erreurs :p





Certes, mais zapper pendant 7 ans les pass dans les logs faut vraiment être distrait …



Fichtre, j’utilise justement les apps “Lite” sur mon tel … je n’ai encore rien reçu, j’espère que je suis passé entre les mailles du filet <img data-src=" />

&nbsp;







NXI a écrit :



Et personne ne s’en est rendu compte ? o_O

Ou alors ils ont ont fait remonter et + haut ils s’en foutent ?









skankhunt42 a écrit :



Ce qui est fou c’est qu’il y à aucune moulinette qui vérifie chaque jours sur les mots de passe dans la bdd ne “pings” pas avec des mots commun piochés dans un simple dictionnaire. Après je suppose que pouvoir récupérer les mot de passe doivent être très restreint au niveau employés. Par contre quand je vois le “caca” ( j’ai pas dis que c’est mieux ailleurs ) qu’est facebook sur plein de choses, j’ai du mal à comprendre ce que font actuellement les 45.000 employés qui bossent pour eux.







Les 45000 employés vérifient ce qui est vraiment important : “pas de néné ni de quéquette dans les post” <img data-src=" />





Il affirme également n’avoir à ce jour aucune preuve que des personnes internes auraient abusé ou utilisé à mauvais escient ces informations.



Ce qui me choque dans cette affirmation, c’est quelle sous-entend qu’il pourrait y avoir une utilisation à bon escient des mots de passe en clair.

Pourquoi n’ont-ils pas simplement dit “utilisé” tout court ?


Ça dépend comment sont utilisé les logs.

Je ne connais pas le détail, mais la façon dont c’est présenté peut laisser penser qu’il s’agit d’une base de logs mise à disposition des ingés, probablement pour faire des tests divers. Si c’est le cas c’est pas très étonnant qu’elle ne fasse pas l’objet de revues, c’est les logs de prod qui sont surveillés.

Et selon la façon dont les devs y accèdent, la présence du mdp n’est pas forcément évidente (par exemple si tu y accèdes via un système de requêtes, tu ne le verras pas les mots de passe sauf à les chercher spécifiquement)



Par contre le fait qu’aucun ne l’ai vu en 7 ans… c’est effectivement difficile à croire.








Zerdligham a écrit :



Ça dépend comment sont utilisé les logs.

Je ne connais pas le détail, mais la façon dont c’est présenté peut laisser penser qu’il s’agit d’une base de logs mise à disposition des ingés, probablement pour faire des tests divers. Si c’est le cas c’est pas très étonnant qu’elle ne fasse pas l’objet de revues, c’est les logs de prod qui sont surveillés.

Et selon la façon dont les devs y accèdent, la présence du mdp n’est pas forcément évidente (par exemple si tu y accèdes via un système de requêtes, tu ne le verras pas les mots de passe sauf à les chercher spécifiquement)



Par contre le fait qu’aucun ne l’ai vu en 7 ans… c’est effectivement difficile à croire.





Je le comprends ainsi aussi, néanmoins on est d’accord 7 ans sans rien voir c’est vraiment de la négligence





Plus de 20 000 employés de Facebook auraient eu la possibilité d’y accéder.





Plus quelques centaines à la NSA.








Ricard a écrit :



Plus quelques centaines à la NSA.





Ca à mon avis on peut le conjuguer au présent <img data-src=" />



Je pense que nous ne saurons jamais ce qui s’est vraiment passé, mais c’est une preuve de plus rappelant que mêmes les GAFAM ne sont pas à l’abri de grosses fuites. Google/Gmail, Facebook & co qui laisse fuiter ses mots de passes, ça arrivera forcément un jour, avec les conséquences qu’il y a derrière.

Après tout c’est déjà arrivé à d’autres “grands” tels que Sony. Donc… pourquoi diable les gens continuent-ils d’offrir leur confiance à ces multinationales ? Faudra t-il un drame à l’échelle mondiale pour que les consciences se réveillent ? Et même si ça arrive, combien on parie que le fautif minimisera les faits, et les gens s’en contenteront, ou se diront “ouais mais on a pas (envie de chercher une) d’alternative de toute façon” ? :-p








Ricard a écrit :



Plus quelques centaines à la NSA.







Quelques milliers à la NSA.



<img data-src=" />



Oh tu sais, ils ne s’embettent pas à passer par facebook.

Il récupère directement tes logs sur ton PC via un keylogger ou une backdoor dans l’OS. :p


Je pense que tout les moyens sont bons, et qu’ils n’en négligent aucun.








aldwyr a écrit :



Oh tu sais, ils ne s’embettent pas à passer par facebook.

Il récupère directement tes logs sur ton PC via un keylogger ou une backdoor dans l’OS. :p







Une backdoor sur mon OS… Bonne chance. :)



Je me demandais comment tu pouvais savoir si les mot de passe etait sauvegarder en clair dans leur base de donné sans avoir accès directement. J’ai eu ma réponse.


Ce genre d’actus fait du bien tellement c’est rafraîchissnt, quand tu te demandes si tu as de bonnes pratiques à ton taf <img data-src=" /> Merci Facebook ! <img data-src=" />


C’est la crème de l’ingénierie chez Facebook.




Le réseau social&nbsp;tente&nbsp;de limiter la casse : les mots de passe n’étaient

pas accessibles par des personnes extérieures à&nbsp;Facebook.





Il y a des cas où les mots de passe sont accessibles par des personnes extérieures à une société ? <img data-src=" />


Ils veulent dire que les logs ne font a priori pas partie des données que Cambridge Analytica a récupérées. <img data-src=" />


C’est tout simplement incroyable qu’une entreprise comme Facebook, un des GAFA,&nbsp; ne crypte (hashe) pas ses mots de passe.


Alors facebook est une boite américaine, donc soumise aux contrôles sox, du coups comment ils ont pu passer à travers ? Soit les auditeurs sont complices et ça prouve que les audits en servent à rien, soit ils ont maquillé les fait et dans ce cas c’est super grave.


Après avoir vu une appli qui transmet les identifiants de connexion de sa BDD dans une URL en get ou encore celle qui trace des erreurs de connexion en mettant les credentials dans la trace, plus rien ne me surprend personnellement.








darkbeast a écrit :



Alors facebook est une boite américaine, donc soumise aux contrôles sox, du coups comment ils ont pu passer à travers ? Soit les auditeurs sont complices et ça prouve que les audits en servent à rien, soit ils ont maquillé les fait et dans ce cas c’est super grave.





Intéressant ce control sox, t as plus d info ?









darkbeast a écrit :



Alors facebook est une boite américaine, donc soumise aux contrôles sox, du coups comment ils ont pu passer à travers ? Soit les auditeurs sont complices et ça prouve que les audits en servent à rien, soit ils ont maquillé les fait et dans ce cas c’est super grave.





Tu es hors sujet. Ces contrôles ne concernent que l’informatique qui traite des données financières.







crocodudule a écrit :



Intéressant ce control sox, t as plus d info ?





Voir le lien ci-dessus.



Ce que je comprend de l’article d’origine (de Krebs), c’est que ces mots de passes n’étaient pas dans une BDD.



Je pense que le scénario qui a eu lieu est que des devs avaient besoin de tracer des infos pour débugguer un truc. Ils ont fait une moulinette qui écrivait tout sur disque pour voir ce qui bloquait. Et ils ont oublié de la désactiver une fois fini.

Et c’est comme ça que tu te retrouves avec des millions de mots de passes en clair sur le disque dur d’un dev.








fred42 a écrit :



Tu es hors sujet. Ces contrôles ne concernent que l’informatique qui traite des données financières.





Voir le lien ci-dessus.





Effectivement c’est sans rapport, merci :)









fred42 a écrit :



Tu es hors sujet. Ces contrôles ne concernent que l’informatique qui traite des données financières.





Voir le lien ci-dessus.







Non ils contrôlent aussi le reste je le sais, j’ai des contrôles tous les ans et ça concerne tous les comptes, backup… Pas que la finance.









crocodudule a écrit :



Intéressant ce control sox, t as plus d info ?







Sox ne concerne que les flux financiers, s’assurer qu’il n’y a pas de fraude. Pour les mots de passe, c’est le rôle des audits sécurité. Et quand une appli est dans le top sox, elle se mange à la fois les contrôles sox et les audits de sécurité.



Ne dites pas “Face de bouc a stocké”.

Dites :&nbsp; “la NSA stocke”.

Le passé composé, c’est pour les niais de service.

&nbsp;


le pb c’est que FB est devenu une brique de SSO pour beaucoup d’applis donc leur auth doit être irréprochable

&nbsp;