Sur Ethereum, une plateforme décentralisée de craquage de mots de passe

Sur Ethereum, une plateforme décentralisée de craquage de mots de passe

#CryptoFrenchTech

Avatar de l'auteur
Guénaël Pépin

Publié dans

Internet

04/08/2017 12 minutes
36

Sur Ethereum, une plateforme décentralisée de craquage de mots de passe

Financer le craquage légitime de mots de passe, en s'appuyant sur une place de marché totalement décentralisée. C'est l'objectif du Blockchain Password Market, un prototype ouvert il y a quelques semaines s'appuyant sur des technologies expérimentales de la blockchain Ethereum. Son créateur, Renaud Lifchitz, nous en parle.

Fin juin, à l'occasion de la 15e édition de la Nuit du hack, le chercheur Renaud Lifchitz présentait un projet en gestation depuis plusieurs mois. Son but : créer une place de marché pour le craquage de mots de passe, fondée sur Ethereum sans la moindre partie centralisée, avec le luxe d'une interface web pour les utilisateurs. Il s'agit du Blockchain Password Market, au prototype accessible à bzz:/passwords.eth via un navigateur Ethereum.

La plateforme est fondée sur un smart contract Ethereum, un programme tournant sur les 21 000 nœuds du réseau. Le principe : si une condition est remplie, le contrat déclenche automatiquement une action. Ici, un internaute envoie une empreinte (hash) de mot de passe à craquer pour retrouver l'original. Si quelqu'un envoie la bonne réponse de passe et que le réseau le vérifie, le contrat se déclenche et paie la récompense choisie par le propriétaire du hash (moins 5 % de commission pour la plateforme). Tout est automatisé, avec très peu de maintenance.

Le contrat est accompagné d'une interface web et d'un nom de domaine, fournis par des outils basés sur Ethereum. La plateforme est aussi l'occasion de s'essayer au craquage de mot de passe via des cartes FPGA, à l'efficacité redoutable pour certaines tâches et au coût réduit, au prix d'une programmation bien particulière. Au fait, pourquoi se lancer dans un tel projet ?

Tester la solidité de mots de passe d'outils exposés

« En audit de sécurité, il est régulier de tester si les mots de passe des clients sont suffisamment robustes. Or, dans une mission d'une ou deux semaines, on n'a que quelques jours pour voir si l'un d'eux est solide. On ne déploie pas de moyens phénoménaux, on utilise un ordinateur avec une carte graphique » nous détaille Renaud Lifchitz. Ces moyens sont bien éloignés de ceux que peut mettre en œuvre un attaquant motivé sur une cible à forts enjeux, qui a beaucoup plus de temps entre les mains.

« Là, l’idée était de mettre à l'épreuve la solidité de mots de passe de manière complètement ouverte et d’y inciter les gens, en y mettant des primes. C’est ce qui donne envie aux gens de participer et de donner de la puissance de calcul pour tenter de casser » détaille Lifchitz. Attention, il n'est pas question d'y envoyer des mots de passe de clients pendant un audit. Le risque est trop grand, notamment si le texte contient des éléments identifiant l'entreprise ou l'employé.

« La plateforme pourra plutôt être utilisée pour du craquage collaboratif sur un système ouvert sur Internet (caméra, routeur…). J’ai un appareil exposé, j'ai un mot de passe, je veux vérifier s’il est assez fort, je le soumets » estime le chercheur, qui dit avoir eu le déclic pour la Nuit du hack, où il présente régulièrement ses projets.

« Je trouvais ça intéressant pour la Nuit du hack, qui combine la sécurité à des aspects hack (détournement de technologies) et do it yourself » détaille-t-il. La motivation était aussi de concevoir une plateforme entièrement décentralisée, donc résistante à certaines attaques comme le déni de service distribué (DDoS). Soit quelque chose encore très rare aujourd'hui, voire inédit.

Quid des détournements ?

Craquer des mots de passe peut aussi intéresser des acteurs moins sympathiques que des chercheurs ou responsables de la sécurité.  Le spécialiste reconnaît de possibles détournements, par exemple par une personne qui veut se propager sur un réseau, en disposant uniquement du hash d'un identifiant important.

« Mais les outils de craquage de mot de passe sont déjà existants, en ligne », comme des forums, souligne-t-il. Même en étant relativement anonyme, la nouvelle plateforme ne devrait donc pas changer grand-chose, si elle venait à attirer un large public, selon son concepteur.

