🚫 Les algorithmes à bannir (et pourquoi ils traînent encore en 2025)

Les algorithmes à bannir sont pourtant bien connus : MD5, SHA-1, RC4, DES… la liste ressemble plus à un cimetière qu’à une boîte à outils moderne. Et pourtant, en 2025, ils continuent de hanter nos systèmes d’information comme des fantômes qu’on n’arrive pas à exorciser. Sérieusement, on peut envoyer des sondes sur Mars et générer du code avec une IA, mais certaines bases de données RH stockent encore des mots de passe en MD5. Spoiler : non seulement c’est obsolète, mais c’est criminel. Prenons donc un moment pour se moquer (gentiment, ou pas) de ces dinosaures crypto que certains refusent d’enterrer.

🔑 MD5 : le zombie qui refuse de mourir

MD5, c’est un peu comme Windows XP : tout le monde sait qu’il est mort, mais il continue de hanter les coins les plus sombres de l’IT. Conçu en 1991, cracké depuis 2004 (oui, il y a 21 ans !), MD5 est l’algorithme de hachage le plus maltraité de l’histoire.

Collisions ? Faciles.
Rainbow tables ? Un jeu d’enfant.
Hashcat le croque en quelques millisecondes avec une carte graphique correcte.

Et pourtant, j’ouvre encore des bases utilisateurs en 2025 et je vois… MD5(password). Sérieux, on hash les mots de passe avec le même niveau de sécurité qu’un cadenas en plastique vendu chez Action.

👉 Alternative : SHA-256, SHA-3, et surtout des fonctions de dérivation adaptées aux mots de passe comme bcrypt, scrypt ou Argon2.

🪦 SHA-1 : le cousin qui aurait dû partir à la retraite en 2010

SHA-1, c’est le grand frère de MD5, qui a essayé de faire croire qu’il était solide. En réalité, c’était juste un ado fragile sous stéroïdes. En 2017, Google a officiellement annoncé une attaque par collision réussie (projet SHAttered). Depuis, c’est plié.

Et pourtant, on trouve encore du SHA-1 :

Dans de vieux certificats SSL internes.
Dans des systèmes industriels pas mis à jour « parce que ça tourne encore ».
Dans certains protocoles maison bricolés par des devs persuadés que « SHA-1 c’est suffisant, de toute façon qui irait attaquer notre appli de facturation ? ».

👉 Alternative : SHA-256 ou SHA-3, mais vraiment, oubliez SHA-1 comme vous avez oublié vos mots de passe Hotmail.

⚰️ DES et 3DES : la sécurité des années 70 en mode revival

DES (Data Encryption Standard), adopté en 1977, c’était génial à l’époque. Le problème ? Sa clé de 56 bits se casse aujourd’hui avec un Raspberry Pi et un café serré. Il a été officiellement déclaré mort par le NIST en 2005, mais… surprise ! On le trouve encore dans certaines applis bancaires anciennes et protocoles embarqués.

Et 3DES alors ? Ah, le fameux « triple DES » censé prolonger la vie du patient. Une rustine qui a tenu un temps, mais qui est aujourd’hui tout aussi interdit (bloqué par PCI-DSS en 2018). En gros, c’est comme mettre trois cadenas de vélo sur une porte de coffre-fort : ça reste nul, juste plus lourd.

👉 Alternative : AES (Advanced Encryption Standard), adopté en 2001. Pas d’excuse : il est standard, solide, rapide et disponible partout.

🕸️ RC4 : le cauchemar en streaming

RC4, inventé dans les années 80, a longtemps été utilisé dans TLS, WEP et d’autres protocoles réseau. Le problème ? Une faiblesse structurelle qui rend ses flux pseudo-aléatoires… pas du tout aléatoires. Résultat : attaques pratiques, fuites de clés, et une vulnérabilité massive dans le Wi-Fi (RIP WEP).

Et pourtant, certains admins système se disent encore : « Allez, on laisse RC4 activé, au cas où un vieux client ne supporte pas mieux ». Traduction : « Offrons un boulevard à un attaquant en 2025, juste pour faire plaisir à une imprimante de 2007 ».

👉 Alternative : AES-GCM, ChaCha20-Poly1305 pour les flux réseau.

🪓 RSA faible : la clé trop courte, c’est la honte

RSA, en soi, reste un algorithme utilisé et robuste — à condition d’employer des clés de taille adaptée. Le souci, c’est qu’on croise encore des infrastructures avec des clés ridiculement petites :

des clés de 512 bits (casse quasi instantanée),
des clés de 1024 bits (vulnérables face à des adversaires motivés).

Pourquoi ces tailles pourries ? Ce n’est pas seulement de la paresse : historique oblige, des restrictions légales et d’export (dans les années 1990–2000, certaines réglementations limitaient la diffusion de la cryptographie forte) ont poussé des éditeurs et intégrateurs à standardiser et déployer des clés plus courtes pour rester « exportables ». Le résultat : des systèmes hérités ont été mis en production avec des clés trop faibles… et certains sont encore en production en 2025.

👉 En 2025, la règle est simple : 2048 bits minimum, et mieux vaut viser 3072 ou 4096 bits pour les usages sensibles. Si tu trouves encore du 1024 bits dans ton SI, considère-le comme une bombe à retardement — plan de migration immédiat.

📜 Pourquoi on les utilise encore ?

C’est la partie la plus pathétique de l’histoire : on sait que ces algorithmes sont morts depuis longtemps, mais ils traînent toujours. Pourquoi ?

Inertie : « ça marche, on n’y touche pas ».
Legacy : systèmes bancaires, industriels ou embarqués trop coûteux à mettre à jour.
Ignorance : devs ou admins qui n’ont jamais mis les pieds dans une conf sécurité.
Compatibilité : le fameux « il y a encore un client sous Windows XP qui doit se connecter ». Sérieusement, on va sacrifier la sécu de tout un SI pour un poste musée ?

🎭 Les excuses bidon les plus entendues

« Mais c’est en interne, donc c’est pas grave. » → Jusqu’au jour où un stagiaire balance la base sur Pastebin.
« Personne n’attaquerait notre appli métier. » → Parce que les ransomwares font dans la philanthropie, sans doute.
« Ça coûterait trop cher de migrer. » → Attendez de voir la facture d’un incident.
« On n’a pas le temps. » → Mais vous avez trouvé le temps pour refaire le logo en flat design.

✅ Que faire en 2025 ?

Audit des applis et protocoles : identifiez où traînent encore MD5, SHA-1, DES, RC4.
Forcer la mise à jour des bibliothèques crypto (OpenSSL, Java, .NET…).
Exiger du SHA-256 ou plus fort, AES-GCM ou ChaCha20-Poly1305, RSA >= 2048 bits.
Mettre en place des politiques de sécurité strictes : interdiction des algos faibles dans les configs TLS, VPN, certificats internes.
Former vos devs et admins : la crypto, ce n’est pas une option.

🧨 Conclusion : stop au paléocrypto

La morale est simple : si vous utilisez encore MD5, SHA-1, DES, RC4 ou des clés RSA trop courtes, vous jouez à la roulette russe avec votre SI. Et le barillet est déjà plein.

La cryptographie, c’est comme l’hygiène : on ne négocie pas. Alors la prochaine fois que vous croisez du MD5 dans une base, n’hésitez pas : débranchez le serveur, mettez une pancarte « Danger : relique », et organisez une cérémonie d’enterrement. En 2025, on n’a plus d’excuse.

🚫 Les algorithmes à bannir (et pourquoi ils traînent encore en 2025)

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com