Cracker les mots de passe hachés en utilisant un mot de passe connu

Ghedipunk

2019-11-12 05:42:54 UTC

view on stackexchange narkive permalink

Réponse courte:

Vous ne pouvez pas déchiffrer 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 chiffrée du mot de passe. Il ne peut pas être décrypté, pas plus que vous ne pouvez prendre de hashbrown 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 quelles ont été les données perdues, mais vous vous tromperez probablement, et avec les fonctions de hachage cryptographique, être un peu erroné à 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 ayez 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 d'origine 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'utilisateur; 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 ressources humaines 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 à 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 cette opportunité pour changer le mot de passe de chacun en un algorithme d'étirement de clé tel que PBKDF2, bcrypt, scrypt ou Argon2id.

Et, si tout cela échoue, demandez à l'utilisateur de téléphoner, expliquez la situation et planifiez une heure à laquelle il pourra vous regarder travailler et réinitialiser son mot de passe immédiatement après. (Je ne mets cela que 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 vient 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, donc c'est probablement un point discutable.

Et pendant que vous travaillez sur des systèmes d'authentification, allez consultez les Directives d'identité numérique du NIST, parcourez le tout et portez une attention particulière au SP 800-63B.

oups, j'ai supprimé les bits de cryptage de la question

OP connaît déjà le mot de passe par défaut ("J'ai la chaîne hachée stockée du mot de passe par défaut, quel mot de passe il se traduit").L'objectif semble être de récupérer les mots de passe des autres utilisateurs (ou les données qu'ils protègent), pour les personnes qui les ont modifiés.

+1 pour l'analogie du "hash" brown -> pomme de terre.:-)

@CBHacking S'ils ont le hachage de mot de passe par défaut, ils peuvent simplement changer le hachage dans la base de données et réinitialiser efficacement le mot de passe de cet utilisateur par défaut.