Aussi, que se passe-t-il si quelqu'un craque un mot de passe sans le signaler ensuite sur la plateforme ? Le scénario serait peu probable. « Je pense que si quelqu'un voit un hash arriver, son intérêt est d’avoir la prime. Il ne sait pas qui le soumet donc il ne sait pas d’où il vient (quel service, quel annuaire utilisateur, quelle utilisation...), d'autant qu'il sera vu par pas mal de monde. A priori, l'outil permet d'essayer plus de stratégies que vous seul, dans votre coin » répond le spécialiste.

Renaud Lifchitz plateforme Ethereum
Crédits : Renaud Lifchitz

La décentralisation comme objectif

La place de marché est constituée de trois éléments. Le moteur (backend) est un smart contract Ethereum classique. L'interface web, censée permettre d'interagir avec le contrat, est hébergée via Swarm, une technologie en plein développement. Le nom de domaine bzz:/passwords.eth est, lui, obtenu via l'Ethereum Name Service (ENS).

« Le frontend utilise une fonctionnalité en bêta, Swarm, encore peu connue. C'est une technologie de stockage distribué, sur l'ensemble des nœuds qui en sont équipés. Le système est similaire à IPFS (Interplanetary Filesystem), à la différence qu'il ne s'agit pas d'un stockage volontaire (où l'on choisit où héberger les données) mais sur tout le réseau » explique Renaud Lifchitz, qui estime qu'entre 500 et 1 000 nœuds disposent du Swarm.

Comment donc retrouver un contenu ? « Il n’est pas adressable par une adresse IP ou une URL, mais un hash lié. On adresse le hash. Peu importe le nombre de nœuds le possédant, on télécharge les morceaux sur tous ceux qui l'ont, en mode pair-à-pair. » Pour le moment, l'interface web n'est pas fonctionnelle, mais uniquement là à titre informatif. Elle se base sur web3.js, une bibliothèque JavaScript qui permet d’interroger la blockchain depuis une page web.

L'adresse bzz:/passwords.eth passe, elle, par l'ENS. « Cette résolution de noms est aussi décentralisée, via un smart contract normalisé (ENS). Il va répondre avec une adresse (hash) de contenu décentralisé, smart contract ou wallet » nous détaille encore Lifchitz.

Comment y accéder ? 

Pour accéder à la place de marché, en interagissant directement avec le smart contract ou en passant par l'interface web (en construction), il faut obtenir un client Ethereum. Parmi les « lourds », qui peuvent constituer un nœud du réseau, Lifchitz recommande l'officiel Ethereum Mist ou son concurrent Parity.

Des clients plus légers, comme l'extension navigateur MetaMask, permettent d'interagir facilement avec un smart contract, sans pour autant donner la possibilité d'accéder à des sites Swarm. Il existe enfin des passerelles publiques vers Swarm à partir d'un navigateur classique, à l'image de swarm-gateways.net.

 

Quelques limites concrètes sur Ethereum

Si le prototype du Blockchain Password Market fonctionne, il subit les limites d'Ethereum. La principale est que seules les empreintes d'un mot de passe créées avec l'algorithme SHA-256 sont autorisées. C'est le moyen standard actuel de créer des hash, alors que des outils plus anciens, comme SHA-1 et MD5 sont considérés comme obsolètes.

Pourquoi cette limite ? Pour une question de coût. Au moment de vérifier qu'un mot de passe « craqué » correspond bien au hash de départ, le smart contract effectue l'opération sur les nœuds du réseau Ethereum. La puissance de calcul utilisée pour exécuter un smart contract est rémunéré en « gas », le coût d'une opération, versé aux mineurs.

« Il faut payer la puissance de calcul mobilisée pour faire tourner ce smart contract sur toutes les mailles du réseau. Faire tourner la vérification sur des dizaines de milliers de serveurs se paie, sinon n’importe qui pourrait faire n’importe quoi » rappelle Lifchitz.

SHA-256 est intégré directement à la machine virtuelle Ethereum, donc effectuer des opérations avec cet algorithme coûte peu. « Il y a déjà une instruction pour calculer un hash SHA-256 dans ma machine virtuelle Ethereum. Les smart contracts sont du bytecode. J’ai simplement appelé cette instruction pour vérifier la validité du mot de passe » explique le spécialiste. Avec un autre algorithme, comme MD5 ou SHA-1, il faudrait réécrire les instructions nécessaires à la vérification, créant une usine à « gas » très consommatrice, donc onéreuse.

