Je bosse sur un projet dans le cadre duquel j'ai besoin de construire une table de correspondance entre des mots de passe et leurs hash cryptographiques.
Seulement voilà, l'algorithme de calcul de ces hash (argon2id) est spécifiquement construit pour être long et coûteux a calculer. Or moi j'ai besoin d'un gros volume de données aléatoires (+2Gib), et memes avec toute ma puissance dont je dispose a la maison, ça me prendrait des mois.
J'ai donc mis au point hashcrush, un "brûleur de CPU", qui calcule ces précieux hash en utilisant toute la puissance disponible sur la machine qui l'exécute. Je l'ai testé sous Linux et OpenBSD.
Parce que je crois en l''esprit communautaire et l'entraide dans la vie de tous les jours, je préfères demander de l'aide au sein des communautés auxquelles j'appartiens plutôt que d'engraisser les fournisseur de service (qui me louerait du CPU à foison pour le même résultat avec grand plaisir).
Donc si vous voulez bien me filer un coup de main, clonez le dépôt et mangez du hash ! Toutes les infos sont sur la page du projet.
Si vous avez des questions, n'hésitez pas à les poser ici.
Merci les copains :)
Edit: pour ceux que ça intéresse, on a atteint l'objectif. Ça nous aura prit 3 jours, contre 8 mois si j'avais fais ça tout seul !
Effectivement ça peut y ressembler, et t'as raison d'être méfiant.
Mais si vraiment c'était du brute force et que c'était illégal, je ne publierais pas ça en mon nom, publiquement sur le web :)
Ensuite, concrètement tu peux voir que les hash générés utilisent un "sel" généré aléatoirement pour chaque mot de passe: hashgen.go#L97 et hashdump#L4. Si vraiment c'était un brute-force sur une base existance, alors je devrais utiliser un sel pré-existant récupéré dans cette DB. La technique est décrite dans l'article d'OWASP sur le stockage des mot de passe, qui mentionne justement Argon2ID. Spécifiquement cette phrase:
an attacker has to crack hashes one at a time using the respective salt rather than calculating a hash once and comparing it against every stored hash.
Comme je le disais dans mon cas, les "salt" de chaque hash sont générés aléatoirement à la volée, et donc ne peuvent pas correspondre dump de données (ou alors ce serait pas de bol, avec 1 chance sur 2^128).
Dans mon cas, je m'en fiche car le but est justement de générer une "fausse" base de données, mais avec des résultats cohérents.
Si tu as d'autres questions, ou si je dois éclaircir certains points, n'hésites pas !
J'imagine que c'est pour de l'entrainement en sécurité / hacking white-hat etc.
Dans une ancienne boite ils faisaient des concours comme ça régulièrement où le mec de la sécurité créaient des services avec des failles à attaquer etc., avec des prix à la clé pour qui y arrivait. Ça permet d'éduquer sur la sécurité et aussi de repérer les devs qui ont le talent pour, un mec de mon équipe a d'ailleurs été transféré dans le departement de sécurité IT suite à un de ces exercises.