Y a-t-il un avantage à diviser un mot de passe?
J'ai lu sur le hachage LANMAN (LM) et je suis curieux de savoir une partie particulière de l'algorithme.
Le hachage LM est calculé comme suit:
- Le mot de passe de l’utilisateur ASCII est converti en majuscules.
- Ce mot de passe est complété à 14 octets.
- Le mot de passe de 14 octets est divisé en deux moitiés de 7 octets.
- Ces valeurs sont utilisées pour créer deux clés DES, une pour chaque moitié de 7 octets.
- Chacune des deux clés est utilisée pour crypter la constante ASCII chaîne "KGS! @ # $%" , résultant en deux valeurs de texte chiffré de 8 octets.
- Ces deux valeurs de texte chiffré sont concaténées pour former une valeur de 16 octets, qui est le hachage LM.
Il y a beaucoup de failles de sécurité décrites dans l'article Wikipédia lié et évoquées ailleurs, mais je suis particulièrement intéressé par les étapes 3 à 6. Je suis curieux de savoir ce qui a conduit à cette conception. Y a-t-il un réel avantage en termes de sécurité à diviser un mot de passe, à chiffrer les deux moitiés séparément, puis à combiner les deux moitiés pour former à nouveau un hachage? Ou est-ce juste un exemple de "sécurité par l'obscurité" ?
La division du mot de passe en hachages n'est pas un avantage. Cela a été fait pour des raisons obscures qui ne sont plus d'actualité aujourd'hui.
La raison pour laquelle le hachage LanMan fonctionne de cette façon est que le hachage LanMan est construit sur DES. DES accepte une clé de 56 bits. Par conséquent, il est naturel de traiter un bloc de 7 octets comme formant une clé DES. Il n'y a pas de bon moyen d'utiliser DES pour hacher plus de 7 octets à la fois, et nous avons besoin d'un moyen de construire un hachage pour des mots de passe plus longs à partir de DES, donc les concepteurs du hachage LanMan ont décidé de diviser le mot de passe en deux moitiés.
Aujourd'hui, nous ne créerions jamais un hachage de mot de passe de cette façon. Nous utiliserions simplement Bcrypt, Scrypt, PBKDF2 ou un équivalent - ou nous construirions quelque chose de similaire basé sur des primitives existantes, comme SHA256. Mais à l'époque, Bcrypt, Scrypt, SHA256, etc. n'existaient pas, ouvrant la possibilité aux concepteurs LanMan de faire ce genre d'erreur dévastatrice.
Selon les normes modernes, le hachage LanMan est un design minable. Il y a beaucoupbeaucoupattaques dessus. C'est très faible. Personne ne devrait utiliser le hachage LanMan aujourd'hui s'il peut éventuellement l'éviter. (Comme d'autres l'ont souligné, sa sécurité est minable même selon les normes de l'époque. Un point juste.)
Le fractionnement du mot de passe est un faiblesse, pas un avantage. Il permet de casser chaque mot de passe de manière indépendante. En commençant par ASCII caractères (codes de 32 à 126, inclus), puis en supprimant les lettres minuscules, vous vous retrouvez avec 127-32-26 = 69 caractères possibles dans l'alphabet de mot de passe. Cela conduit à 697 moitiés possibles, ce qui est légèrement inférieur à 243. En d'autres termes, cela est très maniable grâce à la force brute. Vous n'avez même pas besoin d'un dictionnaire.
Ce n'est pas la sécurité par l'obscurité. C'est l'insécurité par l'incompétence.
Edit: "hautement maniable avec force brute" ouvre également la voie à diverses optimisations. Notez que LanMan n'est pas salé, donc les tables précalculées peuvent être efficaces (vous payez le coût de la construction de la table une fois, puis vous attaquez plusieurs demi-mots de passe - cela vaut même la peine pour un seul mot de passe, car un le mot de passe est deux demi-mots de passe). En 2003, Philippe Oechslin a publié un compromis temps-mémoire amélioré (c'est l'article dans lequel il a inventé le terme "Rainbow table") et des tableaux calculés pour le cracking des mots de passe LanMan. Il s'est limité aux mots de passe alphanumériques (lettres et chiffres, mais pas de signes spéciaux), donc un espace de 237. La taille cumulée des tables serait alors de 1,4 Go, avec une efficacité de craquage de 99,9% et un temps d'attaque inférieur à une minute.
Avec un 243 espace, c'est-à-dire 64 fois plus grand, la taille de la table et le temps d'attaque augmentent tous les deux d'un facteur 16 (c'est 642/3), nous parlons donc d'environ 23 Go (ce qui n'est pas beaucoup pour les disques d'aujourd'hui) et d'une attaque de 15 minutes. En fait, l'attaque serait plus rapide que cela, car le goulot d'étranglement est la recherche sur le disque dur, et l'attaquant intelligent utilisera un SSD qui peut effectuer des recherches 50 fois plus rapidement qu'un disque dur mécanique (un SSD de 32 Go coûte moins cher que 70 $ ...). L'effort de création de table (une dépense unique) pourrait prendre quelques semaines sur un seul PC, ou quelques jours sur n'importe quel cloud décent, donc c'est plutôt bon marché.
Apparemment , de telles tables existent déjà ...
Le simple fait que quelque chose soit plus complexe ne le rend pas nécessairement plus sûr. J'ai exécuté un pirate de mot de passe sur ma boîte Windows et il a semblé décomposer les mots de passe en 8 chaînes de caractères, et il a cassé chaque chaîne indépendamment de l'autre chaîne, ce qui a rendu le processus extrêmement rapide.
Donc, d'un point de vue pratique, la division d'un mot de passe n'est pas bénéfique, et @Thomas a déjà expliqué pourquoi il n'est pas bénéfique mathématiquement.