Comment déterminer quel type d'encodage / cryptage a été utilisé?
Existe-t-il un moyen de savoir quel type de cryptage/codage est utilisé? Par exemple, je teste une application Web qui stocke le mot de passe dans la base de données dans un format crypté (WeJcFMQ/8+8QJ/w0hHh+0g==). Comment déterminer le hachage ou le chiffrement utilisé?
Votre exemple de chaîne (WeJcFMQ/8+8QJ/w0hHh+0g==) est le codage Base64 pour une séquence de 16 octets, qui ne ressemble pas à un sens ASCII ou UTF-8. If c'est une valeur stockée pour le mot de passe - vérification (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ée sur le mot de passe; la seule fonction de hachage classique avec une sortie 128 bits est MD5. Mais il pourrait s'agir de n'importe quoi.
La façon "normale" de le savoir est de regarder le code de l'application. Le code d'application est incarné de manière tangible et épaisse (fichiers exécutables sur un serveur, code source quelque part ...) qui n'est pas, et ne peut pas être, autant protégé qu'une clé secrète. La rétro-ingénierie est donc la "voie à suivre".
Sauf 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 "sel" aléatoire ou IV (en supposant un cryptage symétrique).
- En supposant que la valeur est déterministe à partir du mot de passe pour un utilisateur donné, si deux utilisateurs choisissent le même mot de passe, cela aboutit-il à la même valeur stockée? Si non, le nom d'utilisateur fait probablement partie du calcul. Vous voudrez peut-être 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 pouvez pas vous authentifier avec succès 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 d'un mot de passe hachage, pas - cryptage (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é uniquement à partir de la valeur stockée).
Edit: je viens de remarquer un script très cool nommé hashID . Le nom le décrit à peu près.
~~~
D'une manière générale, l'utilisation de l'expérience pour faire des suppositions éclairées est de savoir comment ces choses sont faites.
Voici une liste avec un très grand nombre de sorties de hachage afin que vous sachiez à quoi ressemble chacune et créez des signatures/patters ou tout simplement vérifier optiquement.
- Générateur de hachage de hachage en ligne
- Forum du logiciel InsidePro> Types de hachage (via Archive.org)
Il y a deux principales choses auxquelles vous faites d'abord attention:
- la longueur du hachage (chaque fonction de hachage a une longueur de sortie spécifique)
- l'alphabet utilisé (toutes les lettres anglaises sont-elles des nombres 0-9 et A-F si hexadécimal? quels caractères spéciaux y a-t-il s'il y en a?)
Plusieurs programmes de craquage de mot de passe (Jean l'éventreur par exemple) appliquent une correspondance de modèle 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 modèles échoueront.
Ce que vous avez publié est 16 octets (128 bits) de données codées en base 64. Le fait qu'il soit codé en base 64 ne nous dit pas grand-chose car la base 64 n'est pas un algorithme de chiffrement/hachage, c'est un moyen de coder des données binaires en texte. Cela signifie que ce bloc comprend une information utile, à savoir que la sortie fait 16 octets de long. Nous pouvons comparer cela à la taille de bloc des schémas couramment utilisés et comprendre ce que cela ne peut pas être. Les régimes de loin les plus courants sont:
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 n'ont pas la même longueur, vous ne regardez pas un algorithme de hachage, mais un algorithme de chiffrement. Étant donné que la sortie sera toujours un multiple de la taille de bloc sous-jacente, la présence d'un bloc qui n'est pas divisible également par 16 octets signifierait qu'il ne peut pas être AES et doit donc être DES ou 3DES.
Si vous avez la possibilité de saisir 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.
S'il s'agit bien d'un simple hachage de mot de passe, nous pourrions peut-être tiliser Google pour le casser . Base64 est difficile à rechercher, cependant, 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 n seul coup , de md5this.com - bien qu'il y en ait évidemment très bientôt, y compris ce post.
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 suggèrent fortement qu'il s'agit bien d'un hachage MD5 non salé d'un vrai mot de passe.
Cela dépend du format - certains protocoles de stockage de texte crypté ont une partie en texte clair qui définit comment il est crypté. D'après votre exemple, je doute que la chaîne à laquelle vous faites référence soit si courte qu'il semble que ce soit juste le texte chiffré.
Je suggère quelques réflexions:
Le "==" à la fin serait certainement un remplissage, donc ne l'incluez pas dans les tentatives de décryptage.
Vous avez peut-être affaire à un hachage ou à un hachage salé, plutôt qu'à un chiffrement. Dans ce cas, essayer de "décrypter" les données ne fonctionnera pas - vous devez faire correspondre les mots de passe en utilisant la même valeur de hachage et/ou de sel que celle utilisée à 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 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.
L'encodage peut généralement être deviné. Par exemple, la chaîne que vous avez publiée dans votre question est codée en Base64. Les signes égaux remplissent le schéma Base64. C'est quelque chose que je sais à vue d'expérience.
Si vous m'avez donné une chaîne qui a été cryptée, je peux peut-être vous dire l'encodage mais je ne peux pas vous dire l'algorithme utilisé pour la crypter à moins qu'une sorte de métadonnées ne soit disponible. La raison en 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 chiffres (quatre sorties), vous ne seriez pas en mesure de me dire avec certitude quel texte chiffré appartenait à quel chiffrement à moins que vous ne le déchiffriez ou ne le cassiez.
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, @ réponse de John est doré. Si vous pouvez entrer un mot de passe que vous connaissez, puis essayer des schémas courants contre celui-ci, vous pouvez apprendre quel est le hachage utilisé.
La seule façon est de deviner. Avec l'expérience, les devinettes seront plus correctes.
Par exemple: Basé sur la longueur de 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 sortie: BASE64 produit une sortie avec des caractères imprimables.
À la fin de la journée, c'est l'approche par essai et erreur qui vous apprend comment.
C'est une sécurité très faible sur tous les fronts! Le texte en clair est P4 $$ w0rdP4 $$ w0rd et il est chiffré en utilisant XOR, avec la clé CdZ4MLMPgYtAE9gQ80gMtg ==. Cela produit le texte chiffré publié par l'OP ci-dessus, WeJcFMQ/8 + 8QJ/w0hHh + 0g ==.
Vérifier:
Tout d'abord, utilisez xxd pour obtenir le binaire sous-jacent du texte en clair:
echo -n 'P4$$w0rdP4$$w0rd' | xxd -b -c16
Cela produit:
01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100
Ensuite, décodez en base64 la clé et utilisez xxd pour obtenir le binaire sous-jacent de la clé:
echo -n 'CdZ4MLMPgYtAE9gQ80gMtg==' | base64 -d | xxd -b -c16
Cela produit:
00001001 11010110 01111000 00110000 10110011 00001111 10000001 10001011 01000000 00010011 11011000 00010000 11110011 01001000 00001100 10110110
Maintenant, XOR les deux chaînes binaires:
01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 01010000 00110100 00100100 00100100 01110111 00110000 01110010 01100100 (plaintext)
[XOR]
00001001 11010110 01111000 00110000 10110011 00001111 10000001 10001011 01000000 00010011 11011000 00010000 11110011 01001000 00001100 10110110 (key)
-----------------------------------------------------------------------------------------------------------------------------------------------
01011001 11100010 01011100 00010100 11000100 00111111 11110011 11101111 00010000 00100111 11111100 00110100 10000100 01111000 01111110 11010010 (ciphertext)
Enfin, utilisez bc, xxd et base64 pour convertir le texte chiffré binaire en base64:
echo "obase=16; ibase=2; 01011001111000100101110000010100110001000011111111110011111011110001000000100111111111000011010010000100011110000111111011010010" | bc | xxd -p -r | base64
Cela produit WeJcFMQ/8 + 8QJ/w0hHh + 0g ==, qui est le texte chiffré publié par l'OP dans la question ci-dessus.
Je m'excuse si cette réponse semble artificielle. Certes, ça l'est. Des questions similaires à celle-ci, où l'affiche ne fournit que du texte chiffré et demande un aperçu de la façon dont ce texte chiffré aurait pu être produit, semblent se poser assez fréquemment sur security.stackexchange.com; et cette question est souvent référencée comme un doublon à ceux-ci. Le but de cette réponse est d'illustrer que des questions de cette nature sont sans réponse, car il existe des solutions infinies à ces types de questions.
La seule façon est quand il y a des métadonnées qui vous le disent. Par exemple, j'ai récemment travaillé avec des fichiers PDF, et le format comprend un dictionnaire contenant le filtre, l'algorithme, la taille de la clé, etc. Les données.