Votre exemple de chaîne ( WeJcFMQ / 8 + 8QJ / w0hHh + 0g == ) est un encodage Base64 pour une séquence de 16 octets, qui ne ressemble pas à un ASCII ou UTF-8 significatif. Si c'est une valeur stockée pour la vérification du mot de passe (c'est-à-dire pas vraiment un mot de passe "chiffré", plutôt un mot de passe "haché") alors c'est probablement le résultat d'une fonction de hachage calculé sur le mot de passe; la seule fonction de hachage classique avec une sortie de 128 bits est MD5. Mais cela peut concerner n'importe quoi.

La manière "normale" de le savoir est de regarder le code de l'application. Le code de l'application est incarné de manière tangible et lourde (fichiers exécutables sur un serveur, code source quelque part ...) qui n'est pas, et ne peut pas être, autant protégée qu'une clé secrète. L'ingénierie inverse est donc la «voie à suivre».

À l'exception de l'ingénierie inverse, vous pouvez faire quelques expériences pour essayer de faire des suppositions éclairées:

• Si le même utilisateur " change "son mot de passe mais le réutilise, la valeur stockée change-t-elle? Si oui, alors une partie de la valeur est probablement un "salt" aléatoire ou IV (en supposant un cryptage symétrique).
• En supposant que la valeur est déterministe à partir du mot de passe d'un utilisateur donné, si deux utilisateurs choisissent le même mot de passe, aboutit-il à la même valeur stockée? Si non, le nom d'utilisateur fait probablement partie du calcul. Vous pouvez essayer de calculer MD5 ("nom d'utilisateur: mot de passe") ou d'autres variantes similaires, pour voir si vous obtenez une correspondance.
• La longueur du mot de passe est-elle limitée? À savoir, si vous définissez un mot de passe de 40 caractères et que vous ne parvenez pas à vous authentifier en tapant uniquement les 39 premiers caractères, cela signifie que tous les caractères sont importants, ce qui implique qu’il s’agit vraiment de hachage du mot de passe , pas encryption (la valeur stockée est utilisée pour vérifier un mot de passe, mais le mot de passe ne peut pas être récupéré à partir de la valeur stockée seule).

Edit: je viens de remarquer un script très cool nommé hashID. Le nom le décrit assez bien.

~~~

De manière générale, utiliser l'expérience pour faire des suppositions éclairées est la façon dont ces choses sont faites.

Voici un liste avec un très grand nombre de résultats de hachage afin que vous sachiez à quoi chacun ressemble et créez des signatures / motifs ou vérifiez simplement optiquement.

• Générateur de hachages de hachage en ligne
• InsidePro Software Forum> Types de hachage (via Archive.org)

Il y a deux principales choses que vous devez d'abord faites attention à:

• la longueur du hachage (chaque fonction de hachage a une longueur de sortie spécifique)
• l'alphabet utilisé (est-ce que toutes les lettres anglaises? les nombres 0-9 et AF donc hex? Quels caractères spéciaux y a-t-il s'il y en a?)

Plusieurs programmes de craquage de mots de passe (John the ripper par exemple) appliquent une correspondance de motif sur l'entrée pour deviner l'algorithme utilisé, mais cela ne fonctionne que sur les hachages génériques. Par exemple, si vous prenez une sortie de hachage et faites pivoter chaque lettre de 1, la plupart des schémas de correspondance de motifs échoueront.

Ce que vous avez publié est 16 octets (128 bits) de données codées en base 64. Le fait qu'il soit encodé en base 64 ne nous en dit pas beaucoup car la base 64 n'est pas un algorithme de chiffrement / hachage, c'est un moyen d'encoder des données binaires en texte. Cela signifie que ce bloc comprend une information utile, à savoir que la sortie a une longueur de 16 octets. Nous pouvons comparer cela à la taille de bloc des schémas couramment utilisés et comprendre ce que cela ne peut pas être. Les schémas de loin les plus courants sont:

• SHA-1 (160 bits)
• MD5 (128 bits )
• AES (128 bits)
• DES (64 bits)
• 3DES (64 bits)

La prochaine chose que nous devons faire est de regarder d'autres blocs de texte chiffré pour trouver la réponse à la question suivante:

• Tous les textes chiffrés ont-ils la même longueur, même pour des longueurs d'entrée différentes?

Si tous les blocs ne sont pas de la même longueur, vous ne regardez pas d'algorithme de hachage, mais un cryptage. Étant donné que la sortie sera toujours un multiple de la taille du bloc sous-jacent, la présence d'un bloc qui n'est pas également divisible par 16 octets signifierait qu'il ne peut pas être AES et doit donc être DES ou 3DES.

Si vous avoir la possibilité de mettre un mot de passe et d'observer la sortie, cela peut être déterminé très rapidement. Entrez simplement un mot de passe de 17 caractères et regardez la longueur. Si ses 16 octets vous avez MD5, 20 octets signifie SHA-1, 24 octets signifie DES ou 3DES, 32 octets signifie AES.

Cela dépend du format - certains protocoles de stockage de texte chiffré ont une partie en texte clair qui définit la manière dont il est chiffré. D'après votre exemple, je doute que la chaîne à laquelle vous faites référence est si courte qu'elle ressemble à du texte chiffré.

Je suggérerais quelques réflexions:

• Le "==" à la fin serait certainement un remplissage, donc ne l'incluez pas dans les tentatives de déchiffrement.

