Les années passent… et il y a encore du NTLMv1 qui traîne.
Mandiant a récemment émis un rappel à ce sujet… et l’a accompagné de rainbow tables. Il y en a pour environ 100 Go de données, sous licence CC BY 4.0, téléchargeables via la console Google Cloud ou l’outil gsutil (elles sont dans des buckets GCP).
Promesse : grâce à ces tables, récupérer des clés en moins de 12 heures avec du matériel grand public coûtant moins de 600 $. Une méthode alternative aux attaques par force brute avec hashcat et Cie. Lesquelles sont moins efficaces à mesure que la longueur des secrets augmente.
Pour quelques rainbow tables de plus
Les rainbow tables de Mandiant semblent cibler les mots de passe de 7 caractères de longueur.
Le projet RainbowCrack – une référence dans le domaine, intégré à notamment à Kali Linux – va jusqu’à 10 avec ses propres tables. Il annonce des taux de réussite entre 96,8 % et 99,9 %.
Plage de caractères
Nombre de caractères
Taux de réussite
Poids
Ascii 32 à 95
7
99,9 %
52 Go
Ascii 32 à 95
8
96,8 %
460 Go
Majuscules, minuscules, chiffres
8
99,9 %
127 Go
Majuscules, minuscules, chiffres
9
96,8 %
690 Go
Minuscules, chiffres
9
99,9 %
65 Go
Minuscules, chiffres
10
96,8 %
316 Go
NTLM, un grand chantier pour Microsoft
De longue date, la v1 du protocole NTLM est considérée comme insuffisamment sécurisé. Le guide de l’ANSSI sur l’administration des environnements Active Directory résume sa faiblesse : il permet d’obtenir des condensats (hashs) par simple capture du trafic réseau. Dans la pratique, les attaques forceront typiquement l’authentification depuis un objet AD à haut niveau de privilèges, comme un contrôleur de domaine.
NTLMv1 a officiellement été supprimé des OS Microsoft avec Windows 11 24H2 et Windows Server 2025. Mais il y a des restes dans certains scénarios. Entre autres lors de l’utilisation de MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2) dans un environnement joint à un domaine. Solution recommandée : déployer Credential Guard… et exploiter les fonctionnalités d’audit, renforcées pour l’occasion.
L’objectif de Microsoft est de désactiver complètement le protocole à terme, pour aller vers Kerberos. Il a fallu adapter ce dernier afin de lui apporter certaines caractéristiques spécifiques de NTLM – qui ont d’ailleurs favorisé son intégration « en dur » par certaines applications. Par exemple, l’absence d’exigence de connexion réseau locale à un contrôleur de domaine. La fonctionnalité dite IAKerb a été introduite à ces fins. Elle permet l’authentification sur un contrôleur de domaine via un serveur mandataire.
La principale contrainte pour traiter des données à haut débit n’est plus le calcul ni le stockage, mais le réseau.
En 2017, les équipes d’AWS avaient contextualisé ainsi un article présentant les choix de conception de la base de données Aurora, lancée deux ans plus tôt.
Voilà cet article cité dans un autre, émanant de l’université technique de Munich. Ses auteurs ont analysé l’évolution des spécifications matérielles du cloud public entre 2015 et 2025. S’ils mentionnent le cas Aurora, c’est parce que, selon eux, le postulat d’alors ne tient plus. Sur la période en question, à coût normalisé, la bande passante réseau proposée par AWS a crû sans commune mesure avec les performances CPU et NVMe. Dans ce contexte, Aurora, conçu pour minimiser le trafic réseau, gagnerait peut-être à être réarchitecturé…
Une analyse axée bases de données
L’analyse n’est pas exhaustive, reconnaissent ses auteurs.
En premier lieu, elle est centrée sur les instances EC2 d’AWS, malgré quelques éléments de comparaison avec d’autres clouds publics et avec les infrastructures sur site.
Ensuite, elle se focalise sur un cas d’usage « base de données ». Aussi, les instances avec accélérateurs et FPGA ont été exclues. Et celles dotées de GPU ont été abordées séparément. N’ont pas non plus été prises en compte les instances à capacité extensible (familles T et flex).
Quant aux prix, la tarification retenue est celle à la demande dans la région us-east-1 (la principale du cloud AWS, et la moins chère). Les instances Spot ne sont pas entrées en ligne de compte en raison de leurs tarifs très variables en fonction de la demande. Les savings plans et les instances réservées n’ont pas non plus été inclus, au motif que les remises sont « largement similaires » entre types d’instances (en les retirant, on ne distord donc pas significativement la structure tarifaire d’ensemble).
L’aspect optimisation logicielle a par ailleurs été laissé de côté.
Ces restrictions appliquées, le périmètre d’analyse a englobé 742 instances, groupées en 98 familles.
CPU : une stagnation pas spécifique aux cloud providers
Comme pour les serveurs on-prem, la gamme de CPU s’est nettement diversifiée en 10 ans. En première ligne, les puces Arm : depuis 2024, plus de la moitié des instances que lance AWS sont équipées en Graviton.
En parallèle, le nombre de cœurs a largement augmenté. Exemple : la famille c4, lancée en 2015, en proposait jusqu’à 18, quand la c7a, introduite en 2023, monte à 192.
La progression du ratio coût-performance se révèle plus limitée. En tout cas sur la foi de trois benchmarks, exécutés sur diverses instances 2xlarge optimisées pour le calcul :
SPECint 2018
TPC-H in-memory (facteur d’échelle de 10) sur Umbra
TPC-C sur Leanstore (25 entrepôts)
Les résultats sont normalisés par rapport au coût et à la performance de l’instance c4.2xlarge. Bilan : sur SPECint, le ratio est multiplié par 3 environ sur la période. On serait plutôt à x2 sans les instances Graviton, vers lesquelles ont d’ailleurs basculé des fournisseurs comme Snowflake.
Sur la partie base de données in-memory, la progression est similaire (entre x2 et x2,5). La latence de la mémoire et du cache a possiblement beaucoup d’influence, reconnaissent les auteurs de l’étude, qui n’ont pas analysé ces dimensions.
Cette relative stagnation n’apparaît pas pour autant liée aux marges que prennent les cloud providers. En tout cas sur la foi d’une analyse sur les CPU serveur d’AMD sortis entre 2017 et 2025. Sur la base des prix publics, du nombre de cœurs, des fréquences d’horloge et des métriques IPC communiquées, le rapport coût-performance ne double même pas (x 1,7).
Mémoire : peu de gains en capacité comme en bande passante
À coût normalisé, la capacité de DRAM a très peu progressé. Seul changement majeur : l’introduction, en 2016, d’une famille d’instances optimisées pour la mémoire, avec environ 3,3 fois plus de GiB-heures/$ que les meilleures instances optimisées pour le calcul.
La bande passante absolue par socket mono-CPU a significativement augmenté (de 93 à 492 GiB/s). Mais une fois normalisée, le gain n’est que de x2.
Un bond en avant sur le réseau… avec les instances optimisées
En valeur absolue, le plafond de bande passante sur EC2 est passé de 10 Gbit/s en 2015 à 600 Gbit/s en 2025. Surtout, le rapport coût-performance normalisé a décuplé. En toile de fond, la mise à disposition d’instances optimisées pour le réseau. La c5n, première du genre basée sur le système Nitro, fut ajoutée au catalogue en 2018.
Si on exclut ces instances optimisées, le rapport bande passante par dollar a peu évolué entre 2015 et 2025.
Stockage : comparaison défavorable pour AWS
L’analyse s’est focalisée sur les instances avec stockage NVMe local. La première famille du genre (i3) fut introduite en 2016. La première avancée notable en termes de capacité de stockage par dollar fut le lancement de la famille i3en en 2019. Le ratio avait alors doublé. Il a peu évolué depuis.
Même réflexion si on considère le coût des I/O : les i3 demeurent les plus avantageuses, tant en lecture séquentielle qu’aléatoire.
Cette stagnation dans le cloud public contraste avec les tendances de l’on-prem : à coût normalisé, la capacité par dollar a triplé et le coût des I/O a été divisé par 5. L’arrivée de PCIe4 puis de PCIe5 a joué.
Des opportunités dans le hardware spécialisé
Un indicateur est ici analysé : le volume d’opérations 32 bits en virgule flottante à coût normalisé.
Avec les GPU, le rapport coût-performance a été multiplié par environ 4,7 entre les familles d’instances p3 et g6e.
Depuis 2019, AWS a lancé deux générations d’instances inf et trn dotées d’ASIC dédiés au machine learning. Les trn2 délivrent deux fois plus de flops/s par device que les g6e ; et le ratio coût-performance est multiplié par 15,7 par rapport aux p3.
La spécialisation du hardware peut donc se révéler avantageuse… y compris pour le traitement de données (l’étude fait référence à divers travaux* sur ce sujet).
Caches NVMe, cycles processeur… Des questions d’architecture émergent
Combinée à la démultiplication des débits réseau, la stagnation des performances du stockage pose des questions pour des solutions comme Snowflake, qui utilisent des caches NVMe plutôt que de lire directement sur S3.
Autre combinaison, autre enjeu : tandis que la bande passante réseau croît et que la vitesse des processeurs stagne, le budget en cycles CPU par paquet décline. Exploiter pleinement les ressources disponibles pourrait exiger des modifications majeures touchant par exemple au contournement du noyau.
Avec les instances Arm, l’amélioration du rapport coût-performance se constante autant sur le calcul (c8g) que sur le réseau (c8gn), la capacité mémoire (x2gd) et la capacité NVMe (is4gen).
Voir au-delà des hyperscalers
La tendance est la même dans les autres clouds… sauf que, de manière générale, les VM – Arm ou x86 – peuvent être notablement moins chères que chez les hyperscalers. Oracle et OVHcloud sont cités à ce sujet, sur la foi d’une comparaison pour des instances à CPU AMD 16 cœurs, 128 GiB de RAM et sans fonctionnalités spécifiques de type grande bande passante réseau. Hetzner l’est aussi, avec son instance CCX53, 3,7 fois moins chère que la m6a.8xlarge d’AWS. En contrepartie, ces fournisseurs ont un écosystème moins fourni, une couverture géographique plus limitée, une facturation parfois moins granulaire et un éventail plus restreint d’instances spécialisées (susceptibles de faire baisser les coûts pour certains cas d’usage).
Entre les « trois grands », il y globalement peu d’écart… avec quelques exceptions (AWS a l’avantage sur la bande passante réseau avec les instances c7gn/c8gn, Microsoft ne facture pas le trafic entre zones de disponibilité au sein d’une même région, etc.).
Un outil interactif pour dépasser l’analyse statique
Vu la nature multidimensionnelle de l’univers des instances cloud, une analyse statique est intrinsèquement limitée, admettent les auteurs de l’étude. Ils fournissent donc un outil interactif open source associant moteur SQL et visualisation R. Le service fonctionne intégralement dans le navigateur (pas de dépendance serveur). La base sous-jacente est téléchargeable (fichier DuckDB).
Connexion
