Actu - Facebook stockait des millions de mots de passe sans les crypter

[RSSBot]

Un expert en sécurité a découvert que pendant sept ans, de 2012 à 2019, Facebook n'avait pas chiffré les mots de passe de centaines de millions d'utilisateurs. Des milliers de salariés de Facebook...

Lire la suite : Facebook stockait des millions de mots de passe sans les crypter

[Publicité]

[Damien49]

Quelle incompétence. Le cryptage des mots de passe c'est la base de la base. Même moi avec mon minuscule site fait main sans aucun cours d'informatique je sais crypter un mot de passe en php. Quelle honte.

[uneautreterre]

Non, non, iln'y a pas besoin d'un « petit logiciel » pour crypter un mot de passe. Les langages côtés serveurs le font via une simple fonction native dans le langage. Et comme le dit l'intervenant qui me précède, c'est vraiment basique et tout développeur un poil sérieux le fait.

[LeMulet]

En tous cas il faut vraiment ne pas être très futé (ou totalement déconnecté des réalités du monde du travail ou totalement incompétent en informatique) pour penser que les informaticiens d'une société de cette envergure aient pu passer à côté d'une chose aussi basique à mettre en œuvre que le cryptage des mots de passe, et ce pendant des années. Mais c'est vrai que si on se prend pour un caïd et qu'on croit que tous les autres sont des incompétents, on peut le penser. On appelle ça l'effet Dunning-Kruger.

[A voir en vidéo sur Futura]

[Damien49]

Vu que ce sont des données qui n'était pas cryptés uniquement pour les employés de facebook, j'en déduis que nos mots de passes étaient en fait bien cryptés, mais que c'est le stockage de la clef de cryptage qui devait être disponible en interne. Enfin c'est une simple déduction.

[JPL]

Je crois que la technique généralement employée c’est de faire un hachage du mot de passe de telle sorte qu’il n’y a pas d’opération inverse possible pour le restaurer.

[Publicité]

[pm42]

Je crois que la technique généralement employée c’est de faire un hachage du mot de passe de telle sorte qu’il n’y a pas d’opération inverse possible pour le restaurer.

Oui. Mais même ça, il faut faire attention parce que certains algorithmes deviennent trop faibles. C'est notamment le cas du MD5 et du SHA-1.
Mais effectivement, on applique cette technique en faisant en sorte que le mot de passe en clair ne passe pas sur le réseau et même qu'il soit le moins longtemps visible en mémoire.
C'est vraiment de la sécurité de base connue depuis longtemps. Donc Facebook a encore fait très, très fort.

[JPL]

Par contre il existe diverses rainbow tables contenant le hachage de milliers de mots de passe (et de leurs variantes) fréquemment utilisés qui permettent de les retrouver s’ils sont trop simples. Mais cela demande un traitement spécial de la base de données qui est par nature délictueuse.

[Damien49]

En fait on dit pas cryptage, c'est vrai. On dit chiffrage

Un petit site pour différencier le tout : https://chiffrer.info/

Mais pour les mots de passe c'est pas du hachage, sinon on pourrait pas retrouver le mot de passe, c'est bien du chiffrage. On a donc besoin d'une clef. Le chiffrage utilisant aussi des fonctions de hachage, mais de manière réversible. Md5 est obsolète pour les raisons données par JPL, on utilise plutôt du open-ssl maintenant. Sans la clef impossible de déchiffrer un mot de passe.

[Damien49]

oups chiffrement pardon ^^

[pm42]

En fait on dit pas cryptage, c'est vrai. On dit chiffrage

Vu que cryptage est dans le Robert, sur Wikipedia et ailleurs, on va continuer à l'utiliser.

Mais pour les mots de passe c'est pas du hachage, sinon on pourrait pas retrouver le mot de passe, c'est bien du chiffrage.

Justement, le principe est qu'on ne puisse pas retrouver le mot de passe.

On a donc besoin d'une clef.

Non.

Le chiffrage utilisant aussi des fonctions de hachage, mais de manière réversible.

hachage et réversible sont incompatibles en cryptographie.

Md5 est obsolète pour les raisons données par JPL, on utilise plutôt du open-ssl maintenant

open-ssl est une librairie pour implémenter de la communication sécurisée. Cela n'a rien à voir avec md5.

Sans la clef impossible de déchiffrer un mot de passe.

En tout cas chapeau, chacune de tes phrases est fausse.

[JPL]

En fait c’est simple. Le mot de passe est stocké sous forme de hachage et quand on veut se connecter au site on tape son mot de passe, le site le reçoit et le hache et on compare le résultat de ce hachage à celui qui est stocké pour voir s’ils sont identiques. La même technique est utilisée pour les numéros de carte bancaire... du moins on l’espère.

[Publicité]

[Damien49]

Bah t'es gentil mais je connais un peu le sujet ayant moi-même mis en place un système de chiffrement de mot de passe pour mon site. Visiblement j'ai fait mieux que Facebook.

