@String Theory FR Bonne vidéo, bonnes explications, mais cependant il y a une erreur à la fin. La méthode que tu décris pour s'authentifier sur Facebook est une méthode de non-divulgation du mot de passe, qui permet au serveur de vérifier qu'un client connaît bien son mot de passe sans qu'il ait besoin de le divulguer, au moyen de la signature d'un challenge. Ce n'est cependant pas de la cryptographie asymétrique (il n'y a pas de clé publique impliquée dans cette méthode). De plus, Facebook n'utilise pas cette méthode pour authentifier l'utilisateur sans fuiter le mot de passe.Pour s'en convaincre, c'est très simple, en quelques étapes: - dans Firefox, aller sur la page de connexion Facebook,- aller dans le menu > Développement Web > Réseau,- ça ouvre une zone / fenêtre qui permettra de voir tout ce que Firefox transmet et reçoit du serveur distant,- entrer son nom d'utilisateur et son mot de passe sur Facebook et valider,- dans la fenêtre Réseau, on peut alors voir que la première requête est une requête POST: Firefox envoie des données au serveur de Facebook,- cliquer sur cette requête POST pour avoir les détails, et dans le panneau qui s'ouvre ouvrir l'onglet Params- on peut alors constater que le mot de passe et le nom d'utilisateur sont transmis tel quels au serveur, qui reçoit donc bien le mot de passe saisi. Mais alors comment est-ce que le mot de passe est sécurisé lors de cette transaction? En réalité tout repose sur TLS (fourni par HTTPS).TLS permet au navigateur d'authentifier, à l'aide de la cryptographie asymétrique, qu'il communique bel et bien avec le serveur de Facebook. Une autorité de certification lui permet de s'en assurer, autorité qui a signé le certificat de Facebook (en l'occurence le petit cadenas vert nous indique qu'il s'agit ici de Digicert). Une fois Facebook authentifié auprès du navigateur, on a une phase de négociation TLS qui a lieu entre le navigateur et Facebook, impliquant de l'aléa, de façon à générer une session unique.Cette session est composée de clés symétriques partagées entre Facebook et le navigateur, elles vont permettre de rendre confidentiels les échanges via chiffrement (en général AES) et de pouvoir vérifier leur authenticité via un MAC. Le mot de passe est donc bel et bien transmis à Facebook, mais dans un canal sécurisé par de la cryptographie symétrique, canal précédemment authentifié via de la cryptographie asymétrique, en général ECC (plus coûteuse en calculs). Dans certains cas, en plus de l'authentification du serveur par un client, on authentifie le client auprès du serveur via TLS. Mais ce n'est pas pratiqué sur le web, étant donné qu'avoir un certificat signé par une autorité n'est pas chose simple. De plus Facebook n'a aucun besoin d'authentifier ses visiteurs par ce biais, ils le font par mot de passe. Bonne continuation pour tes vidéos, à bientôt !
Putain merci. Enfin quelqu'un qui sait de quoi il parle. Merci. J'ai eu le même réflexe : sortir la console de dev, et oui, le mot de passe est envoyé en "clair" dans une requête POST... Mais on est en HTTPS donc, pas de soucis.
Mea culpa : le fonctionnement précis du login Facebook est plus complexe et je ne le connais vraiment pas. Le point important est qu'il s'agit là d'une solution classique pour l'authentification numérique sécurisée. Il existe d'autres variantes possibles, comme la méthode des hashs de Lamport, qui consiste à révéler hash(hash(hash(....(hash(mot de passe)))) = hash^1000(mot de passe). Puis pour certifier notre identité, on peut révéler hash^999(mot de passe), qui devient alors public. Puis pour recertifier notre identité, on peut révéler hash^998(mot de passe)... et ainsi de suite.
C'est pourtant pas dur de se documenter sur SSL/TLS AVANT de faire une vidéo sur le sujet .... RFC 6101,5246,8446 fr.wikipedia.org/wiki/Transport_Layer_Security
"hashs de Lamport, qui consiste à révéler hash(hash(hash(....(hash(mot de passe)))) = hash^1000(mot de passe)" WHAT ?! Je ne sais pas où tu as lu ça mais d'une part la page Wikipédia ne décrit pas du tout cet algorithme (fr.wikipedia.org/wiki/Signature_de_Lamport) et d'autre part si c'était bien basé sur une série d'étapes de hashage, la sécurité serait totalement compromise par des collisions en cascade - c'est à proscrire ! Genre vraiment, j'insiste ! Ne faites jamais ça !
Bonjour Lé. Bizarre, j'ai testé de m'authentifier sur Facebook via zaproxy depuis mon navigateur et ho surprise ds le flux https, le mot de passe est envoyé... en clair!!! Dans quelles conditions un mécanisme complexe d'authentification est il utilisé par Facebook ?
Heu, 1:05 :"pour les vieux parmis vous" . Wouah ! Un "pour les plus anciens parmis vous" MERCI..... et pis d'abord ça existe encore les chèques, non mais 😅.
Bon ça nous arrive encore de faire des chèques vous savez ^^ Que ce soit des cautions ou autre par exemple ! Mais il est vrai que justement pas mal de magasins les refusent car ils ne sont pas assez sécurisés justement.
Ouais... ça c'est la théorie. Et sinon, en pratique, comme on l'a appris le mois passé, Facebook stocke (a stocké) sur ses serveurs internes des centaines de millions de mots de passe en clair accessibles à des milliers de ses employés...
Dès le début : "Certification digitale" Sauf que "Le terme digital est l'adjectif associé au substantif doigt (exemple: tracé digital; empreinte digitale; comput digital)." (Merci Wikipedia) On dirait plutôt "Certification numérique"
«Vous vous êtes déjà demandé ce qui se passe lorsqu’on rentre le mot de passe sur FaceBook ?» Non. Je pense que la plus part des personnes ne se posent pas ce genre de questions... Mais... si on regarde ta vidéo, c’est qu’on est intéressé ! 😬 Merci pour ta vidéo.
Bon, alors, les vieux vous signalent qu'en 2019, on peut encore payer par chèque... C'est pratique, notamment pour s'acheter des trucs entre particuliers. Parce que, bon, perso, je prends toujours pas la carte bleue, mais les chèques, oui. (C'était la minute vieux, je vous laisse entre jeunes...)
Pourquoi tu t'es doublé ? Le micro a merdé au tournage ? Ou alors la synchro dans le logiciel de montage ? Ça fait bizard a regarder. En fait, je veux dire que je trouve que le son ne correspond pas toujours à l'acoustique pré supposé du lieu.
Je suis 100% d'accord avec la vidéo jusqu'à 5:55 ... Pour faire ce qui serait décrit à la fin il faudrait que Facebook stocke notre mdp en clair ? Sinon l'utilisateur applique au mdp la fonction de hash avant d'effectuer la signature mais alors cela signifie que Facebook stocke des équivalents de mdp en clair ? (Comme les hash ntlm sous Windows... cf attaque passthehash). J'avoue que je ne vois pas comment Facebook réaliserait cela !!! Qlq'1 a des liens SVP ? Ce qui est expliqué avant correspond plus à l'authentification/échange de clé ssl/tls du serveur par le navigateur qu'a l'authentification de l'utilisateur par le serveur.
Facebook n'a pas besoin de notre mot de passe en claire. En général il le stock en MD5. Mais entre temps le mot de passe aura voyager sous une autre forme de clé. Il à besoin seulement que la clé envoyé même hashé soit égale à la clé reçu (hashé également). Qui elle même est crypté via une clé. Comme ça le mot de passe n'est jamais donner en claire. Mais bon, comme dis un mot de passe que tu l'as en brute ou en MD5 c'est pareille.
Si tu veux plus d'information on appel cette methode *Challenge-response authentification* Wikipedia EN: en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication (l'article en anglais et meilleur que celui FR) Wikipedia FR: fr.wikipedia.org/wiki/Authentification_d%C3%A9fi-r%C3%A9ponse Tu peux aussi juste chercher le nom de de la methode sur un moteur de recherche pour avoir plein de liens
Euh il y a une grosse confusion entre les clefs de chiffrement et les mots de passe. La connexion HTTPS s'effectue normalement avec l'histoire de clef pubilque et privée. Le mot de passe est envoyé via le tunel SSL tel quel, facebook le compare à ce qu'il y a dans la base de donnée (et sans le chiffrer ! il est même pas chiffré en base de donnée d'après la dernière fuite) Pour savoir si l'utilisateur reviens, c'est juste une session bassée sur un grand chiffre dans les cookies. Bref le mot de passe sur facebook a la même gestion qu'un site fait par jean-kikoo-du-92 (sauf l'infrastructure qui est plus résistante aux attaques)
Punaise, le "pour les vieux parmi vous" je l'ai trouvé un peu raide celle-là ^^ Heureusement qu'il existe encore des chéquiers sinon j'aurais été qualifié de 3 ème âge :D
Ah ah la punchline pour les vieux et les chèques 😂😂😂 Elle est bonne mais ca match pas avec le ton sérieux... Bon sinon je suis surpris du nombre de commentateurs qui utilisent encore des chèques...
Au sein de mon école, les cotisations aux assos, c'est par chèque... On a entre 19 et 23 ans et a priori on a tous un chéquier, même si c'est pas une utilisation quotidienne c'est toujours utile.
Pour les chèques en début de vidéos je ne comprend pas trop. Un paiement est bien un transfert d'argent, du coup les chèques existent encore et sont toujours utilisés. Donc je ne pense pas que ce soit un problème d'âge de connaître les chèques ou non, mais plutôt du "monde" dans lequel on évolue. Mes neveux de 14ans connaissent les chèques et savent en remplir. J'ai l'impression que l'on parle d'un mode de paiement qui a pris fin dans les années 60. Cela dit, ca montre que je suis largué...comme mes parents l'ont été à une époque. Affaire à suivre !!!
Hum, mais où sont les sources ? :) Bien qu'intéressant, il n'y a pas de système de signature numérique a l'aide d'une clef qui pourrait être dérivée du mot de passe sur l'interface de connexion de facebook :/
C'est justement ce que je me demandais, je ne connais pas le protocole de facebook c'est interessant de savoir si ils utilisent du challenge-response authentication. Par ailleurs ça serait une bonne idée de leur part pour permettre des connexion via le compte FB sur d'autre platforme. PS: ça fait quand meme un bon exemple au pire
De ce que je vois sur la page d'authentification de facebook, le login/password est envoyé tel que au serveur (avec quelques meta données de tracking (no kidding ;)) Exercice interessant, par exemple avec l'algorithme de signature EdDSA (RFC 8032) il est possible de générer une clef publique et une clef privée a partir d'une graine de 32 octets. On pourrait donc, lors du choix du mot de passe, le dériver avec PBKDF2 afin d'obtenir la graine de 32 octets, générer les deux clefs et envoyer à FB la clef publique. Lors de la phase d'authentification, FB envoie un challenge et l'utilisateur entre son mot de passe dans l'interface. A ce moment là le navigateur peut regénérer la clef privée à partir de ce mot de passe en suivant le meme algorithme qu'avant et ensuite signer le challenge. Il suffit ensuite d'envoyer a FB le challenge signé et FB peut vérifier la signature pour authentifier l'utilisateur. Bien compliqué pour très peu de gain :/ Effectivement, vu que c'est du challenge-response, si la transmission TLS est compromise, le mot de passe ne transite pas. Et comme le mot de passe ne transite pas, ça eviterai peut-être qu'ils le stoquent en clair dans leurs logs ;-) Il faut bien faire attention à ce que l'algorithme qui passe du mot de passe à la clef publique soit suffisamment gourmand en ressource, sinon en cas de leak de cette clef publique, il deviendrait presque trivial de faire une attaque par bruteforce sur le mot de passe. C'est pourquoi on utilise des algorithmes comme bcrypt pour générer de manière sécurisée les empreintes des mot de passe qui sont stoquées en base de données. Ne pas oublier de rajouter aussi un peu d'aléa (un sel qui pourrait être dérivé d'un ID d'utilisateur) car sinon, si deux utilisateurs utilisent le même mot de passe, ils auront la même clef publique ... Et donc sans connaitre leur mot de passe, en cas de leak de la base, il est facile de voir quel(s) utilisateur(s) utilisent le même mot de passe. De ce fait, on sait lequel on va essayer de casser en premier: en cas de réussite on a gagné plusieurs comptes et si c'est le même, il y a une forte chance qu'il soit trivial :)
@@toms2809 "le login/password est envoyé tel que au serveur (avec quelques meta données de tracking (no kidding ;))" Sans surprise. " Bien compliqué pour très peu de gain :/" La securité des users c'est gros gain normalement x) ... mais bon on parle de facebook. Sinon l'avantage une unification des methodes de connexion à plusieur platforme avec un seule compte. Par exemple avoir la meme clé publique utilisé par google, facebook, twitter, ... pas besoin d'etre facebook pour verifier que le challenge response est validé, il suffit d'une clé qui est publique et donc accessible a tout le monde (toute les platformes). "Effectivement, vu que c'est du challenge-response, si la transmission TLS est compromise, le mot de passe ne transite pas. Et comme le mot de passe ne transite pas, ça eviterai peut-être qu'ils le stoquent en clair dans leurs logs ;-)" Si le TLS et compromis (par une attaque non passive) il est possible d'injecter du code qui va leak les passwords directement depuis la page web ou on rentre le password. "Il faut bien faire attention à ce que l'algorithme qui passe du mot de passe à la clef publique soit suffisamment gourmand en ressource, sinon en cas de leak de cette clef publique" Je pense que tu tiens là la raison pour la quelle facebook ne fait pas ça: Tout l'interet du challenge-response c'est de pouvoir diffuser une clé *publique* qui sera visible par tout le monde. Mais dans des cas classique de challenge-response on ne derive pas les paires de clé depuis un petit password mais plutot derivé depuis un passphrase pour etre resistant aux attaques bruteforce par dico ou alors simplement avec des seeds random qui sont elles aussi ressistantes aux attaques bruteforces. C'est donc imcompatible de diffuser publiquement une public key derivé depuis un password pour securiser une authentification. tout les gens avec des password simple se ferait casser leur password tres rapidement car il suffit de tester aleatoirement, et en local, des passwords tres rependu sur des listes de publique key (qui sont publique donc accessible a tout le monde). On peut bien mettre un algo un peu lourd, ou qui s'adapte comme bcrypt, de toute façon comme la bdd est publique le travail et simplifier. Il serait preferable de mettre en place des protocoles de challenge response auth avec des paires de clé pri/pub à seed aleatoire qui doivent donc etre stocké sur du hardware secu comme les clé yubico par exemple. Ou alors avec des passphrase. Je sais pas si tu es d'accord avec moi, mais je pense qu'on a trouvé la raison qui explique pourquoi facebook ne fait pas de challenge response sur les passwords. Il n'y a aucun interet si c'est pas pour avoir des clés vraiment publiques, or avoir des clés vraiment publiques est imcompatible avec des clés derivés depuis des passwords.
Il existe une méthode d'authentification en deux temps qui consiste à envoyer un challenge et sa clef privée cryptée à l'utilisateur qui vient d'entrer un login et d'attendre que l'utilisateur déchiffre la clef et l'utilise pour répondre au challenge. Ça se bien fait avec les CryptoAPI des navigateurs. Mais ça veut dire qu'on peut attaquer une clef offline...
Il y a aussi autre chose a prendre en compte ... avec un système de d'authentification avec clef publique tel que tu le décris, tu obtiens un super moyen de tracker tous les utilisateurs. Comme tu utilise la même clef chez FB, Google, Amazon, etc... il n'y a plus rien qui les empêche de mettre en commun leurs informations pour savoir que c'est la même personne physique derrière les comptes sur toutes les plateformes... et ça c'est pas cool. C'est d'ailleurs pour ça que certains mécanismes d'authentification en challenge-response par exemple WebAuthn, génèrent une clef publique différente a chaque inscription pour garantir un certain niveau de confidentialité
Quoi? C'est la 1er fois que me traite de vieux parce que j'utilise des chèques!! donc dès qu'on dépasse 35ans il faut un déambulateur ? j'étais a 2doigts de t'envoyer un chèque pour soigner ton acné! Et ne compte pas être invité aux soirées crêpes dans les EHPAD... sur ce bonne soirée, un tisane camomille, un supo et au lit!! (je met un like quand même avec ma souris payé par chèque...)
est-ce que ça veut dire que si on déchiffre avec la clé publique de l'utilisatrice, on trouve un document signé par le mot de passe ? c'est débile non ? j'ai du raté quelque chose...
non, le mot de passe c'est la clé privé, cette clé reste de ton coté (c'est pour ça qu'elle est privé), jamais tu ne la transmet. Ce que tu transmets ne contient pas ton mot de passe (c'est peut-etre un peu ambigue dans la video) cela contient simplement la donné aleatoire que t'as envoyé facebook mais que tu as chiffré en utilisant ta clé privé. Pour verifier si le mot de passe est bon il suffit alors d'utiliser la clé publique (que tout le monde à le droit de connaitre) pour dechiffrer les donnés aleatoires. Une fois déchiffé FB peut verifier si le contenu est identique à ce qu'il a demandé. Comme cette donné aleatoire ne sera utilisé qu'une fois par utilisateur, cela empeche de reutiliser cette signature. Par contre je doute que FaceBook pratique vraiment cela de cette maniere, mais cela fonctionnerait en tout cas ^^. PS: pour etre precis, c'est pas que le mot de passe c'est la clé privé, c'est que la clé privé et publique sont generé à partir du mot de passe, mais c'est un detail =)
les banques fournissent de moins en moins de chèques sauf en cas de demande, c'est le cas pour les banques en ligne. enfin les commerces bannissent ce moyen de paiement donc oui on peut parler des chèques au passé
J'ai bien peur qu'il y ait plus de vieux que tu ne l'imagines dans tes abonnés. Sinon, tu devrais sortir un peu, parce que les chèques, ça existe toujours, ça s'utilise encore beaucoup. Et je connais bien plus de gens qui se font avoir dans leur vie numérique que dans leur vie papier ! A part ça, merci pour tes videogrammes petit galopin !
J'ai une question (pas forcément dans le cas de Facebook) : Comment fait-on pour être sur que la clée publique de Florence soit bien émise par Florence ? N'y a-t-il pas moyen d'émettre une fausse clée public et un document l'or à cette clé ?
La clé publique n'est pas emise à chaque fois en faite. Elle est stocké dans les base de donné de facebook. On sait donc qu'elle est valide car elle etait valide toute les fois d'avant. C'est biensur toujours la meme paire de clé publique/privé qui est utilisé a chaque connexion. (en realité cette paire de clé est generé a partir du mot de passe, comme ça si on change le mot de passe ça change la clé publique et privé) Le probleme est donc de savoir si c'est la bonne clé publique qu'on a recu la premiere fois ;) Et pour ça il faut que l'inscription se fasse de manière securisé. Pour cela on utilise les meme type de protocole mais en un peu plus complexe avec des certificats qui cerifient d'autres certificats. Sauf que au bout de la chaine, il y a un certificat qui est produit par une source consideré comme sûre, qui fait autorité. Cette source sur est souvent une entrprise dont c'est justement le corps de metier. Si quelqu'un arrive a imiter cette autorité de certification alors ce n'est pas que ton compte Facebook qui n'est plus sur, c'est tout le monde,et on s'en rendrait compte tres vite. Il serait alors facile d'invalider tous les certificats de cette autorité =) (la revocabilité d'un certificat c'est important aussi) Autant te dire que pour pirater ton compte facebook il est impensable d'essayer d'attaquer une autorité de certification ;) Par contre dans des domaines tres critiques (l'armement par exemple) on ne veut pas dependre de ces autorités, on peut alors faire les echanges de clé directement de maniere physique. Par exemple sur une clé USB chiffré.. (enfin on a du hardware pour faire des choses secu ;))
@@Arthur-qv8np Dans le domaine de l'armement, on veut dépendre d'une autorité qu'on maîtrise. L'armée française utilise l'autorité de l'armée française.
Très intéressant. Merci et bravo (ps : perso, je n'ai jamais imité la signature de mes parents... mais j'en connais des ... ah ah ah). Vidéo très intéressante, bourrée d'humour et instructive. Merci.
Dommage que la vidéo commence à @5:58 Le terme Digital (WTF) La blockchain en solution décentralisée n'est pas la solution #attaquedes51% Merci tout de même pour la vidéo
Le nombre de commentaires à propos des chèques et des vieux ....😂 je lui en rajoute pas une couche, je crois "qu'il esr habillé pour l'année "... une expression de "vieux" ? 😉
la blockchain c'est cool mais il nous manque toujours un *consensus protocol* qui fonctionne et qui ne consomme pas autant d'energie que la proof of work utilisé sur dans presque toute les crypto currency. Peut-etre la proof of stack mais c'est pas evident. Donc en attendant il faut pas trop se hyper ^^
Je dis non, non, no et NON !! L'explication se veut intéressante et sérieuse mais pert toute crédibilité en moins de 40 second. Pourquoi ??? "...la certification DIGITALE..." NUMERIQUE BORDEL !!!!!!!
#Blockchain ... voui ... avec une centrale nucléaire aux fesses pour alimenter les ordi qui permettent le calcul (au moins pour le minage, mais pas que)... Pas sûr que ce soit très efficace tout ça ;-) Ca peut être intéressant de parler de cet aspect, y compris (surtout ?) pour me montrer si/où je me trompe.
Très déçu par cette vidéo... Autant, d'habitude, les épisodes CRYPTO sont intéressants mais là... Certes la signature numérique réalisée via chiffrement asymétrique est bien expliquée, mais le titre de la vidéo est méga putaclic et on fait un survole express du "sujet" en 20s en fin de vidéo, complètement bâclé, qui laisse très perplexe, jusqu'à la véracité de ce qui est annoncé... L'intro est également hyper bancale...
@String Theory FR Bonne vidéo, bonnes explications, mais cependant il y a une erreur à la fin.
La méthode que tu décris pour s'authentifier sur Facebook est une méthode de non-divulgation du mot de passe, qui permet au serveur de vérifier qu'un client connaît bien son mot de passe sans qu'il ait besoin de le divulguer, au moyen de la signature d'un challenge. Ce n'est cependant pas de la cryptographie asymétrique (il n'y a pas de clé publique impliquée dans cette méthode).
De plus, Facebook n'utilise pas cette méthode pour authentifier l'utilisateur sans fuiter le mot de passe.Pour s'en convaincre, c'est très simple, en quelques étapes:
- dans Firefox, aller sur la page de connexion Facebook,- aller dans le menu > Développement Web > Réseau,- ça ouvre une zone / fenêtre qui permettra de voir tout ce que Firefox transmet et reçoit du serveur distant,- entrer son nom d'utilisateur et son mot de passe sur Facebook et valider,- dans la fenêtre Réseau, on peut alors voir que la première requête est une requête POST: Firefox envoie des données au serveur de Facebook,- cliquer sur cette requête POST pour avoir les détails, et dans le panneau qui s'ouvre ouvrir l'onglet Params- on peut alors constater que le mot de passe et le nom d'utilisateur sont transmis tel quels au serveur, qui reçoit donc bien le mot de passe saisi.
Mais alors comment est-ce que le mot de passe est sécurisé lors de cette transaction?
En réalité tout repose sur TLS (fourni par HTTPS).TLS permet au navigateur d'authentifier, à l'aide de la cryptographie asymétrique, qu'il communique bel et bien avec le serveur de Facebook. Une autorité de certification lui permet de s'en assurer, autorité qui a signé le certificat de Facebook (en l'occurence le petit cadenas vert nous indique qu'il s'agit ici de Digicert).
Une fois Facebook authentifié auprès du navigateur, on a une phase de négociation TLS qui a lieu entre le navigateur et Facebook, impliquant de l'aléa, de façon à générer une session unique.Cette session est composée de clés symétriques partagées entre Facebook et le navigateur, elles vont permettre de rendre confidentiels les échanges via chiffrement (en général AES) et de pouvoir vérifier leur authenticité via un MAC.
Le mot de passe est donc bel et bien transmis à Facebook, mais dans un canal sécurisé par de la cryptographie symétrique, canal précédemment authentifié via de la cryptographie asymétrique, en général ECC (plus coûteuse en calculs).
Dans certains cas, en plus de l'authentification du serveur par un client, on authentifie le client auprès du serveur via TLS. Mais ce n'est pas pratiqué sur le web, étant donné qu'avoir un certificat signé par une autorité n'est pas chose simple. De plus Facebook n'a aucun besoin d'authentifier ses visiteurs par ce biais, ils le font par mot de passe.
Bonne continuation pour tes vidéos, à bientôt !
Putain merci. Enfin quelqu'un qui sait de quoi il parle. Merci. J'ai eu le même réflexe : sortir la console de dev, et oui, le mot de passe est envoyé en "clair" dans une requête POST... Mais on est en HTTPS donc, pas de soucis.
Mea culpa : le fonctionnement précis du login Facebook est plus complexe et je ne le connais vraiment pas.
Le point important est qu'il s'agit là d'une solution classique pour l'authentification numérique sécurisée.
Il existe d'autres variantes possibles, comme la méthode des hashs de Lamport, qui consiste à révéler hash(hash(hash(....(hash(mot de passe)))) = hash^1000(mot de passe).
Puis pour certifier notre identité, on peut révéler hash^999(mot de passe), qui devient alors public.
Puis pour recertifier notre identité, on peut révéler hash^998(mot de passe)... et ainsi de suite.
C'est pourtant pas dur de se documenter sur SSL/TLS AVANT de faire une vidéo sur le sujet .... RFC 6101,5246,8446 fr.wikipedia.org/wiki/Transport_Layer_Security
"hashs de Lamport, qui consiste à révéler hash(hash(hash(....(hash(mot de passe)))) = hash^1000(mot de passe)" WHAT ?! Je ne sais pas où tu as lu ça mais d'une part la page Wikipédia ne décrit pas du tout cet algorithme (fr.wikipedia.org/wiki/Signature_de_Lamport) et d'autre part si c'était bien basé sur une série d'étapes de hashage, la sécurité serait totalement compromise par des collisions en cascade - c'est à proscrire ! Genre vraiment, j'insiste ! Ne faites jamais ça !
Bonjour Lé. Bizarre, j'ai testé de m'authentifier sur Facebook via zaproxy depuis mon navigateur et ho surprise ds le flux https, le mot de passe est envoyé... en clair!!! Dans quelles conditions un mécanisme complexe d'authentification est il utilisé par Facebook ?
Heu, 1:05 :"pour les vieux parmis vous" . Wouah ! Un "pour les plus anciens parmis vous" MERCI..... et pis d'abord ça existe encore les chèques, non mais 😅.
Bon ça nous arrive encore de faire des chèques vous savez ^^ Que ce soit des cautions ou autre par exemple ! Mais il est vrai que justement pas mal de magasins les refusent car ils ne sont pas assez sécurisés justement.
Ouais... ça c'est la théorie. Et sinon, en pratique, comme on l'a appris le mois passé, Facebook stocke (a stocké) sur ses serveurs internes des centaines de millions de mots de passe en clair accessibles à des milliers de ses employés...
En effet prendre Facebook comme exemple n'est pas la meilleur des idées...
Comment ça "à l'époque des chèques" ???
Adobe acrobate pour c/C de signa numérique ?
1:05 pour les vieux parmis vous........hummm, pas trés heureux.
Les gens proche de la mort, c'est mieux? xD
Les gens qui vont chez le médecin généraliste qui ne prend pas la carte bleue...
Les gens qui ont dans leur téléphone les numéros de leur médecin, de leur dentiste, de leur ophtalmo, de leur pharmacien, etc.
les vieux ???!!! et la vieille alors ? bandes de ptits cons XD
Dès le début : "Certification digitale"
Sauf que "Le terme digital est l'adjectif associé au substantif doigt (exemple: tracé digital; empreinte digitale; comput digital)." (Merci Wikipedia)
On dirait plutôt "Certification numérique"
«Vous vous êtes déjà demandé ce qui se passe lorsqu’on rentre le mot de passe sur FaceBook ?»
Non. Je pense que la plus part des personnes ne se posent pas ce genre de questions...
Mais... si on regarde ta vidéo, c’est qu’on est intéressé ! 😬
Merci pour ta vidéo.
Je crois que j'ai tout compris, merci !
Bon, alors, les vieux vous signalent qu'en 2019, on peut encore payer par chèque... C'est pratique, notamment pour s'acheter des trucs entre particuliers. Parce que, bon, perso, je prends toujours pas la carte bleue, mais les chèques, oui.
(C'était la minute vieux, je vous laisse entre jeunes...)
Super vidéo !
Pourquoi tu t'es doublé ? Le micro a merdé au tournage ? Ou alors la synchro dans le logiciel de montage ? Ça fait bizard a regarder.
En fait, je veux dire que je trouve que le son ne correspond pas toujours à l'acoustique pré supposé du lieu.
Pour les vieux parmi vous ... ça, c'est fait ;) merciiii (très intéressant sinon).
Je suis 100% d'accord avec la vidéo jusqu'à 5:55 ... Pour faire ce qui serait décrit à la fin il faudrait que Facebook stocke notre mdp en clair ? Sinon l'utilisateur applique au mdp la fonction de hash avant d'effectuer la signature mais alors cela signifie que Facebook stocke des équivalents de mdp en clair ? (Comme les hash ntlm sous Windows... cf attaque passthehash).
J'avoue que je ne vois pas comment Facebook réaliserait cela !!! Qlq'1 a des liens SVP ? Ce qui est expliqué avant correspond plus à l'authentification/échange de clé ssl/tls du serveur par le navigateur qu'a l'authentification de l'utilisateur par le serveur.
Non. Il suffit que FB ai la clef publique associée a la clef privée qui est générée a partir de notre mot de passe.
Facebook n'a pas besoin de notre mot de passe en claire.
En général il le stock en MD5.
Mais entre temps le mot de passe aura voyager sous une autre forme de clé.
Il à besoin seulement que la clé envoyé même hashé soit égale à la clé reçu (hashé également). Qui elle même est crypté via une clé.
Comme ça le mot de passe n'est jamais donner en claire. Mais bon, comme dis un mot de passe que tu l'as en brute ou en MD5 c'est pareille.
Si tu veux plus d'information on appel cette methode *Challenge-response authentification*
Wikipedia EN: en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication (l'article en anglais et meilleur que celui FR)
Wikipedia FR: fr.wikipedia.org/wiki/Authentification_d%C3%A9fi-r%C3%A9ponse
Tu peux aussi juste chercher le nom de de la methode sur un moteur de recherche pour avoir plein de liens
Euh il y a une grosse confusion entre les clefs de chiffrement et les mots de passe.
La connexion HTTPS s'effectue normalement avec l'histoire de clef pubilque et privée.
Le mot de passe est envoyé via le tunel SSL tel quel, facebook le compare à ce qu'il y a dans la base de donnée (et sans le chiffrer ! il est même pas chiffré en base de donnée d'après la dernière fuite)
Pour savoir si l'utilisateur reviens, c'est juste une session bassée sur un grand chiffre dans les cookies.
Bref le mot de passe sur facebook a la même gestion qu'un site fait par jean-kikoo-du-92 (sauf l'infrastructure qui est plus résistante aux attaques)
Punaise, le "pour les vieux parmi vous" je l'ai trouvé un peu raide celle-là ^^
Heureusement qu'il existe encore des chéquiers sinon j'aurais été qualifié de 3 ème âge :D
Ah ah la punchline pour les vieux et les chèques 😂😂😂
Elle est bonne mais ca match pas avec le ton sérieux...
Bon sinon je suis surpris du nombre de commentateurs qui utilisent encore des chèques...
Au sein de mon école, les cotisations aux assos, c'est par chèque... On a entre 19 et 23 ans et a priori on a tous un chéquier, même si c'est pas une utilisation quotidienne c'est toujours utile.
Pour les chèques en début de vidéos je ne comprend pas trop. Un paiement est bien un transfert d'argent, du coup les chèques existent encore et sont toujours utilisés. Donc je ne pense pas que ce soit un problème d'âge de connaître les chèques ou non, mais plutôt du "monde" dans lequel on évolue. Mes neveux de 14ans connaissent les chèques et savent en remplir.
J'ai l'impression que l'on parle d'un mode de paiement qui a pris fin dans les années 60. Cela dit, ca montre que je suis largué...comme mes parents l'ont été à une époque. Affaire à suivre !!!
regarde a quelle date la belgique a arreté les chèques et pt que tu seras moins largué
@String Theory FR Vous êtes une chaîne Suisse? (d'ou le sponsor par l'EPFL??? (Ecole polytechnique fédérale de Lasanne)))
🤪🤪🤪L'ancien logo de l'epfl !!!
MERCI ! :)
Et bonne continuation a cette chaine également !
Hum, mais où sont les sources ? :)
Bien qu'intéressant, il n'y a pas de système de signature numérique a l'aide d'une clef qui pourrait être dérivée du mot de passe sur l'interface de connexion de facebook :/
C'est justement ce que je me demandais, je ne connais pas le protocole de facebook c'est interessant de savoir si ils utilisent du challenge-response authentication. Par ailleurs ça serait une bonne idée de leur part pour permettre des connexion via le compte FB sur d'autre platforme.
PS: ça fait quand meme un bon exemple au pire
De ce que je vois sur la page d'authentification de facebook, le login/password est envoyé tel que au serveur (avec quelques meta données de tracking (no kidding ;))
Exercice interessant, par exemple avec l'algorithme de signature EdDSA (RFC 8032) il est possible de générer une clef publique et une clef privée a partir d'une graine de 32 octets. On pourrait donc, lors du choix du mot de passe, le dériver avec PBKDF2 afin d'obtenir la graine de 32 octets, générer les deux clefs et envoyer à FB la clef publique.
Lors de la phase d'authentification, FB envoie un challenge et l'utilisateur entre son mot de passe dans l'interface. A ce moment là le navigateur peut regénérer la clef privée à partir de ce mot de passe en suivant le meme algorithme qu'avant et ensuite signer le challenge. Il suffit ensuite d'envoyer a FB le challenge signé et FB peut vérifier la signature pour authentifier l'utilisateur.
Bien compliqué pour très peu de gain :/
Effectivement, vu que c'est du challenge-response, si la transmission TLS est compromise, le mot de passe ne transite pas. Et comme le mot de passe ne transite pas, ça eviterai peut-être qu'ils le stoquent en clair dans leurs logs ;-)
Il faut bien faire attention à ce que l'algorithme qui passe du mot de passe à la clef publique soit suffisamment gourmand en ressource, sinon en cas de leak de cette clef publique, il deviendrait presque trivial de faire une attaque par bruteforce sur le mot de passe. C'est pourquoi on utilise des algorithmes comme bcrypt pour générer de manière sécurisée les empreintes des mot de passe qui sont stoquées en base de données.
Ne pas oublier de rajouter aussi un peu d'aléa (un sel qui pourrait être dérivé d'un ID d'utilisateur) car sinon, si deux utilisateurs utilisent le même mot de passe, ils auront la même clef publique ... Et donc sans connaitre leur mot de passe, en cas de leak de la base, il est facile de voir quel(s) utilisateur(s) utilisent le même mot de passe. De ce fait, on sait lequel on va essayer de casser en premier: en cas de réussite on a gagné plusieurs comptes et si c'est le même, il y a une forte chance qu'il soit trivial :)
@@toms2809 "le login/password est envoyé tel que au serveur (avec quelques meta données de tracking (no kidding ;))"
Sans surprise.
" Bien compliqué pour très peu de gain :/"
La securité des users c'est gros gain normalement x) ... mais bon on parle de facebook.
Sinon l'avantage une unification des methodes de connexion à plusieur platforme avec un seule compte. Par exemple avoir la meme clé publique utilisé par google, facebook, twitter, ... pas besoin d'etre facebook pour verifier que le challenge response est validé, il suffit d'une clé qui est publique et donc accessible a tout le monde (toute les platformes).
"Effectivement, vu que c'est du challenge-response, si la transmission TLS est compromise, le mot de passe ne transite pas. Et comme le mot de passe ne transite pas, ça eviterai peut-être qu'ils le stoquent en clair dans leurs logs ;-)"
Si le TLS et compromis (par une attaque non passive) il est possible d'injecter du code qui va leak les passwords directement depuis la page web ou on rentre le password.
"Il faut bien faire attention à ce que l'algorithme qui passe du mot de passe à la clef publique soit suffisamment gourmand en ressource, sinon en cas de leak de cette clef publique"
Je pense que tu tiens là la raison pour la quelle facebook ne fait pas ça:
Tout l'interet du challenge-response c'est de pouvoir diffuser une clé *publique* qui sera visible par tout le monde. Mais dans des cas classique de challenge-response on ne derive pas les paires de clé depuis un petit password mais plutot derivé depuis un passphrase pour etre resistant aux attaques bruteforce par dico ou alors simplement avec des seeds random qui sont elles aussi ressistantes aux attaques bruteforces.
C'est donc imcompatible de diffuser publiquement une public key derivé depuis un password pour securiser une authentification. tout les gens avec des password simple se ferait casser leur password tres rapidement car il suffit de tester aleatoirement, et en local, des passwords tres rependu sur des listes de publique key (qui sont publique donc accessible a tout le monde). On peut bien mettre un algo un peu lourd, ou qui s'adapte comme bcrypt, de toute façon comme la bdd est publique le travail et simplifier.
Il serait preferable de mettre en place des protocoles de challenge response auth avec des paires de clé pri/pub à seed aleatoire qui doivent donc etre stocké sur du hardware secu comme les clé yubico par exemple. Ou alors avec des passphrase.
Je sais pas si tu es d'accord avec moi, mais je pense qu'on a trouvé la raison qui explique pourquoi facebook ne fait pas de challenge response sur les passwords. Il n'y a aucun interet si c'est pas pour avoir des clés vraiment publiques, or avoir des clés vraiment publiques est imcompatible avec des clés derivés depuis des passwords.
Il existe une méthode d'authentification en deux temps qui consiste à envoyer un challenge et sa clef privée cryptée à l'utilisateur qui vient d'entrer un login et d'attendre que l'utilisateur déchiffre la clef et l'utilise pour répondre au challenge.
Ça se bien fait avec les CryptoAPI des navigateurs.
Mais ça veut dire qu'on peut attaquer une clef offline...
Il y a aussi autre chose a prendre en compte ... avec un système de d'authentification avec clef publique tel que tu le décris, tu obtiens un super moyen de tracker tous les utilisateurs.
Comme tu utilise la même clef chez FB, Google, Amazon, etc... il n'y a plus rien qui les empêche de mettre en commun leurs informations pour savoir que c'est la même personne physique derrière les comptes sur toutes les plateformes... et ça c'est pas cool.
C'est d'ailleurs pour ça que certains mécanismes d'authentification en challenge-response par exemple WebAuthn, génèrent une clef publique différente a chaque inscription pour garantir un certain niveau de confidentialité
Quoi? C'est la 1er fois que me traite de vieux parce que j'utilise des chèques!! donc dès qu'on dépasse 35ans il faut un déambulateur ? j'étais a 2doigts de t'envoyer un chèque pour soigner ton acné! Et ne compte pas être invité aux soirées crêpes dans les EHPAD... sur ce bonne soirée, un tisane camomille, un supo et au lit!! (je met un like quand même avec ma souris payé par chèque...)
est-ce que ça veut dire que si on déchiffre avec la clé publique de l'utilisatrice, on trouve un document signé par le mot de passe ? c'est débile non ? j'ai du raté quelque chose...
non, le mot de passe c'est la clé privé, cette clé reste de ton coté (c'est pour ça qu'elle est privé), jamais tu ne la transmet.
Ce que tu transmets ne contient pas ton mot de passe (c'est peut-etre un peu ambigue dans la video) cela contient simplement la donné aleatoire que t'as envoyé facebook mais que tu as chiffré en utilisant ta clé privé.
Pour verifier si le mot de passe est bon il suffit alors d'utiliser la clé publique (que tout le monde à le droit de connaitre) pour dechiffrer les donnés aleatoires. Une fois déchiffé FB peut verifier si le contenu est identique à ce qu'il a demandé.
Comme cette donné aleatoire ne sera utilisé qu'une fois par utilisateur, cela empeche de reutiliser cette signature.
Par contre je doute que FaceBook pratique vraiment cela de cette maniere, mais cela fonctionnerait en tout cas ^^.
PS: pour etre precis, c'est pas que le mot de passe c'est la clé privé, c'est que la clé privé et publique sont generé à partir du mot de passe, mais c'est un detail =)
moi je dis .... y a pus de respect décidément :x 1:02
en gros les mots de passe servent à sécuriser un compte par exemple pour pouvoir se connecter en toute "sécurité" hein ? :')
Pourquoi tu parles des chèques au passé ? Ca existe encore ! ^^
les banques fournissent de moins en moins de chèques sauf en cas de demande, c'est le cas pour les banques en ligne.
enfin les commerces bannissent ce moyen de paiement donc oui on peut parler des chèques au passé
Dis donc gamin! Tes parents ne t'ont pas appris le respect? C'est quoi ces sous-entendus sur l'âge de Florence?
Chouette vidéo sinon 😉
J'ai bien peur qu'il y ait plus de vieux que tu ne l'imagines dans tes abonnés.
Sinon, tu devrais sortir un peu, parce que les chèques, ça existe toujours, ça s'utilise encore beaucoup.
Et je connais bien plus de gens qui se font avoir dans leur vie numérique que dans leur vie papier !
A part ça, merci pour tes videogrammes petit galopin !
J'ai entendu ça comme une vanne, l'air de rien. Gratuite, certes, mais pas méchante.
" à l'époque des chèques" Hey, ils existent toujours. ;)
Trop d'approximations, de raccourcis, et de références inutiles à Facebook...
J'ai une question (pas forcément dans le cas de Facebook) : Comment fait-on pour être sur que la clée publique de Florence soit bien émise par Florence ? N'y a-t-il pas moyen d'émettre une fausse clée public et un document l'or à cette clé ?
La clé publique n'est pas emise à chaque fois en faite. Elle est stocké dans les base de donné de facebook. On sait donc qu'elle est valide car elle etait valide toute les fois d'avant.
C'est biensur toujours la meme paire de clé publique/privé qui est utilisé a chaque connexion. (en realité cette paire de clé est generé a partir du mot de passe, comme ça si on change le mot de passe ça change la clé publique et privé)
Le probleme est donc de savoir si c'est la bonne clé publique qu'on a recu la premiere fois ;) Et pour ça il faut que l'inscription se fasse de manière securisé.
Pour cela on utilise les meme type de protocole mais en un peu plus complexe avec des certificats qui cerifient d'autres certificats.
Sauf que au bout de la chaine, il y a un certificat qui est produit par une source consideré comme sûre, qui fait autorité.
Cette source sur est souvent une entrprise dont c'est justement le corps de metier. Si quelqu'un arrive a imiter cette autorité de certification alors ce n'est pas que ton compte Facebook qui n'est plus sur, c'est tout le monde,et on s'en rendrait compte tres vite. Il serait alors facile d'invalider tous les certificats de cette autorité =) (la revocabilité d'un certificat c'est important aussi)
Autant te dire que pour pirater ton compte facebook il est impensable d'essayer d'attaquer une autorité de certification ;)
Par contre dans des domaines tres critiques (l'armement par exemple) on ne veut pas dependre de ces autorités, on peut alors faire les echanges de clé directement de maniere physique. Par exemple sur une clé USB chiffré.. (enfin on a du hardware pour faire des choses secu ;))
@@Arthur-qv8np Merci beaucoup
@@Arthur-qv8np Dans le domaine de l'armement, on veut dépendre d'une autorité qu'on maîtrise. L'armée française utilise l'autorité de l'armée française.
Très intéressant. Merci et bravo (ps : perso, je n'ai jamais imité la signature de mes parents... mais j'en connais des ... ah ah ah). Vidéo très intéressante, bourrée d'humour et instructive. Merci.
Dommage que la vidéo commence à @5:58
Le terme Digital (WTF)
La blockchain en solution décentralisée n'est pas la solution #attaquedes51%
Merci tout de même pour la vidéo
J'ai rien compris
Un peu trop courte.
Le nombre de commentaires à propos des chèques et des vieux ....😂 je lui en rajoute pas une couche, je crois "qu'il esr habillé pour l'année "... une expression de "vieux" ? 😉
Whaou la blockchain est vraiment parfaite pour la solution de la signature grace à sa clé privé + le hachage
la blockchain c'est cool mais il nous manque toujours un *consensus protocol* qui fonctionne et qui ne consomme pas autant d'energie que la proof of work utilisé sur dans presque toute les crypto currency. Peut-etre la proof of stack mais c'est pas evident.
Donc en attendant il faut pas trop se hyper ^^
Je crois que je n'ai rien compris ... Comment en être sûr?
Si tu n'es pas capable de le re-expliquer c'est que tu n'as rien compris x)
Bin non, moi j'ai jamais signé à la place de mes parents.
Ce Facebook là : www.journaldugeek.com/2019/04/04/facebook-nouvelle-fuite-de-donnees-540-millions-dutilisateurs ? ^^"
Je dis non, non, no et NON !!
L'explication se veut intéressante et sérieuse mais pert toute crédibilité en moins de 40 second. Pourquoi ???
"...la certification DIGITALE..."
NUMERIQUE BORDEL !!!!!!!
tu dis à l'époque des chèques, mais les chèques existent toujours -_- sinon tres cool la vidéo
#Blockchain ... voui ... avec une centrale nucléaire aux fesses pour alimenter les ordi qui permettent le calcul (au moins pour le minage, mais pas que)... Pas sûr que ce soit très efficace tout ça ;-)
Ca peut être intéressant de parler de cet aspect, y compris (surtout ?) pour me montrer si/où je me trompe.
le probleme du consensus protocol =)
Je fais encore des chèques.
Il est vrai que je suis très vieux...
snif
j'adorerais aller à l'epfl !!!
Très déçu par cette vidéo... Autant, d'habitude, les épisodes CRYPTO sont intéressants mais là... Certes la signature numérique réalisée via chiffrement asymétrique est bien expliquée, mais le titre de la vidéo est méga putaclic et on fait un survole express du "sujet" en 20s en fin de vidéo, complètement bâclé, qui laisse très perplexe, jusqu'à la véracité de ce qui est annoncé... L'intro est également hyper bancale...
Et si on pirate une boîte mail (genre free) et que l’on dit qu’on a oublié mon mdp de fb... je parle d’expérience.
Je signais à leur place seulement quand ils avaient trop la flemme de signer ^^
merci pour les vieux......
lol
très bonne vidéo
*1er commentaire (je crois)*
taggle
Tiens ... Science4All ;-)
Moi j’ai pas fait pause 😎
Le vieux il t'emm**** naméo.... ;)
Très déçu par cette vidéo. Le titre ne correspond pas au contenu.