Pour sortir de SHA-256, passer par un oracle ?

Pour le concepteur de la plateforme, une solution pourrait être de passer par un oracle, comprendre une passerelle qui permet d'interroger des services en dehors de la blockchain Ethereum, comme la météo ou des résultats sportifs.

« Il serait donc possible de faire le calcul de hash sur un service web classique et d’utiliser un oracle pour vérifier le hash, sans contrainte de « gas » » pense Lifchitz. Problème, ce serait s'appuyer sur un outil centralisé extérieur à la chaine de blocs, ce qui va à l'encontre du principe de la place de marché. Une autre piste peut être d'attendre qu'Ethereum intègre les autres algorithmes de hash voulus, à une échéance indéterminée.

Il n'est pas dit que le projet évolue beaucoup, dans l'absolu. Il a germé pendant six à huit mois, demandant cinq à dix jours intensifs de développement, dont les 100 lignes de code du smart contract, le cœur du système qu'il s'agissait de blinder. Suivant la blockchain « depuis presque six ans » et Ethereum depuis environ deux ans, il a été marqué par les ratés de grande envergure qu'ont connu d'autres plateformes fondées sur Ethereum, comme le célèbre The DAO, une entreprise dont 50 millions de dollars ont été siphonnés à cause d'un smart contract mal ficelé, obligeant à un « hard-fork » de cette blockchain.

Le langage des smart contracts peut lui-même réserver des pièges. « Solidity est un langage très proche de JavaScript, plus fortement typé, orienté objet » retient Renaud Lifchitz, pour qui la centaine de lignes de son contrat a demandé quelques jours de réflexion. Il faut dire qu'une fuite de 30 millions de dollars, de la société Parity, s'est jouée à un mot oublié dans le smart contract multi-signatures gérant leur ICO (sorte de levée de fonds). La prudence est donc de mise. 

Une carte pour craquer des mots de passe

Côté programmation pourtant, le plus grand défi n'a pas été celui-ci. Il était du côté de la carte FPGA utilisée pour concevoir un craqueur de mots de passe hashés en SHA-256. Renaud Lifchitz affirme qu'il lui a fallu deux ans de « curiosité intensive » pour bien s'en servir, avant de lancer son projet, qui a permis de mettre en pratique son apprentissage.

Une carte FPGA est un outil très spécialisé, qui se présente sous une forme équivalente à celle du Raspberry Pi. Celui utilisé par le chercheur, le Digilent PYNQ-Z1, peut être obtenu à 100 ou 200 euros. « Pour 100 euros de FPGA, on peut battre une carte graphique sur certains calculs et s’amuser à programmer » résume-t-il. Il s'agit d'un circuit reprogrammable sur lequel « on câble physiquement l'algorithme », pour obtenir extrêmement rapidement son résultat. La seule énergie utilisée est celle nécessaire à l'action voulue.

Certains algorithmes s'y prêtent bien mieux que d'autres : « Cela peut battre un CPU multi-cœurs, à condition que ce soit du binaire pas trop complexe », comme le DES ou 3DES. Il reste que le paradigme de développement diffère grandement de celui d'un projet logiciel classique. Ici, au lieu de se suivre automatiquement, les instructions peuvent s'exécuter en même temps. Il faut donc tout orchestrer très précisément.

D'ailleurs, le problème n'est pas le craquage de mots de passe hashés en SHA-256, des blocs existant déjà, pour être installés sur tous les ports physiques libres de la carte au besoin, pour multiplier la vitesse de traitement. Non, « la difficulté est d’instrumenter ce bloc et de faire les entrées sorties du FPGA. Tant que tout est en interne, avec des paramètres statiques, c'est simple » explique notre interlocuteur. Faire entrer un hash et récupérer le mot de passe est le plus compliqué. 

« Il faut des modules pour gérer de l'USB, du port série (UART), lire les entrées utilisateur (au niveau utilisateur, en base 10 ou ASCII, il faut un module de conversion)... C’est déjà extraordinairement complexe ! » affirme-t-il, jugeant ce travail « extrêmement fun et formateur ».

Deux mots de passe déjà obtenus

