Sécurité du hachage de mot de passe Windows 7
Je suis récemment tombé sur un nombresursources qui suggère qu'il est facile de déchiffrer les mots de passe des comptes d'utilisateurs Windows en examinant leurs hachages de mots de passe.
Je comprends que ces hachages sont stockés dans le fichier SAM dans deux formats: LM et NTLM . LM n'est pas sécurisé (et depuis Vista, un fichier significatif n'est pas stocké, non?). Cependant, NTLM est également cryptographiquement faible et peut également être brisé de manière perturbante rapidement.
Dans tous les cas, même avec ce que je considérerais comme des mots de passe "forts", je les ai vu craquer en quelques minutes - simplement en redémarrant l'ordinateur sous Linux à partir d'un lecteur flash, puis en exécutant un programme qui extrait les mots de passe de les hachages. Cela me semble être une énorme vulnérabilité.
La seule chose que j'ai pu trouver en ligne pour empêcher cela était d'utiliser un mot de passe plus long, afin de garantir que le hachage LM le plus faible n'a pas de sens - mais NTLM est toujours faible.
Quelqu'un sait comment se protéger contre ce genre d'attaques?
Il y a quelques éléments à considérer ici. Microsoft a utilisé deux algorithmes pour la base de données des comptes sur les systèmes Windows:
LM (LAN Manager)
NTLM (NT LAN Manager)
Un attaquant disposant d'un accès physique à votre système peut facilement vider le contenu de la base de données SAM (Security Accounts Manager) pour tous les comptes locaux, puis utiliser quelque chose comme Ophcrack ( http://ophcrack.sourceforge.net ) pour exécuter des attaques de table Rainbow contre les valeurs hachées.
Cependant, vous devez déterminer quel est le risque réel: l'attaquant est capable de déchiffrer le mot de passe et/ou l'attaquant est en mesure d'accéder au système. Ceci est important car il n'est pas nécessaire de déchiffrer le mot de passe (devinez sa valeur) afin de compromettre le système. De nombreux autres outils remplacent simplement le hachage dans la base de données SAM par quelque chose choisi par l'attaquant. Cela compromet le système, mais pas nécessairement le mot de passe lui-même. Le chiffrement intégral du disque résout les deux problèmes en tant que première ligne de défense: votre attaquant n'est pas en mesure de monter le volume dans l'outil qu'il utilise pour contourner la base de données SAM. Si vous suivez cette voie, de nombreux fournisseurs commerciaux proposent des solutions. Truecrypt ( http://www.truecrypt.org/ ) propose un superbe programme gratuit. Bitlocker ou toute solution de chiffrement intégrée au système d'exploitation est pratiquement sans valeur car ils sont facilement sensibles aux attaques de démarrage à froid.
L'une des solutions les plus récentes sont les lecteurs à chiffrement automatique qui nécessitent un démarrage dans leur propre micrologiciel pour y accéder.
Dans toute cette réponse, je considère le problème de la récupération du mot de passe (ou un mot de passe équivalent) à partir d'un hachage dérobé, tel qu'il est stocké sur un serveur sur lequel l'attaquant pourrait obtenir un accès en lecture.
Le hachage NTLM est faible, mais pas aussi faible que l'ancien hachage LM.
Le hachage LM plus ancien comporte plusieurs faiblesses majeures:
- Pas sensible à la casse.
- Limité à 14 caractères.
- Divise le mot de passe en deux moitiés de 7 caractères hachés séparément.
Cette dernière faiblesse permet un cracking très efficace (quel que soit le soin apporté au choix du mot de passe); voir cette réponse pour quelques détails.
Le NTLM moins ancien est juste MD4 calculé sur le mot de passe. Cette fois, le mot de passe est sensible à la casse et peut être assez long. Il y a un différend quant à la longueur maximale réelle du mot de passe qui pourrait apparemment contenir jusqu'à 127 caractères environ. Étant donné que MD4 est calculé sur le codage UTF-16 du mot de passe, toute la gamme de nicode pourrait théoriquement être utilisée, mais puisque l'utilisateur doit taper le mot de passe régulièrement (et sans retour visuel), en utilisant des caractères au-delà l'ensemble imprimable ASCII recherche des problèmes.
Ce qui est faible dans le hachage NTLM, c'est qu'il n'est pas salé, et que MD4 est rapide (MD4 est également cryptographiquement cassé de plusieurs manières, mais pas pour la résistance de préimage brute comme cela est utilisé pour le hachage de mot de passe; pour que, MD4 est aussi robuste que jamais). MD4 est en fait plus rapide que MD5. Un GPU récent calculera plusieurs milliards d'instances MD4 par seconde. Cela permet à l'attaquant d'explorer facilement de vastes ensembles de mots de passe potentiels (ce qui est connu sous le nom de attaque par dictionnaire ). La seule défense consiste à choisir vos mots de passe dans un ensemble plus vaste.
Jetons un peu de maths à cela: puisque NTLM n'est pas salé, un groupe d'attaquants dédié pourrait trouver utile de construire un gros Table arc-en-ciel . Il existe différentes optimisations possibles, mais, en règle générale, les choses se passeraient comme suit:
- Il existe un paramètre de sécurité, appelé t; c'est la longueur moyenne d'une chaîne dans la table Rainbow.
- Si l'ensemble des mots de passe couverts par le tableau a la taille [~ # ~] n [~ # ~], alors les exigences de stockage sont environ 10 * N/t octets (10 octets par extrémité de chaîne triée est une estimation raisonnable).
- La construction de la table implique un coût d'environ 1.7 * N invocations de fonctions de hachage.
- Attaquer un mot de passe avec la table implique de calculer environ t2 fois la fonction de hachage, et en faisant t des recherches dans le tableau.
Si la table est répartie sur une centaine de disques durs mécaniques, environ 10000 recherches peuvent être effectuées par seconde. Si l'attaquant est vraiment motivé, il pourrait souhaiter passer environ une heure par mot de passe, ce qui signifie un maximum t de 3600000 pour les recherches (disons 222); le coût du processeur correspondant est tombé à environ 232 hachages par seconde, ce qui est possible avec quelques GPU récents. Les cent disques permettent 300 TB stockage (je parle de 3 TB disque, qui sont disponibles aujourd'hui), ce qui apporte le possible = [~ # ~] n [~ # ~] à environ 267. C'est assez énorme, mais technologiquement faisable. Notre groupe d'attaquants pourrait acheter une centaine de GPU (et une unité de climatisation gros) et en finir avec le calcul de cette table en quelques mois.
Ainsi, afin de vaincre nos adversaires motivés, nous devons choisir des mots de passe au hasard dans un ensemble plus grand que leur [~ # ~] n [~ # ~]. Si notre ensemble de mots de passe possibles a une taille supérieure à 277 et nos mots de passe sont choisis de manière aléatoire et uniforme dans cet ensemble (c'est-à-dire que l'entropie du mot de passe est de 77 bits ou plus), l'attaquant n'a que 1/1000 de chance de casser un mot de passe donné avec sa table. Cela devrait suffire à le dissuader.
Comment obtient-on 77 bits d'entropie? Si nous nous limitons aux lettres (majuscules et minuscules) et aux chiffres, afin que le mot de passe puisse être tapé sur des claviers arbitraires, alors nous pouvons avoir un peu moins de 6 bits d'entropie par caractère. Par conséquent, 13 caractères suffisent . N'est-ce pas gonflé? Seulement 13! Pas besoin de passer à d'énormes mots de passe. Mais attention au petit type: c'est 13 lettres ou chiffres totalement aléatoires. Pas question de laisser un humain - choisir ces personnages, ou même de générer une douzaine de mots de passe de 13 caractères et de lui laisser choisir celui qu'il préfère. Vous prenez le générateur, vous produisez un mot de passe, et vous l'apprenez. L'effort mental est le prix d'utilisation d'un mécanisme de hachage de mot de passe rapide non salé comme NTLM.
(Bien sûr, le groupe d'attaquants décrit ci-dessus est réaliste. Vous voudrez peut-être augmenter un peu la complexité, afin que vos mots de passe soient également forts vis-à-vis des attaquants de demain; alors faites en 14 ou 15 caractères pour être plus sûr.)
En général, sur la plupart des systèmes, un mot de passe plus long est toujours meilleur.
Il existe bien sûr des tables Rainbow pour NTLM (par exemple, http://www.freerainbowtables.com/en/tables2/ )
Du point de vue du forçage brutal cependant, vous devriez limiter le nombre de tentatives de connexion infructueuses avant d'être verrouillé. Cela peut être défini à l'aide de la stratégie locale. 3 tentatives infructueuses, puis vous les bloquez.
La sécurité physique l'emporte sur tout. Empêchez le BIOS de démarrer un CD ou une clé USB et verrouillez la boîte. Bien sûr, je réitère le commentaire ci-dessus, utilise le cryptage complet du disque, peut-être même multifactoriel. Vous ne pouvez pas monter un lecteur chiffré sous Linux comme par magie, vous devez connaître le mot de passe et/ou la clé.
Cold boot et evil maid nécessitent que quelqu'un investisse vraiment du temps pour casser votre machine. Sur votre ordinateur personnel local, il est plus probable que vous serez trompé par le téléchargement de logiciels malveillants ou que vous ayez un logiciel non corrigé et qu'ils obtiendront simplement la racine (ahem, administrateur) et ne se soucient pas de briser votre mot de passe.
Si vous avez de vrais trucs secrets, faites un cryptage complet du disque et mettez les trucs importants dans un conteneur de cryptage de deuxième niveau.
J'ai entendu un jour un seul informaticien dire que le seul ordinateur sécurisé est celui qui a mordu avec une hache puis brûlé. :-)