La troisième option n'est pas louche, c'est une technique de migration standard.De nombreux frameworks (par exemple, le framework d'identité de Microsoft) ont même une prise en charge explicite pour la reformulation de ces mots de passe.Des points bonus si vous forcez finalement une réinitialisation de mot de passe sur des utilisateurs persistants et non migrés.

Merci pour cela - je pense que c'est une bonne réponse pour quelqu'un, mais je cherche spécifiquement à déhacher une chaîne hachée bcrypt.Je comprends que cela ne peut généralement pas être fait, j'ai juste pensé avec tellement d'informations sur le processus (je connais l'IV utilisée par exemple - un avantage rare je pense) que je pourrais le faire dans mon cas, et je voulais savoir, sinon, pourquoi pas.Merci quand même

@Brian, la partie douteuse, dans ce cas, est que pour que vous puissiez _apprendre_ le mot de passe, vous devrez l'enregistrer en texte brut quelque part.

@Ghedipunk: Si le système a les mots de passe en texte brut, vous pouvez les rechiffrer (c'est-à-dire que # 3 est complètement faux).S'il les a hachés, vous copiez les hachages, pas les mots de passe.

@Brian, "_quand 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é."- C'est là que vous effectuerez la partie louche de la journalisation du mot de passe en texte brut.(Et comme le mot de passe vient d'être compromis (bien que par vous), j'ai ajouté une section indiquant que les mots de passe devraient être expirés.)

@Ghedipunk: Si tous les comptes ont le même mot de passe (par défaut), le rechiffrement de ce mot de passe ne fournit pas une protection adéquate même si vous ne savez pas quel est ce mot de passe, car les utilisateurs se connaissent les mots de passe.Si tous les comptes ont des mots de passe différents, vous n'avez pas besoin de consigner le texte en clair (bien qu'il soit brièvement dans la RAM, comme ce sera probablement le cas sur votre nouveau système): l'étape de re-hachage du mot de passe devrait se produire immédiatement.

Cependant, @Brian, OP essaie d'obtenir les mots de passe de leurs utilisateurs afin qu'ils puissent les utiliser eux-mêmes.Cela implique des affaires très louches.- Je conviens que le simple changement de l'algorithme d'étirement des clés n'implique pas la journalisation du mot de passe, mais ce n'est pas ce qui est demandé ou répondu.

J'aime vraiment cette métaphore des pommes de terre et des pommes de terre, et je vais probablement la voler.

@DewiMorgan: Peut-être apocryphe (je n'ai pas de copie de The Art of Computer Programming, Volume 3 de Knuth, qui semble avoir les meilleures sources sur l'origine du terme), mais on m'a dit qu'en tant que jargon, le hachage dérive directementde hacher et de mélanger le hachis de corned-beef.J'utilise des hashbrowns parce que plus de gens autour de moi le connaissent.

Conor Mancone

2019-11-12 07:18:57 UTC

view on stackexchange narkive permalink

Je vais ajouter à la pléthore de réponses ici avec 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 alimentez l'intégralité de Wikipédia. 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 les majuscules. S'il trouve des majuscules, il renvoie True . Sinon, il renvoie False . Voici quelques exemples des entrées et sorties:

  123456 -> Falseasdfer -> Falserfjeif -> False27 _ + $ (-> FalseweAdfy -> TrueErYHV1 -> True12345W -> TrueWERERE -> true

J'ai maintenant le hash d'un utilisateur et il est: True . Quel était le mot de passe?

Une fonction de hachage est donc un destructeur d'informations déterministe.

@ig-dev ouais, à peu près

Ceci n'est probablement pas pertinent.Tout mot de passe qui produit le même hachage fonctionnera comme un mot de passe.Vous ne vous souciez généralement pas de savoir si le mot de passe est "Swordfish" ou "sdfj340q9t" #% ¤Afaweit34iQWE # ¤t ", vous vous souciez de savoir si le système vous authentifiera lorsque vous entrez le mot de passe du candidat. De même, si le hachage est de 32 octets, et l'un des candidats qui produit le hachage est "Swordfish", vous pouvez être assez sûr que "Swordfish" est la séquence de caractères que l'utilisateur d'origine a entré.

Juste pour être complet, la plupart des hachages de mots de passe modernes sont plus longs que les mots de passe typiques et produisent avec une très grande chance un hachage unique et ne jettent rien.(Certains plus anciens accepteraient plusieurs mots de passe avec le même hachage, surtout si vous forcez brutalement avec des modèles complexes et longs).

@Taemyr Vrai normalement mais pas pour l'OP qui veut clairement trouver le mot de passe * réel * de l'utilisateur et pas seulement une collision.

(1) "J'essaye d'obtenir les notes d'utilisateur des comptes où un utilisateur a (rarement) changé son mot de passe par défaut."- Donc, OP n'est pas vraiment intéressé par le mot de passe réel. Et (2) En supposant un algorithme de hachage cryptographiquement sécurisé, le seul choix est de forcer le mot de passe, si cela réussit, il est extrêmement probable que le mot de passe trouvé soit le mot de passe réel.

Même si le hachage est plus long que le mot de passe, vous pouvez toujours (théoriquement) trouver une collision.La puissance de calcul réelle requise dépend de la force du hachage et n'est certainement pas triviale s'il s'agit de quelque chose de sécurisé à distance.

@Taemyr Mon objectif était de fournir un exemple clair et concis qui montre pourquoi il peut être impossible de récupérer le mot de passe d'origine.Je pense que cela est utile pour le PO, et bien qu'il y ait manifestement de nombreuses mises en garde, les autres réponses ici sont plus détaillées.En conséquence, c'est intentionnellement minimaliste.Si vous n'êtes pas d'accord avec ma réponse, vous êtes invités à voter contre.

@ConorMancone Ce serait abuser des votes négatifs.Comme l'info-bulle de vote défavorable dit "Cette réponse n'est pas utile" - si taemyr pense que _que_, alors ils devraient voter contre (même si ce ne serait pas le seul utilisateur à abuser des votes négatifs de cette façon).

@Taemyr: comment est-ce hors de propos?L'exemple de hachage transforme toute entrée en un hachage de 1 bit.C'est pour montrer que le fait d'avoir les hachages n'aide pas à récupérer le mot de passe.Maintenant, l'algo de hachage est médiocre en ce qui concerne les mots de passe car beaucoup, comme vous l'avez mentionné, correspondent au hachage (= collisions).Mais l'intention n'était pas de fournir un bon hachage pour les mots de passe.

@Taemyr un mot de passe qui hache avec le même hachage fonctionnerait très bien pour s'authentifier par rapport au système existant, mais cela ne fonctionnerait pas pour créer un nouveau hachage (algorithme différent) dans un nouveau système pour l'ancien mot de passe.

Pas ce que je recherche, mais un regard intéressant sur la situation.Je ne vois pas en quoi cela clarifie ce que je demande spécifiquement ...

@Mancone Nous savons ce qu'OP a demandé, mais nous ne pouvons pas savoir ce qu'il _ veut_.

@gnasher729, OP veut éviter d'appeler 58 utilisateurs.Cette partie a été [déplacée vers le chat]) https://security.stackexchange.com/questions/221047/crack-hashed-passwords-using-a-known-password/221050#221050).Que ce soit un bon objectif ou non est mieux adapté pour [lieu de travail.se];la nôtre est la suivante: étant donné que les utilisateurs contourneront la sécurité si cela ne leur convient pas (et que OP _peut_ avoir une meilleure compréhension de leurs utilisateurs que nous le faisons), comment pouvons-nous les garder en sécurité?(C'est pourquoi j'ai opté pour d'autres moyens d'obtenir leurs mots de passe, mais j'ai ajouté la partie d'expiration des mots de passe dans une modification.)

CBHacking

2019-11-12 05:57:06 UTC

view on stackexchange narkive permalink

Votre question est un peu déroutante, donc si ce qui suit ne correspond pas entièrement à 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 ou 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 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 le savez soit , ou peut accéder, à l'algorithme utilisé pour la dérivation de clé à partir des mots de passe.
Vous souhaitez déchiffrer 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é utilisés, etc.), je ne peux pas forcément trouver les points les plus faibles du système à attaquer. Cependant, comme décrit, il semble que le lien faible soit le hachage de 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 MD5 à un tour). Pour un hachage non salé, vous pouvez probablement utiliser une table arc-en-ciel (une table de recherche mappant les résumé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 tables que vous pouvez trouver), forcer brutalement de tels hachages est généralement assez facile; Les GPU grand public modernes peuvent effectuer littéralement des milliards de ces 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 peut-être littéralement le forçage brutal de chaque caractère possible jusqu'à une longueur donnée), des logiciels tels que "hashcat" ou "john the ripper", et quelque temps.

Pour répondre plus directement à la question: toutes les normes modernes de chiffrement et de hachage fonctionnent sur le hypothèse qu'il doit être sécurisé 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 (d'entrée, de résumé) pour un algorithme de hachage, car vous pouvez calculer cette digestion vous-même étant donné que vous avez l'entrée et l'algorithme - est l'hypothèse de base que toute crypto moderne doit être en sécurité contre. La crypto ne vaudrait pas grand-chose si quelques millions (soyons généreux) de paires d'entrée / sortie suffisaient pour casser l'algorithme de chiffrement ou de hachage.