Pour la Nuit du hack, il a mis en ligne quatre mots de passe à casser, pour un total de 120 euros de récompense. Un « password bounty » en somme. Deux ont été trouvés : « toto » en moins d'une journée et « AleaJactaEst » en quelques jours. « La difficulté était plus d’interagir avec le smart contract que de casser le mot de passe » pense notre interlocuteur. Deux autres, plus longs et plus complexes, attendent encore leurs sauveurs.

La suite est encore indéterminée. Suite à la conférence, fin juin, une développeuse s'est proposée de finaliser l'interface web. La fin de l'année sera déjà un jalon important. C'est à ce moment qu'est attendu Ethereum 3 et, potentiellement, la version finale de Swarm, l'outil qui héberge ladite interface. Au passage de la version bêta à la stable, il se peut que tous les contenus aujourd'hui stockés gratuitement par les nœuds du réseau soient supprimés, pour passer à un modèle rémunéré. Les 5 % de commission demandés sont (entre autres) une anticipation de ce changement.

Pour le moment, la plateforme n'a pas encore enregistré de soumission de nouveau hash. La seule présentation (en français) a été celle de la Nuit du hack. Une communication plus large pourrait suivre, notamment avec la diffusion du code source du smart contract. Si le but n'est pas de dépasser le stade du prototype, seul l'avenir dira si cette plateforme décentralisée percera dans le monde de la sécurité informatique.

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Tester la solidité de mots de passe d'outils exposés

Quid des détournements ?

La décentralisation comme objectif

Comment y accéder ? 

Quelques limites concrètes sur Ethereum

Pour sortir de SHA-256, passer par un oracle ?

Une carte pour craquer des mots de passe

Deux mots de passe déjà obtenus

Commentaires (36)


Ca me fait penser à certains messages dans “certains lieux” demandant à ce qu’un compte soit cassé contre paiement…



D’accord, on met en avant un truc bien sous tout rapport s’appuyant sur une “communauté” pour faire de la recherche et de l’audit de sécurité. Blablabla… Mais la question du paiement (et de la com de la plateforme au passage), me fait furieusement penser à certains marchés qui existent dans l’ombre “marketé” avec un plan de communication pour faire bien ni plus ni moins… 


La, on ne te demande pas de casser un compte, mais un hash ce qui est différent

Un site qui expose des tables de hash n’a rien d’illégal


Le hash, c’est pas le truc que tu envoie pour t’authentifier et qui est comparé avec la bdd?

Du coup, si tu as la correspondance entre hash et mdp, tout site non https devient vulnérable?



Je ne maîtrise pas le détail de  d’authentification, mais si quelqu’un pouvait m’éclairer ce serait sympa, car ça semble super limite comme truc.


Le client (navigateur) envoie le mdp en clair (via HTTPS normalement) et c’est le serveur qui génère le hash et le compare à celui de la BDD.



si le client envoyait le hash directement, le fait de stocker le hash en BDD n’aurait aucun intérêt niveau sécurité.


Avoir récupéré un hash, c’est déjà être sur le système, et c’est ça qui est illégal sans autorisation !



Par ailleurs la plateforme n’apporte rien de plus en termes d’anonymat par rapport à la blockchain en général, c’est à dire un anonymat relatif (on parle plus de “pseudonymat”). Ca n’a donc rien d’un darkmarket. Les primes sont là pour encourager les gens à donner de la puissance de calcul inutilisée, ni plus ni moins.



Renaud (le créateur de la plateforme)

 








PtiDidi a écrit :



La, on ne te demande pas de casser un compte, mais un hash ce qui est différent

Un site qui expose des tables de hash n’a rien d’illégal





Certes tu as une étape en plus, récupérer le hash. Ce n’est pas rien mais tu peux déjà en trouver pas mal sur le net, encore récemment avec un site d’extrême droite qui a récupéré et publié les mails & hash de personnes sur des services en ligne (très mal sécurisés au passage) de groupes religieux ou “d’appartenance philosophique”.

Ces derniers s’amusaient à péter les comptes pour y récupérer état civil, adresse, téléphone etc… Nul doute qu’ils n’hésiteraient pas à utiliser le service en cause si besoin.



D’accord, d’autres services le font, mais précisément ils n’ont pas de discours putassié sur la légitimité du hack… Soit c’est gratos et sauf une mise en garde y a rien, ou alors c’est payant et le service ne cherche pas à faire de discours moralisateurs mais simplement à ne pas laisser de trace.



