S'agit-il d'une méthode de hachage / masquage automatique? Pouvez-vous reconnaître le motif?
Un système que nous introduisons dans l'organisation n'utilise aucune fonction de hachage traditionnelle que je puisse trouver. J'ai été chargé de "l'approuver" par des tests en boîte noire.
Je soupçonne que les mots de passe sont simplement obscurcis ou chiffrés (non hachés) car la longueur du résultat change avec la longueur du mot de passe (bien qu'il y ait un minimum, semble-t-il - peut-être un remplissage?).
Voici quelques données:
mot de passe: résultat 1: TG3432WB7VU = 11: r8ahLkJGWbY = 111: E7fXdNqEWAA = 11111111: FIcx3a00R4eGhFyHjD56qw == 1111111111: FIcx3a00R4evxqEuQkZZtg == 2111111111: GPwnH80qEACvxqEuQkZZtg ==
Le résultat est évidemment base64, mais ne décode en rien de lisible. Avant de savoir que la longueur du résultat avait changé, j'ai essayé de prendre les octets décodés et de les traiter comme MD5 et d'autres fonctions de hachage, mais cela n'a évidemment pas fonctionné. Maintenant que je sais que le résultat change de longueur, j'envisage d'autres alternatives, pires. Il convient de noter les deux parties en gras ci-dessus: elles sont identiques dans deux mots de passe différents. Donc, soit chaque 8 octets sont traités indépendamment (pourquoi?) Ou il y a une substitution polyalphabétique en cours (?).
Mise à jour:
Tout caractère, y compris les caractères Unicode, est accepté par le système pour les mots de passe. La répétition d'un caractère de 3 octets 8 fois entraîne un "hachage" long de 24 octets.
Je soupçonne fortement qu'il s'agit d'une méthode auto-enroulée, ou du moins très obsolète. Il est très faible selon les normes modernes et ne doit pas être utilisé pour protéger quoi que ce soit d'important.
Les mots de passe courts pourraient être piratés avec pas plus de 2 ^ 64 tentatives de force brute, ce qui est tout à fait possible même avec un ordinateur normal. Si les deux moitiés du résultat sont indépendantes, même avec des mots de passe assez longs, 2 * 2 ^ 64 tentatives de force brute pourraient le casser (donc 2 ^ 65 tentatives). Il y a probablement d'autres faiblesses dans l'algorithme qui le rendent plus faible que décrit ici.
Un autre point intéressant à tester serait 2111111111 et voir si la deuxième partie du résultat reste la même. Si la deuxième partie ne change pas, c'est définitivement un algorithme faible.
Modifier:
Étant donné que les résultats du test 2111111111 sont les mêmes pour la seconde moitié, il s'agit certainement d'un algorithme faible et ne doit pas être utilisé pour protéger quoi que ce soit de sensible! J'ai inclus la comparaison pertinente ci-dessous:
1111111111 : FIcx3a00R4evxqEuQkZZtg==2111111111 : GPwnH80qEACvxqEuQkZZtg==
Modifier:
Un autre test intéressant serait ce que Ricky Demer suggère ci-dessous:
La prochaine chose à vérifier est qu'il gère les blocs de 8 octets de manière identique. Quels sont les "hachages" de aaaaaaaabbbbbbbbc et bbbbbbbbaaaaaaaac? - Ricky Demer 25 février à 6:44
S'il traite les blocs de 8 octets de manière identique, c'est encore pire pour les mots de passe même longs, quelle que soit la longueur. Cela ne nécessiterait que 2 ^ 64 tentatives de force brute, comme l'a souligné Neil dans les commentaires. Une fois que quelqu'un a fait un tableau de ce que chaque possibilité calcule, cet algorithme serait pratiquement inutile. Il y a probablement encore plus de faiblesses à découvrir dans cet algorithme.
Conclusion:
Je ne recommande pas d'utiliser cet algorithme quels que soient les résultats du dernier test. Nous en avons déjà vu assez pour savoir qu'il est faible. Quelque chose avec un schéma de cryptage/hachage de bits plus élevé, du sel, un temps de calcul long, etc. serait beaucoup mieux, et je recommanderais d'utiliser l'une des méthodes existantes soigneusement testées. Le chiffrement/hachage auto-roulé n'a pas bénéficié des tests approfondis de la plupart des principales méthodes de flux.
Le fait que la longueur des chaînes codées dépend de la longueur des mots de passe respectifs suggère une faiblesse bien pire: les mots de passe semblent être obscurcis plutôt que hachés.
Cela signifie que quiconque connaît les éléments internes du système peut décrypter instantanément n'importe quel mot de passe! Les implications sont nombreuses: vous devez faire confiance aux développeurs qui ont déjà travaillé sur le système, le code source doit être gardé secret pour toujours (c'est pourquoi vous passez en revue une boîte noire), etc.
Peu importe la qualité de l'algorithme d'obscurcissement (et 264 n'est pas exactement stellaire). C'est cassé par conception.
Kerckhoffs's_principle s'applique évidemment: Un cryptosystème doit être sécurisé même si tout ce qui concerne le système, à l'exception de la clé, est de notoriété publique.
Cela en soi devrait vous suffire pour dire "Je ne peux pas approuver ce système sans plus d'informations".
D'après vos exemples, il semble que l'entrée soit divisée en blocs de 8 caractères/octets, chaque bloc est haché individuellement et les sorties assemblées, puis le résultat entier est codé en base64.
Ce n'est pas bien. La plupart des mots de passe de plus de 8 caractères ne font que quelques caractères de plus. Cela signifie qu'un attaquant peut casser très facilement le deuxième bloc. Et lorsque vous connaissez le deuxième bloc, vous avez une forte indication de ce que le premier bloc peut contenir.
La communauté cryptographique a découvert cela il y a des décennies et ne hachera plus les blocs de manière indépendante. Cela signifie que ces programmeurs ne sont [~ # ~] pas [~ # ~] à jour sur la crypto.
La seule bonne nouvelle est qu'un changement d'un seul caractère dans le mot de passe change tout son bloc de sortie. Cela signifie probablement qu'ils hachent en fait les mots de passe et pas seulement les obscurcissent. Pourtant, avec les faiblesses ci-dessus, la meilleure fonction de hachage du monde ne peut pas enregistrer l'algorithme.
Cela ressemble à un simple chiffrement de bloc et n'est certainement pas quelque chose que vous voudriez utiliser. Comparez-le à, au lieu de hacher les mots de passe, simplement les encoder/les brouiller avec, par exemple, base64. Ce n'est pas quelque chose que vous voudriez faire. Si quelqu'un applique même une simple cryptanalyse, il pourrait facilement découvrir que ce ne sont que suffisamment de caractères utilisés pour être en base64.