Merci pour cela, à part des conseils sur la façon de faire fonctionner un système, ce qui, espérons-le, sera utile aux autres, vous êtes la seule personne à avoir compris et paramétré avec précision votre réponse - merci et désolé d'avoir été bref avant :)

Si vous pensez que les gens ne vous ont pas compris, il serait utile de répondre à leurs questions en clarifiant votre question.Plusieurs personnes vous demandent plus de détails.@MJHd

Un sel rendrait-il les choses plus difficiles dans ce cas?On dirait que ce développeur a accès à la base de données, ce qui voudrait dire qu'il aurait probablement le sel ainsi que le hachage.Et comme ils essaient seulement de déchiffrer un seul mot de passe, ne pourraient-ils pas simplement ajouter le sel à chaque mot de passe candidat avant le hachage?

@MartianInvader oui un sel rendrait les choses plus difficiles.L'intérêt d'un salt est de forcer l'attaquant à attaquer chaque hash individuellement, c'est-à-dire d'empêcher l'utilisation de tables arc-en-ciel.Il est généralement toujours disponible pour quiconque possède le hachage du mot de passe et n'est pas considéré comme particulièrement secret.

Façons dont un sel rend les choses plus difficiles: ne peut pas utiliser une table arc-en-ciel (ou simplement google le résumé, qui fonctionne de manière alarmante pour MD5), ne peut pas dire quand plusieurs utilisateurs ont le même mot de passe, ne peuvent pas déchiffrer plusieurs mots de passe dansparallèle (et l'OP essaie de déchiffrer plusieurs mots de passe différents, @MartianInvader)

@Jack Mais cette réponse ne suggère pas d'utiliser une table arc-en-ciel - elle recommande de forcer brutalement les hachages à partir d'un ensemble de mots de passe candidats.On dirait que l'affiche essaie également de déchiffrer un petit ensemble de mots de passe - bien que je suppose que s'il y avait, disons, 10 mots de passe qui avaient des sels séparés, alors les forcer brutalement prendrait 10 fois plus de temps, mais serait toujours faisable.Je suppose que l'implication la plus importante du manque de sel est simplement qu'elle "implique un système de hachage de mot de passe très faible".

@MartianInvader Bon point, j'ai ajouté une suggestion d'utiliser des tables arc-en-ciel.Avec le matériel moderne, le forçage brutal peut être plus rapide que le téléchargement d'une table arc-en-ciel, mais si vous en avez une à portée de main (et / ou que vous ne voulez pas dépenser de l'argent sur un GPU rapide), c'est toujours le moyen le plus simple de craquer les plus non salés.mots de passe.

ig-dev

2019-11-12 06:36:47 UTC

view on stackexchange narkive permalink

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 en ce que le chiffrement peut être inversé, contrairement au hachage. Le hachage détruit les informations et il n'existe aucun moyen de reconstruire le mot de passe d'origine à partir d'un hachage sécurisé. S'il y a un léger changement dans le 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écurisés. Il existe également des bases de données constituées de combinaisons connues de mot de passe-hachage. Celles-ci n'aident pas à déchiffrer les mots de passe inconnus de la base de données.