D’ailleurs, à quoi bon s’escrimer à décentraliser le bousin s’ils visent que du hack légitime sinon à ne pas faire dans le détail en partant du principe que le légitime ou non on prend notre com au passage ?









nono2357 a écrit :



Avoir récupéré un hash, c’est déjà être sur le système, et c’est ça qui est illégal sans autorisation !



Par ailleurs la plateforme n’apporte rien de plus en termes d’anonymat par rapport à la blockchain en général, c’est à dire un anonymat relatif (on parle plus de “pseudonymat”). Ca n’a donc rien d’un darkmarket. Les primes sont là pour encourager les gens à donner de la puissance de calcul inutilisée, ni plus ni moins.



Renaud (le créateur de la plateforme)

 





Pas systématiquement; plusieurs de sites notamment militants comme je viens de le dire, proposent en accès libre des bases qui se sont faites poutrées (souvent facilement hélas).









spidy a écrit :



Le client (navigateur) envoie le mdp en clair (via HTTPS normalement) et c’est le serveur qui génère le hash et le compare à celui de la BDD.



si le client envoyait le hash directement, le fait de stocker le hash en BDD n’aurait aucun intérêt niveau sécurité.





Il faut aussi compter sur le fait que normalement et à minima, le mot de passe n’est pas “hashé” seul mais avec un sel, rendant la recherche du mot de passe nécessairement plus complexe.




  1. Il y a une mise en garde sur le site http://swarm-gateways.net/bzz:/passwords.eth)





    1. Pourquoi décentraliser ? : car pas d’entretien nécessaire (hébergement, mise à jour), et pas de censure/DDoS. Quant à la loi elle n’est pas la même partout, décentraliser ça évite la censure dans les pays où la parole n’est pas libre. Chacun doit se renseigner sur la loi de son pays, ce n’est pas au site de faire la morale.



    2. Des listes de hashs existent déjà sur le net, consulter ces hashs n’a rien d’illégal. Nous, chercheurs en sécurité, le faisons régulièrement !



       









nono2357 a écrit :





  1. Il y a une mise en garde sur le site http://swarm-gateways.net/bzz:/passwords.eth)





    1. Pourquoi décentraliser ? : car pas d’entretien nécessaire (hébergement, mise à jour), et pas de censure/DDoS. Quant à la loi elle n’est pas la même partout, décentraliser ça évite la censure dans les pays où la parole n’est pas libre. Chacun doit se renseigner sur la loi de son pays, ce n’est pas au site de faire la morale.



    2. Des listes de hashs existent déjà sur le net, consulter ces hashs n’a rien d’illégal. Nous, chercheurs en sécurité, le faisons régulièrement !



       





      Je n’ai jamais dit que votre service était illégal, mais que je n’adhérais pas une seconde au discours sur la légitimité du hack.



      Votre service traitera des hash sans distinction c’est tout, donc à des fins légitimes comme malveillantes.




Un article expliquant un peu plus en détail le principe de fonctionnement des FPGA serait intéressant, leur utilisation et leur programmation, quel type de tache on peu faire avec etc…

La blockchain c’est encore très mystérieux pour beaucoup de monde.

 








Patatt a écrit :



Un article expliquant un peu plus en détail le principe de fonctionnement des FPGA serait intéressant, leur utilisation et leur programmation, quel type de tache on peu faire avec etc…

La blockchain c’est encore très mystérieux pour beaucoup de monde.





+1… je pige absolument quedal au principe, déjà que je sais pas coder alors … <img data-src=" />

j’attends le bouquin “pour les nuls”



Une vidéo (en français) qui m’a permis d’y voir plus clair perso : http://www.youtube.com/watch?v=du34gPopY5Y








Flyman81 a écrit :



Une vidéo (en français) qui m’a permis d’y voir plus clair perso : http://www.youtube.com/watch?v=du34gPopY5Y





merci mon brave ! <img data-src=" /> <img data-src=" />



Je ne suis pas sur de comprendre le passage du FPGA aux serveurs dans l’ether



Les serveurs ne font que la vérification

Et il faut obligatoirement un FPGA programmé pour craquer les mots de passe pour y arriver.



C’est ça?

les FPGA doivent être programmé spécifiquement pour cette tache là?&nbsp;&nbsp;








Flyman81 a écrit :