Le terme « cryptage » et ses dérivés viennent du grec ancien κρυπτός, kruptos, « caché, secret ». Cependant, le Référentiel Général de Sécurité de l’ANSSI qualifie d’incorrect « cryptage ». En effet, la terminologie de cryptage reviendrait à coder un fichier sans en connaître la clé et donc sans pouvoir le décoder ensuite. Le terme n’est par ailleurs pas reconnu par le dictionnaire de l’Académie française.

Justement, le principe est qu'on ne puisse pas retrouver le mot de passe.

Visiblement tu n'as pas compris le principe d'un chiffrement de mot de passe. C'est le stockage du mot de passe qui doit être chiffré, mais on a forcément besoin de le retrouver sinon tu ne pourrais jamais te connecter. Tu es obligé d'utiliser un système de clef. Si tu fais une simple fonction de hachage sans clef, faudra que tu nous explique comment le site fait pour détecter que tu inscrit bien le bon mot de passe par rapport à celui qu'il a stocké haché dans sa base de donnée. Bon courage.

[Damien49]

open-ssl est une librairie pour implémenter de la communication sécurisée. Cela n'a rien à voir avec md5.

Pardon oui j'ai confondu c'est mcrypt qui n'est plus sécurisé et que openssl remplace. (mcrypt pouvant utiliser md5)

[Damien49]

hachage et réversible sont incompatibles en cryptographie.

Quand tu utilises un système de chiffrement avec clef, tu utilises aussi des fonctions de hachage, afin de rendre ton chiffrement unique, sauf que la fonction de chiffrement est plus complexe qu'un simple hachage, car tu as forcément besoin à un moment donné de la déchiffrer (pour pouvoir t'identifier avec ton mot de passe en l’occurrence)

Exemple openssl issu de mon site :

$ivlen = openssl_cipher_iv_length($ciph er="AES-128-CBC");
$iv = openssl_random_pseudo_bytes($i vlen);
$ciphertext_raw = openssl_encrypt($my_key, $cipher, $key_crypt, $options=OPENSSL_RAW_DATA, $iv);
$hmac = hash_hmac('sha256', $ciphertext_raw, $key_crypt, $as_binary=true);
$my_key = base64_encode( $iv.$hmac.$ciphertext_raw );

Il y a bien ici à la fois du hachage et également l'utilisation d'une clef de chiffrement. Ici c'est la fonction de chiffrement, j'en ai une autre pour déchiffrer.

https://blog.developpez.com/sqlpro/p...dans-les-sgbdr

[JPL]

Excuse-moi mais j’avais lu une autre explication, comme je l’expliquais dans mon message n° 12. En opérant comme je l’avais lu on n’a nul besoin de décrypter le mot de passe stocké pour que ça fonctionne. D’ailleurs à quoi serviraient les énormes rainbow tables qu’apprécient tant les black hackers si les mots de passe et numéros de carte de crédits n’étaient pas tout simplement stockés sous une forme simplement hachée ? S’ils étaient passés à la moulinette d’un vrai cryptagge elles seraient totalement inutiles.
Ce que tu expliques je le connais parce que j’avais eu la curiosité de lire la manière dont Truecrypt et son successeur Véracrypt procèdent pour crypter (au pardon... chiffrer) des données, mais cela correspond pas à ce que j’avais lu il y a peu d’années pour le stockage des mots de passe.

[pm42]

Voir https://fr.wikipedia.org/wiki/Foncti...ons_typiques_2 ou n'importe quelle explication sur le Net.

On est dans du pur Dunning-Kruger : il n'a tout compris à l'envers.
L'idée est justement de ne surtout pas utiliser un cryptage réversible pour les mots de passe. D'abord parce que cette clé étant stockée quelque part, cela donnerait à l'administrateur la possibilité de connaitre les mots de passe en clair.
Ce qui serait une énorme faille et ce d'autant plus que les gens les partagent entre plusieurs systèmes.

Ensuite, cela donnerait à un attaquant externe un point unique de vulnérabilité : une fois la clé trouvée, il récupèrerait les mots de passe en clair de tout les utilisateurs.

Comme le dit JPL, c'est le principe des fonctions de hachage : elle ne sont pas réversible ce qui est déjà normal vu qu'elles ne sont pas surjectives mais surtout, on ne sait pas générer de collisions : pour un résultat donné, on n'arrive pas à trouver une valeur dans l'espace d'origine qui le donne.
Petit exemple : https://www.linformaticien.com/actua...-fonction.aspx

Donc l'idée intelligente est effectivement de stocker le hachage et ensuite à la connection, quand l'utilisateur tape son mot de passe, on recalcule la même fonction et on compare le résultat.
Et seule cette valeur haché transite sur le réseau.

Sinon, il faudrait envoyer à un moment donné la valeur en clair pour la comparer : et encore une faille de sécurité.