Vous êtes laissé aux méthodes conventionnelles de piratage des mots de passe, qui consiste généralement à 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.

Cela aidera en fait, si vous connaissez la méthode de construction des hachages, il est plus facile de les forcer brutalement (mais cela peut toujours être impossible)

C'est vrai.En même temps, tout ce qui est vraisemblablement nécessaire pour déterminer la fonction de hachage est la connaissance d'une seule combinaison utilisateur / mot de passe.

schroeder

2019-11-12 05:42:35 UTC

view on stackexchange narkive permalink

La réponse courte est que toutes les informations dont vous disposez vous aident , mais si vous ne voulez pas prendre le temps de passer 58 appels téléphoniques, vous n'aimerez pas les semaines / mois / années que cela pourrait 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 pouvez essayer d'exécuter des dictionnaires de mots de passe sur vos hachages pour voir si les utilisateurs ont utilisé des mots de passe devinables. Mais ce ne sera toujours pas à 100%.

Nathan Goings

2019-11-13 00:42:12 UTC

view on stackexchange narkive permalink

Ghedipunk mentionne cette solution, mais je voulais la développer.

Si vous parvenez à dupliquer le mécanisme de hachage avec succès, vous pouvez mettre à jour les mots de passe de vos utilisateurs juste à temps.

Autrement dit, 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 à niveau le compte 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, ce qui les oblige à changer leur mot de passe.

Le but du stockage cryptographique des mots de passe sous forme de hachage est que personne, y compris les administrateurs, ne puisse découvrir le mot de passe en texte brut.

Enfin, pour vous et pour d'autres, si l'ancienne méthode d'authentification s'avère sécurisée et suit les meilleures pratiques, alors 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.

Merci d'avoir développé ce point.J'ai manqué les besoins spécifiques pour OP;J'ai mal lu la question ... mais c'est une bonne explication sur la façon de migrer les anciens hachages de mots de passe (tels que ceux effectués par un seul tour de SHA2) vers un algorithme d'étirement de clé plus sécurisé.J'aime aussi le fait d'expirer les mots de passe des systèmes non sécurisés.

André LFS Bacci

2019-11-12 21:34:59 UTC

view on stackexchange narkive permalink

Vous vous êtes trompé

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é d'un ancien employé. Et puis, de n'importe quel employé. Et puis, de n'importe quelle personne, vraiment.

Les mots de passe sont stockés avec un hachage cryptographique pour empêcher que personne de voir les données d'origine. Cela inclut vous.

Vous n'avez pas besoin de déchiffrer 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. nouveau système.

Vous devez également créer un nouvel identifiant de connexion et supprimer l'ancienne entrée de base de données en cas de succès, afin que tout utilisateur migre sans problème.

Glen Davies

2019-11-12 18:48:07 UTC

view on stackexchange narkive permalink

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 voulez sont les notes de l'utilisateur, il existe d'autres options:

Utilisateur administrateur de la base de données

En supposant que vous ayez 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. C'est effectivement un MITM. (voir les commentaires de Conor Mancone et eckes)

Hashcat

En cas d'échec 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 passer.

Conclusion

Malheureusement, à part la première option, il est probablement moins nécessaire de faire les appels .

mckenzm

2019-11-13 05:58:49 UTC

view on stackexchange narkive permalink

Définissez simple.

Étant donné que vous connaissez et avez l'algorithme, et que vous pouvez le vérifier pour un exemple, il est trivial de "forcer" les autres mots de passe.

Étant donné suffisamment de ressources et de temps. Si vous divisez l'espace en blocs (unités de travail) et testez en parallèle, les choses seront plus faciles. Sauf en cas de sécheresse des ressources provoquée par la frénésie des clics, vous pourriez avoir cent mille threads pendant moins d'un jour à 15 caractères, par exemple, même sans instances GPU et CUDA. Ceci est fait 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 des 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 simplement mettre à jour (surcharger) leur mot de passe à une valeur connue, et les forcer à le réinitialiser. Il est courant dans le développement de simplement mettre à jour le hachage avec le hachage d'un mot de passe arbitraire.

À la racine du problème, c'est que 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 ont changé rarement?

Avez-vous essayé un "grouper par" et un "ordre par ordre décroissant"? S'ils ont tous le même mot de passe par défaut, ils flotteront jusqu'en haut.

Je soutiens l'idée d'une éventuelle migration, avec un ancien magasin et un magasin "modernisé".

Lightness Races in Orbit

2019-11-14 21:00:04 UTC

view on stackexchange narkive permalink

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 personnes 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 communiquées.

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 à sens unique, mais il me semble que vous avez encore des lectures à faire!