Une vidéo (en français) qui m’a permis d’y voir plus clair perso : http://www.youtube.com/watch?v=du34gPopY5Y







partagée <img data-src=" />



Avec du temps tu pourrais craquer les mots de passe avec un processeur de PC classique, beaucoup de temps. Moins de temps avec des cartes graphiques parce que certaines instructions particulières y sont ‘câblées’.



Un FPGA cela ne se programme pas, cela se reconfigure : la première étape consiste à modifier les portes logiques et le circuit électrique, ensuite tu as à ta disposition comme un composant qui réalise en quelques tops d’horloge uniquement la fonction qui t’intéresse sans passer par une unité arithmétique et logique qui s’amuse à faire des calculs avec des registres, pile et compagnie.



Une sorte de cartouche de jeu vidéo que l’on peut recâbler.


Merci <img data-src=" />



Donc une personne qui a un FPGA pourrait se dire, “je vais me faire un peu d’argent en essayant de craquer un mot de passe”.&nbsp;

&nbsp;

Et la personne ayant demandé payera la personne avec le FPGA et l’ether pour les frais de vérification


Merci !!


De ce que j’ai compris il y a 3 étapes :




  • Alice dépose son défi (le hash à remonter, son mot de passe windows à retrouver ? <img data-src=" />) ainsi que la somme associée en Etherium. Les deux sont inscrits dans la blockchain de la plateforme.

  • Bob relève le défi et fait tourner les machines qu’il a à disposition chez lui pour essayer de trouver le message qui génère le hash lorsqu’on lui applique sha-256.

  • Lorsque Bob a trouvé, il paie un octroi (en Etherium aussi) pour soumettre sa solution sur la plateforme. Si la solution de Bob est correcte, la plateforme considère que le contrat est valide et déclenche automatiquement le crédit du compte Etherium de Bob avec le montant du défi.





    Après cela a du évoluer depuis la fin de mes études il y a 15 ans et qu’il y a surement des outils dédiés maintenant, mais j’en suis resté sur l’idée que configurer un FPGA prend quelques pages de mathématiques à écrire avant de passer à l’implémentation. Et c’était du coup assez difficile de débugger pour identifier l’origine des problèmes entre l’erreur de calcul et celle d’implémentation. :/




[…] Attention, il n’est pas question d’y envoyer des mots de passe de clients pendant un audit. Le risque est trop grand, notamment si le texte contient des éléments identifiant l’entreprise ou l’employé.



« La plateforme pourra plutôt être utilisée pour du craquage collaboratif sur un système ouvert sur Internet (caméra, routeur…). J’ai un appareil exposé, j’ai un mot de passe, je veux vérifier s’il est assez fort, je le soumets » estime le chercheur, qui dit avoir eu le déclic pour la Nuit du hack, où il présente régulièrement ses projets.



Quelque chose me gêne dans cette approche.



En somme, l’auteur du service explique que le but est de mettre à l’épreuve des mots de passes a priori impossibles à craquer (dans un délai ou coût raisonnables), plutôt qu’à mettre à l’épreuve des mots de passes utilisés par des vrais individus.



Cela signifie que l’on mettra à l’épreuve des mots de passes susceptibles de ne jamais être trouvés, donc de ne jamais être rémunérés, ou alors rémunérés trop tard, vu que l’intérêt évoqué semble être avant tout celui d’« une mission d’une ou deux semaines, [où l’]on n’a que quelques jours pour voir si l’un d’eux est solide ».



Bref, une (véritable) usine à « gas » ?


Si tu comprends l’anglais, cette vidéo sur la blockchain est assez claire ; celle-ci illustre le fonctionnement dans le blockchain dans le cadre du BitCoin, qui se résume finalement à un livre de comptes certifié par le processus de minage.



La certification de ce livre de comptes, ou le minage, donc, est faite par la communauté, sur la base de la preuve du travail, où le travail est long, sa vérification instantanée. Concrètement, pour fausser le livre de comptes, il faudrait que la majorité des mineurs falsifient les comptes, de la même manière, au même moment, ce qui est possible, mais improbable.



C’est du moins ce que j’ai retenu du principe.


merci bien <img data-src=" />


C’est exactement ça. <img data-src=" />




« Mais les outils de craquage de mot de passe sont déjà existants, en ligne », comme des forums, souligne-t-il. Même en étant relativement anonyme, la nouvelle plateforme ne devrait donc pas changer grand-chose, si elle venait à attirer un large public, selon son concepteur.





Ah bah si ca existe déjà, alors y a rien d’illégal/immoral à créer une plateforme payante…



<img data-src=" />


Hello



Je ne peux laisser passer cette erreur :)