[Damien49]

Non mais t'as lu le lien que j'ai mis, visiblement tu confonds hachage et chiffrement c'est bien ce que je dis.

https://blog.developpez.com/sqlpro/p...dans-les-sgbdr

De plus en plus de jeunes développeurs confondent la technique du hachage et le chiffrement des données.

On est en plein dedans. Tu as déjà codé un peu ? Tu as déjà réalisé un système pour stocker des mots de passe pour un site ? On utilisait peut être il y a des éons du simple hachage pour la gestion des mots de passe, mais c'est totalement obsolète aujourd'hui et prend le risque justement qu'il y ait de grosses failles de sécurité puisque les tables sont disponibles. On utilise maintenant du hachage avec "salts", autrement dit, une clef.

https://apprendre-php.com/tutoriels/...les-salts.html

Il n'y a aucune faille de sécurité avec un systeme de clef, puisque la clef est généré de manière unique par utilisateur et codé en dur dans le code coté serveur. Il faudrait pouvoir accès au code source pour connaitre la clef. Et il n'y a aucun risque que le mot de passe soit intercepté en transit sur le réseau car la méthode de chiffrement hache le mot de passe avant son stockage, comme je le dis depuis le début.

PS : et ça serait bien de pas prendre les autres pour des imbéciles de manière aussi dédaigneuse et hautaine, merci.

[Publicité]

[pm42]

On utilise maintenant du hachage avec "salts", autrement dit, une clef.

On utilise un salt pour augmenter l'espace de la fonction de hachage. On faisait déjà ça il y a des décennies et cela n'a rien à voir avec du cryptage.
D'ailleurs le salt est souvent stocké en clair : ce n'est pas une clé.
Voir :
https://security.stackexchange.com/q...-to-store-salt
https://en.wikipedia.org/wiki/Salt_(cryptography)

PS : et ça serait bien de pas prendre les autres pour des imbéciles de manière aussi dédaigneuse et hautaine, merci.

Dans ce cas, il faut éviter de raconter des choses fausses et dangereuse et de croire que vous êtes le seul à avoir compris et à avoir programmé.
JPL et moi même vous expliquons depuis le début que vous n'avez absolument pas compris la façon dont les choses fonctionnent mais vous restez très sur de vous.
Alors qu'aucune référence ne confirme ce que vous dites simplement parce que vous confondez la clé à usage unique générée pour crypter les communications ssl avec la technique d'authentification des mots de passe...

[mh34]

Ce serait bien que tout le monde baisse d'un ton.
Dernier avertissement.

[Damien49]

Ok me suis renseigné, tu as raison, facebook n'utilise pas un systeme de chiffrement avec clef. Je viens de faire l'essai en lui demandant mon mot de passe oublié, et il ne me l'a pas redonné, mais m'a demandé d'en générer un nouveau. J'étais persuadé qu'on pouvait récupérer son mot de passe par mail, ce que seul la méthode par clef est capable de réaliser.

Mais j'avais pas complétement tort non plus, beaucoup de sites PHP utilisent bien l'autre méthode avec clef. Les 2 méthodes existent : https://openclassrooms.com/fr/course...teurs-avec-php

[pm42]

plus, beaucoup de sites PHP utilisent bien l'autre méthode avec clef. Les 2 méthodes existent : https://openclassrooms.com/fr/course...teurs-avec-php

Non plus. Le site parle bien des "mots de passe faible" : une fois qu'on a le salt, on peut faire une attaque en force brute mais toujours pas décrypter.

[Damien49]

Je parle du système de chiffrement, pas de hachage avec salt. Le soucis pm42 c'est que je connais pas bien la méthode de hachage avec comparaison soit, j'ai eu tort, mais tu ne connais pas non plus l'autre méthode et est persuadé qu'elle n'existe pas et est obsolète. Tu as tort sur ce point.



Cette méthode est sûr, il suffit de cacher la clef dans le code source. Pour un serveur non mutualisé ou un site avec administrateur unique, c'est le plus simple, sécurisé et efficace. Et aucun soucis de Rainbow table.

[pm42]

Cette méthode est sûr, il suffit de cacher la clef dans le code source. Pour un serveur non mutualisé ou un site avec administrateur unique, c'est le plus simple, sécurisé et efficace. Et aucun soucis de Rainbow table.

C'est encore mieux si le serveur est éteint, dans un bunker rempli de gaz innervant, loin de toute connection Internet et gardé par des mercenaires très bien payé.
Je vais arrêter là parce que la méthode en question est tellement catastrophique et dangereuse que je ne veux pas en parler.

[Publicité]

[Damien49]

Tu expliqueras ça à la CNIL :

https://www.cnil.fr/fr/securite-chif...rite-ou-signer

[JPL]

On va arrêter là puisque les divers points de vue ont été exprimés en que la conversation devient un peu nerveuse.