• Vous avez peut-être affaire à un hachage ou un hachage salé, plutôt qu'un cryptage. Dans ce cas, essayer de «déchiffrer» les données ne fonctionnera pas - vous devez faire correspondre les mots de passe en utilisant le même hachage et / ou la même valeur de sel que celui utilisé à l'origine. Il n'y a aucun moyen avec un mot de passe salé pour obtenir la valeur d'origine.

• Votre meilleur pari absolu est d'obtenir une copie du code qui est utilisé pour stocker les mots de passe. Quelque part là-dedans, les mots de passe subissent une opération cryptographique. Trouvez le code pour savoir ce qui se passe ici. 9 fois sur 10, ils utilisent une sorte d'API pour le hachage / salage / cryptage et vous pouvez l'imiter ou l'inverser en utilisant la même API.

Le codage peut généralement être deviné à. Par exemple, la chaîne que vous avez publiée dans votre question est encodée en Base64. Les signes égal sont remplis dans le schéma Base64. C'est quelque chose que je sais de vue par expérience.

Si vous m'avez donné une chaîne qui a été chiffrée, je pourrais peut-être vous dire l'encodage, mais je ne peux pas vous dire l'algorithme utilisé pour le chiffrer à moins une sorte de métadonnées est disponible. La raison est la suivante: les algorithmes de chiffrement fonctionnent en produisant ce qui semble être des données aléatoires. Si je chiffrais deux phrases chacune avec deux chiffrements (quatre sorties), vous seriez incapable de me dire avec certitude quel texte chiffré appartenait à quel chiffrement, sauf si vous l'avez déchiffré ou cassé le chiffrement.

En ce qui concerne votre instance spécifique, les mots de passe sont généralement hachés. Cela signifie que vous ne pouvez pas récupérer le mot de passe à partir du hachage, mais vous pouvez tester pour voir si le hachage correspond au mot de passe. À cet égard, la réponse de @ john est en or. Si vous pouvez saisir un mot de passe que vous connaissez et ensuite essayer des schémas courants contre lui, vous pouvez découvrir quel est le hachage utilisé.

S'il s'agit effectivement d'un simple hachage de mot de passe, nous pourrions peut-être utiliser Google pour le déchiffrer. Cependant, Base64 est difficile à rechercher, avec toutes ces barres obliques et signes plus, alors convertissons d'abord ce hachage en hexadécimal:

  $ perl -MMIME :: Base64 -le 'print unpack "H * ", decode_base64" WeJcFMQ / 8 + 8QJ / w0hHh + 0g == "'59e25c14c43ff3ef1027fc3484787ed2  

OK, maintenant nous pouvons Google pour cela. Pour le moment, je reçois un seul appel, de md5this.com - bien qu'il y en ait évidemment assez bientôt, y compris ce message.

Malheureusement (ou peut-être heureusement, selon votre point de vue), nous n'avons pas la chance de trouver une pré-image (le site répertorie actuellement ce hachage comme "cracking ..."), mais le fait qu'il soit sur cette liste du tout suggère fortement qu'il s'agit bien d'un hachage MD5 non salé d'un vrai mot de passe.

Le seul moyen est de deviner. Avec l'expérience, les travaux de supposition seront plus corrects.

Par exemple: Basé sur la longueur de la sortie: la sortie MD5 est de 128 bits, ou 16 octets, la sortie SHA1 est de 160 bits, ou 20 octets. Basé sur le jeu de caractères de la sortie: BASE64 produit une sortie avec des caractères imprimables.

À la fin de la journée, c'est l'approche try-and-error qui vous apprend comment.

Le seul moyen est lorsqu'il y a des métadonnées qui vous le disent. Par exemple, j'ai travaillé avec des PDF récemment, et le format comprend un dictionnaire contenant le filtre, l'algorithme, la taille de la clé, etc. Mais si tout ce que vous avez est le texte chiffré, alors tout ce que vous avez est une goutte opaque de données.

C'est une sécurité très faible sur tous les fronts! Le texte en clair est P4 $$ w0rdP4 $$ w0rd et il est chiffré à l'aide du chiffrement XOR, avec la clé CdZ4MLMPgYtAE9gQ80gMtg == . Cela produit le texte chiffré posté par l'OP ci-dessus, WeJcFMQ/8+8QJ/w0hHh+0g==

Pour vérifier:

  echo -n 'P4 $$ w0rdP4 $$ w0rd' | xxd -b -c16  

  01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100  

  echo -n 'CdZ4MLMPgYtAE9gQ80gMtg ==' | base64 -d | xxd -b -c16  

  00001001 11010110 01111000 00110000 10110011 00001111 10000001 10001011 01000000 00010011 11011000 00010000 11110011 01001000 00001100 10110110  

  01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 (texte en clair) [XOR] 01110010 01100100 (texte en clair) [XOR] 01100001010101 10110011 00001111 10000001 10001011 01000000 00010011 11011000 00010000 11110011 01001000 00001100 10110110 (clé) ----------------------------------- -------------------------------------------------- -------------------------------------------------- -------- 01011001 11100010 01011100 00010100 11000100 00111111 11110011 11101111 00010000 00100111 11111100 00110100 10000100 01111000 01111110 11010010 (texte chiffré)  

  echo "obase = 16; ibas e = 2; 01011001111000100101110000010100110001000011111111110011111011110001000000100111111111000011010010000100011110000111111011010010 "| bc | xxd -p -r | base64