Le client (navigateur web) envoie bien le mot de passe HASHE. Le password ne transite jamais en clair sur le réseau. L’idée est d’utiliser un hash plutôt grand (minima 256).

Et côté serveur ,on ne stocke pas directement le hash, on utilise un “salt”. Grossomodo, on rehash le hash avec une clé unique pour chaque client.

Et c’est ce résultat qu’on stocke en base.



Donc en base on a un hash de hash et une clé de salage. Quasi impossible de retrouver le password en clair en partant de là.


désolé d’insister mais le mdp est bien envoyé tel que tapé par l’utilisateur, la couche de sécurité se faisant par HTTPS.



Si tu ne me crois pas, teste par toi-même : utilise le débuggeur réseau de ton navigateur et essaie de te logguer sur un site quelconque, tu verras que tout est en clair (login et mdp)

&nbsp;

coté serveur, le stockage peut se faire de plusieurs manières :




  • en clair (si un site permet de renvoyer le mdp actuel (orange-jobs par exemple), c’est qu’il est forcément stocké en clair et ça c’est pas bien ^^)

  • hashé (md5/sha1/sha2…)

  • hashé + un salt commun à tout le monde (pas bien !)

  • hashé + un salt unique par mdp (bcrypt, scrypt…)


Il va nous falloir des sources sur ce coup là, car comme dit spidy, je pense que tu as tort.


C’est surtout que par défaut, ca n’a pas de sens!

Il faudrait que tous les navigateurs génèrent le même HASH pour un même mot de passe…

Et puis niveau protection ca n’apporte rien: que le mot de passe passe en clair ou en hash, si le pirate récupère l’un des deux, il peut alors se connecter à ta place sur le serveur: soit parce que c’est le mdp, soit parceque le hash est attendu par le serveur… donc c’est bon aussi <img data-src=" />



Evidemment avec une solution de hash coté client MAIS piloté par le serveur/application (donc on est pas dans un cadre ‘par défaut’), la donne change. Mais un champs “password” est transmis tel quel sinon.


