Crackez les mots de passe hachés en utilisant un mot de passe connu
Je suis un développeur essayant de déployer un nouveau tableau de bord que j'ai écrit au travail, l'ancien est un gâchis de bibliothèques piratées et seulement environ la moitié de la base de code est encore en cours d'utilisation (du code mort partout qui n'a jamais été supprimé, mais ne fait rien) ...
Je ne suis pas prêt à me suicider pour cette absurdité une seconde de plus, j'essaie d'obtenir les notes des utilisateurs à partir des comptes où un utilisateur a (rarement) changé son mot de passe par défaut. J'ai la chaîne de hachage stockée du mot de passe par défaut, le mot de passe qu'il traduit, le mécanisme de hachage utilisé, la méthode de cryptage utilisée et les chaînes de hachage des autres mots de passe.
Il a juste un moyen simple d'utiliser ces informations pour décrypter les autres mots de passe correctement ??
Si ce n'est pas possible, quelqu'un peut-il m'expliquer pourquoi? J'ai la nature à sens unique du hachage, mais étant donné la quantité d'informations dont je dispose sur le processus de bout en bout, je connais essentiellement l'ensemble du processus, donc je ne suis pas sûr que ce soit important dans ce cas ...
Pour résumer:
Puis-je utiliser la connaissance des mécanismes de hachage et de chiffrement, ainsi qu'un exemple de chaîne de hachage et sa valeur en texte brut, pour casser d'autres mots de passe produits par le même code?
PS: Si cela aide, chaque hachage par défaut est identique quel que soit le moment où il a été créé ...
Votre question est un peu déroutante, donc si les éléments suivants ne correspondent pas pleinement à votre situation, veuillez corriger les hypothèses suivantes:
- Votre système stocke des données chiffrées pour plusieurs utilisateurs.
- Les données de chaque utilisateur sont chiffrées à l'aide d'une clé unique par utilisateur ou à l'aide d'une clé principale chiffrée (encapsulée) avec une clé par utilisateur.
- La clé de chaque utilisateur est soit chiffrée (encapsulée) avec une clé dérivée du, soit directement dérivée du mot de passe de l'utilisateur.
- Vous connaissez les mots de passe de certains utilisateurs mais pas d'autres.
- Vous connaissez l'algorithme de hachage de mot de passe utilisé pour l'authentification.
- Vous avez accès aux hachages d'authentification.
- Les hachages d'authentification ne sont pas salés ("chaque hachage par défaut est identique").
- Vous connaissez ou pouvez accéder à l'algorithme utilisé pour la dérivation des clés à partir des mots de passe.
- Vous souhaitez décrypter les données des utilisateurs dont vous ne connaissez pas les mots de passe.
Sans en savoir plus sur le système (comme les chiffrements utilisés, les algorithmes de hachage/dérivation de clés utilisés, etc.), je ne trouve pas nécessairement les points les plus faibles du système à attaquer. Cependant, comme décrit, il semble que le maillon faible soit le hachage du mot de passe. S'ils sont en fait les mêmes pour un mot de passe donné, cela indique qu'ils ne sont pas salés, ce qui implique un schéma de hachage de mot de passe très faible (peut-être quelque chose d'aussi mauvais que le MD5 à un tour). Pour un hachage non salé, vous pouvez probablement utiliser une table Rainbow (une table de recherche mappant les condensés de hachage précalculés à leurs valeurs d'entrée). Cependant, même si vous ne pouvez pas (par exemple, les mots de passe que vous voulez ne sont pas présents dans les tableaux que vous pouvez trouver), le forçage brutal de tels hachages est généralement assez facile; Les GPU grand public modernes peuvent effectuer littéralement des milliards de tels hachages par seconde, donc tout ce dont vous avez besoin est un matériel approprié (localement ou dans le cloud), un ensemble de mots de passe candidats (et des processus pour en générer plus, y compris éventuellement littéralement juste en forçant brutalement tous les caractères possibles jusqu'à une longueur donnée), des logiciels tels que "hashcat" ou "john the ripper", et un certain temps.
Pour répondre plus directement à la question: toutes les normes de chiffrement et de hachage modernes fonctionnent en supposant qu'elles doivent être sécurisées même si l'attaquant sait exactement quelles sont les étapes de l'algorithme. Connaître l'algorithme - qui domine strictement la valeur de la connaissance d'une paire (entrée, résumé) pour un algorithme de hachage, car vous pouvez calculer ce résumé vous-même étant donné que vous avez l'entrée et l'algorithme - est l'hypothèse de base que tout crypto moderne doit être sûr contre. La crypto ne vaudrait pas grand-chose si quelques millions (soyons généreux) de millions d'entrées/sorties suffisaient pour casser l'algorithme de chiffrement ou de hachage.
Réponse courte:
Vous ne pouvez pas décrypter le hachage. Vous devrez utiliser d'autres moyens pour le récupérer.
Explication:
Le résultat d'un hachage n'est pas une version cryptée du mot de passe. Il ne peut pas être décrypté, pas plus que vous ne pouvez prendre des hashbrowns et reconstruire une pomme de terre complète. Le résultat d'un hachage cryptographique est une version brouillée des données, avec une grande partie des données d'origine perdues. Vous pouvez deviner ce qu'auraient pu être les données perdues, mais vous aurez probablement tort, et avec les fonctions de hachage cryptographique, le fait d'avoir un peu tort à un moment donné rendra les données calculées très différentes des données d'origine.
Cependant, vous pouvez récupérer ce mot de passe par défaut en utilisant différents moyens, en supposant que vous avez accès au code source de l'ancien système. Voici trois possibilités:
Comme il s'agit d'un mot de passe par défaut et que ce mot de passe est identique pour tout le monde, les développeurs originaux n'ont pas beaucoup réfléchi à la sécurité des mots de passe. Vérifiez le code source autour de la création d'utilisateurs; le mot de passe peut être stocké en texte clair.
Le mot de passe par défaut doit être communiqué au nouvel utilisateur d'une manière ou d'une autre. Créez un nouveau compte, demandez à votre administrateur informatique ou demandez au représentant des RH qui donne le mot de passe aux nouveaux employés.
(Un peu louche) Vous pouvez également simplement copier les mots de passe en gros de l'ancien système vers votre nouveau système et, lorsqu'un utilisateur se connecte en utilisant le mot de passe par défaut, vous l'aurez en texte clair pendant un bref instant pendant que le système d'authentification vérifie que le mot de passe correspond au hachage stocké. Utilisez-le comme une opportunité pour changer le mot de passe de tout le monde en un algorithme d'étirement des clés tel que PBKDF2, bcrypt, scrypt ou Argon2id.
Et, si tout cela échoue, appelez l'utilisateur au téléphone, expliquez la situation et fixez un moment où il pourra vous regarder travailler et réinitialiser son mot de passe immédiatement après. (Je ne fais que cela comme dernière option, car il a été mentionné dans les commentaires que c'est la situation que vous souhaitez éviter.)
Dans tous les cas, vous devez expirer le mot de passe immédiatement (car vous venez de le compromettre). Cependant, l'utilisation d'un mot de passe par défaut indique que l'application n'a probablement pas de fonction d'expiration de mot de passe, c'est donc probablement un point discutable.
Et pendant que vous travaillez sur des systèmes d'authentification, rendez-vous sur les NIST Digital Identity Guidelines , parcourez le tout et portez une attention particulière à SP 800-63B).
J'ajouterai à la pléthore de réponses ici un exemple simple, car je trouve que réduire les choses à l'essentiel peut souvent être très instructif. La clé est que les algorithmes de hachage détruisent les données. Un hachage Argon2 toujours a 32 octets même si vous le nourrissez entièrement de Wikipedia. La seule façon d'y arriver est de jeter beaucoup de données et une fois jetées, elles disparaissent.
Pour démontrer que j'ai un algorithme de hachage simple (et terrible). Il vérifie son entrée pour toutes les lettres majuscules. S'il trouve des majuscules, il génère True. Sinon, il génère False. Voici quelques exemples d'entrées et de sorties:
123456 -> False
asdfer -> False
rfjeif -> False
27_+$( -> False
weAdfy -> True
ErYHV1 -> True
12345W -> True
WERERE -> True
Maintenant, j'ai le hachage d'un utilisateur et c'est: True. Quel était le mot de passe?
Non, les informations sur les mots de passe connus ne seront d'aucune utilité pour déchiffrer les mots de passe inconnus.
Les hachages sont le résultat de fonctions de trappe à sens unique. Le hachage diffère du chiffrement dans la mesure où le chiffrement peut être inversé, contrairement au hachage. Le hachage détruit les informations et il n'y a aucun moyen de reconstruire le mot de passe d'origine à partir d'un hachage sécurisé. En cas de légère modification du mot de passe d'origine, le hachage résultant sera entièrement différent. Par conséquent, vous ne pouvez même pas comparer deux hachages pour voir si les mots de passe d'origine sont similaires.
De nombreux projets open-source révèlent comment les mots de passe de leur application sont hachés. Cela ne rend pas les hachages moins sûrs. Il existe également des bases de données composées de combinaisons connues de hachage de mot de passe. Ceux-ci n'aident pas à casser les mots de passe inconnus de la base de données.
Vous êtes laissé aux méthodes conventionnelles de craquage des mots de passe, ce qui implique généralement d'essayer les mots de passe possibles de manière automatisée pour voir s'ils correspondent au hachage. Ce n'est en aucun cas plus facile ou plus rapide que 58 appels téléphoniques.
La réponse courte est que toutes les informations dont vous disposez aident mais si vous ne souhaitez pas prendre le temps de faire 58 appels téléphoniques, alors vous n'aimerez pas le semaines/mois/années, cela peut prendre, même avec toutes vos informations privilégiées.
Considérez ceci: chaque système de mot de passe partout est le même que le vôtre: ils connaissent le hachage, le système et ils peuvent créer autant de leurs propres mots de passe à tester. Et le hachage est toujours considéré comme sécurisé, même dans ces conditions.
Vous pourriez essayer d'exécuter des dictionnaires de mots de passe contre vos hachages pour voir si les utilisateurs ont utilisé des mots de passe devinables. Mais ce ne sera toujours pas à 100%.
Ghedipunk mentionne cette solution mais je voulais la développer.
Si vous êtes en mesure de dupliquer le mécanisme de hachage avec succès, vous pouvez mettre à jour les mots de passe de vos utilisateurs juste à temps.
En d'autres termes, lorsqu'un utilisateur se connecte, vérifiez si les informations d'identification de son compte sont stockées à l'aide de l'ancienne méthode. Si tel est le cas, validez les informations d'identification par rapport à l'ancienne méthode, puis mettez immédiatement le compte à niveau vers une nouvelle information d'identification (sécurisée).
Dans le nouveau système, je recommanderais également expiration tous les comptes d'utilisateurs utilisant l'ancienne méthode afin de les forcer à changer leur mot de passe.
Le point de stockage cryptographique des mots de passe sous forme de hachages est que personne, y compris les administrateurs, ne puisse découvrir le mot de passe en texte brut.
Enfin, pour vous et les autres, si l'ancienne méthode d'authentification s'avère sécurisée et respecte les meilleures pratiques, il n'est pas nécessaire d'utiliser une nouvelle méthode. Déplacez simplement l'ancienne méthode d'authentification dans votre nouveau système.
Vous avez tort
Il n'y a pas de "doit être". Pour voir cela, il suffit de considérer ceci: s'il existe un moyen, aucun mot de passe ne peut être protégé contre un employé précédent. Et puis, de tout employé. Et puis, de toute personne, vraiment.
Les mots de passe sont stockés avec un hachage cryptographique pour éviter que n'importe qui pour voir les données d'origine. Cela comprend vous.
Vous n'avez pas besoin de décrypter les mots de passe
Vous serez en charge du nouveau système et du nouveau processus de connexion complet. Vous connaissez tout l'ancien processus. Ainsi, dans le nouveau système, vous n'avez besoin que de l'ancienne base de données de mots de passe et d'une copie de l'ancien processus.
Si une connexion sur un nouveau système échoue, vous exécutez le processus précédent sur l'ancienne base de données de mots de passe pour autoriser les anciennes connexions sur le nouveau système.
Vous devez également créer une nouvelle identification de connexion et supprimer l'ancienne entrée de base de données en cas de succès, afin que tout utilisateur migre sans aucune difficulté.
Comme l'indiquent les autres réponses, la récupération des mots de passe directement ne sera pas possible.
Cependant, étant donné que les données que vous souhaitez sont les notes de l'utilisateur, il existe d'autres options:
Utilisateur Admin DB
En supposant que vous avez un accès légitime au back-end, vous pouvez extraire les données en tant qu'utilisateur administrateur de la base de données. (voir le commentaire de Trotski94)
MITM
Vous pouvez déployer le nouveau tableau de bord et importer les nouvelles données uniquement lorsque l'utilisateur vous donne son mot de passe. Il s'agit en fait d'un MITM. (voir les commentaires de Conor Mancone et eckes)
Hashcat
À défaut de ces options, exécutez les hachages contre hashcat (l'outil de récupération de mot de passe). À tout le moins, cela pourrait réduire le nombre d'appels téléphoniques que vous devez faire.
Conclusion
Malheureusement, à part la première option, son effort est probablement moindre pour passer les appels.
Non.
L'intérêt d'un cryptage unidirectionnel décent est que le simple fait de savoir comment fonctionne le cryptage est insuffisant pour l'inverser.
Si ce n'était pas le cas, des gens comme vous seraient en mesure de décrypter les données d'autres personnes avec seulement la petite quantité d'informations que vous nous avez fournies.
Il va de soi que ce n'est pas de la sécurité.
Ces algorithmes sont littéralement conçus pour contrecarrer exactement ce que vous essayez de faire.
De plus, le chiffrement dans ce cas étant un hachage , il n'y a pas de mappage un-à-un des données vers le hachage. Vous prétendez comprendre la notion de hachage unidirectionnel, mais il me semble que vous avez encore de la lecture à faire!
Définissez simple.
Étant donné que vous connaissez et possédez l'algorithme et que vous pouvez le vérifier pour un exemple, il est trivial de "forcer brutalement" les autres mots de passe.
Compte tenu des ressources suffisantes et du temps. Si vous divisez l'espace en blocs (unités de travail) et testez en parallèle, les choses seront plus faciles. À moins d'une sécheresse des ressources provoquée par la frénésie des clics, vous pourriez avoir cent mille threads en moins d'une journée à 15 caractères, même sans instances GPU et CUDA. Cela se fait régulièrement pour la blockchain, le pliage à la maison, SETI à la maison, etc.
Hashcat est un bon point de départ, mais si les hachages sont tronqués ou les sous-chaînes, vous devrez toujours modifier le code pour le comparer avec un masque. Vous ne pourrez probablement pas personnaliser un "Antminer" pour cela.
Il est bien sûr beaucoup plus facile de mettre à jour (sur-frappe) leur mot de passe à une valeur connue et de les forcer à le réinitialiser. Il est courant en développement de simplement mettre à jour le hachage en hachage de mot de passe arbitraire.
À l'origine du problème, vous (ou votre ancien système) ne suivez pas l'âge ou les modifications du mot de passe. Vous souhaitez extraire des données uniquement pour ceux qui n'ont pas changé leur mot de passe ou pris leur temps, ou changé rarement?
Avez-vous essayé un "groupé par" et un "ordre en descendant"? S'ils ont tous le même mot de passe par défaut, ils flotteront en haut de celui-ci.
Je soutiens l'idée d'une migration éventuelle, avec un magasin hérité et un magasin "modernisé".