Il y a en effet 2 situations :





  • soit sur une page web

  • soit au sein d’une application (on a alors un peu plus de contrôle)



    &nbsp;Mais je suis plutôt d’accord avec @Wizaord : tant que possible, on ne fait pas transiter le mot de passe sur le réseau, même en HTTPS qui, de toute façon, peut intercepté légalement par des proxys d’entreprises (https://stackoverflow.com/a/21716654/399439)



    De plus, tant que possible, on hashe aussi côté client avec des fonctions de hashage longue en durée (type 100000 cycles de hashage en PBKDF) pour que les attaques par force brutes soient plus lentes à mettre en oeuvre.


Je te conseille de lire “Bitcoin, la monnaie acéphale” de Favier et Takkal-Bataille qui est orienté enjeux politique et économique (avec un partie tech). Si tu préfères un bouquin orienté principalement technique (mais peu lisible), je te conseille “les blockchains, de la théorie à la pratique, de l’idée à l’implémentation” de Goujon, Leporcher et Chouli. A part ces deux là, je n’ai vu que des ouvrages sans intérêt sur la “révolution BC” ==&gt; bullshit.&nbsp;








nicobuq a écrit :



Il y a en effet 2 situations :



 soit sur une page websoit au sein d'une application (on a alors un peu plus de contrôle)&nbsp;Mais je suis plutôt d'accord avec @Wizaord : tant que possible, on ne fait pas transiter le mot de passe sur le réseau, même en HTTPS qui, de toute façon, peut intercepté légalement par des proxys d'entreprises (https://stackoverflow.com/a/21716654/399439)      






De plus, tant que possible, on hashe aussi côté client avec des fonctions de hashage longue en durée (type 100000 cycles de hashage en PBKDF) pour que les attaques par force brutes soient plus lentes à mettre en oeuvre.







Je suis perplexe sur l’intérêt du HASH coté client… Comme le relève fort justement CryoGen tout va passer en clair qu’il s’agisse du mot de passe ou de son hash. La protection viendra du chiffrage de la communication (HTTPS).



Par contre je ne comprends pas ton passage sur le hashage longue en durée coté client? En quoi est-il plus pertinent que ce même hashage coté serveur sachant que ton attaque par bruteforce tu vas devoir la faire sur un hash qu’il soit récupéré par écoute du client comme tu le suggères ou sur la bdd du serveur poutré ?









127.0.0.1 a écrit :



Ah bah si ca existe déjà, alors y a rien d’illégal/immoral à créer une plateforme payante…



<img data-src=" />






Non mais c'est légitime car on sauve la liberté d'expression dans certains pays et qui est en péril parce que tu peux pas librement poutrer contre rémunération des hashs qui sont pas nécessairement les tiens qu'on te dit ...


L’intérêt du hash côté client est de ne jamais faire transiter le mot de passe originel.

&nbsp;

Dans le cadre de vol de BDD ou de sniffing de paquets, un hash de mot de passe ne te donnant pas le mot de passe originel, tu ne peux pas utiliser ce hash sur d’autre webservices.



Concernant le hash ‘longue durée’, il est intéressant pour une attaque générée à partir de mots de passe ‘naturels’ (type ‘Ceci_est_mon_mot_de_passe_pour_2017’). Si la génération d’un hash prend 1 seconde (on cherche a être dans cet ordre là), générer tous les hashs d’une collection importante de mots de passe ‘naturels’ prendra déjà beaucoup de temps et de ressources.



Si l’on utilise directement des hashs, alors ce temps-là ne compte plus. Mais par contre, à moins de connaître le hash recherché, il y a beaucoup plus de possiblités (surtout si on génère un hash long). Il faut garder à l’esprit que tout cela ne cherche pas à prévenir toute attaque mais seulement à les ralentir pour avoir le temps de les détecter et de les contrer.



Après, s’il y a attaque de type MITM, alors il y a compromission des communications et pas de sécurité possible.








nicobuq a écrit :



L’intérêt du hash côté client est de ne jamais faire transiter le mot de passe originel.



&nbsp;      

Dans le cadre de vol de BDD ou de sniffing de paquets, un hash de mot de passe ne te donnant pas le mot de passe originel, tu ne peux pas utiliser ce hash sur d'autre webservices.






Concernant le hash 'longue durée', il est intéressant pour une attaque générée à partir de mots de passe 'naturels' (type 'Ceci\_est\_mon\_mot\_de\_passe\_pour\_2017'). Si la génération d'un hash prend 1 seconde (on cherche a être dans cet ordre là), générer tous les hashs d'une collection importante de mots de passe 'naturels' prendra déjà beaucoup de temps et de ressources.      






Si l'on utilise directement des hashs, alors ce temps-là ne compte plus. Mais par contre, à moins de connaître le hash recherché, il y a beaucoup plus de possiblités (surtout si on génère un hash long). Il faut garder à l'esprit que tout cela ne cherche pas à prévenir toute attaque mais seulement à les ralentir pour avoir le temps de les détecter et de les contrer.      






Après, s'il y a attaque de type MITM, alors il y a compromission des communications et pas de sécurité possible.







Mouai. Si j’admets que c’est peu être un ralentissement supplémentaire, il reste plus symbolique qu’efficace, étant relevé qu’il me semble délicat d’imposer une opération lourde et posant des difficultés éventuelles d’accessibilité/disponibilité de la fonction hash coté client.



C’est bien l’interception éventuelle en clair du mot de passe (ou de son hash coté client) qui est le



nœud du problème et que l'on ne peut véritablement résoudre qu'en  chiffrant les communications.     



&nbsp;

Par contre, il doit y avoir une maladresse dans ta formule “Dans le cadre de vol de BDD ou de…”, la bdd ne contient que des hashs jamais le mot de passe en clair à l’inverse d’un sniffing qui permet de voir passer en clair un mot de passe (sauf hashage coté client comme tu le proposes) à défaut de chiffrage des communications.



La BDD ne contient que des hashs si les précautions élémentaires ont été prises.

&nbsp;

Quand on voit l’actualité de ce domaine ces 3 dernières années, on se rend compte que même sur des gros sites, ces précautions n’ont pas toujours été mises en place, ce qui est effrayant !



Et le risque principal n’est pas de se logguer sur le site en question, mais d’essayer les couple identifiant/mot de passe sur tous les sites possibles (facebook, twitter, banques,…) pour voler d’autres données et faire de l’usurpation d’identité.