Cryptographie en pratique : les erreurs qui rendent votre chiffrement inutile

La cryptographie est facile à utiliser, difficile à bien utiliser

Les bibliothèques cryptographiques modernes sont accessibles à tout développeur. Mais choisir le bon algorithme, le bon mode, générer correctement les clés et les stocker en sécurité demande une expertise que la plupart des équipes n'ont pas. Le résultat : un chiffrement qui donne un faux sentiment de sécurité.

Erreur 1 : algorithmes obsolètes

MD5 et SHA1 pour le hachage de mots de passe

MD5 et SHA1 sont des fonctions de hachage rapides, conçues pour l'intégrité des données, pas pour les mots de passe. Un GPU moderne calcule des milliards de hachés MD5 par seconde. Le rainbow table pour MD5 est disponible publiquement.

Correction : utilisez bcrypt, scrypt ou Argon2id pour les mots de passe. Ces fonctions sont volontairement lentes et incluent un sel unique par mot de passe.

DES et 3DES pour le chiffrement

DES utilise une clé de 56 bits, cassable en quelques heures. 3DES est techniquement plus sûr mais vulnérable à l'attaque Sweet32 sur les blocs de 64 bits.

Correction : AES-256-GCM est le standard actuel. Pas de raison d'utiliser autre chose en 2026.

Erreur 2 : mode ECB

Le mode Electronic Codebook (ECB) chiffre chaque bloc indépendamment. Des blocs de texte clair identiques produisent des blocs chiffrés identiques. La structure des données est préservée dans le chiffré. L'image du pingouin Linux chiffrée en ECB est l'illustration classique de ce problème.

Correction : utilisez GCM (Galois/Counter Mode) qui fournit chiffrement et authentification. Ou CBC avec un HMAC séparé si GCM n'est pas disponible.

Erreur 3 : IV/nonce réutilisé

Un vecteur d'initialisation (IV) ou nonce réutilisé avec la même clé compromet complètement la confidentialité. En mode GCM, la réutilisation d'un nonce permet de récupérer la clé d'authentification et de forger des messages.

Correction : générez un IV aléatoire pour chaque opération de chiffrement. Pour AES-GCM, le nonce de 96 bits doit être unique pour chaque message chiffré avec la même clé.

Erreur 4 : clés codées en dur

Des clés de chiffrement dans le code source, dans des fichiers de configuration committés, ou dans des variables d'environnement partagées. La clé est la même en développement, staging et production.

Correction : utilisez un KMS (Key Management Service) cloud ou un HSM. Les clés ne doivent jamais apparaître en clair dans le code ou les fichiers de configuration. Implémentez la rotation des clés.

Erreur 5 : chiffrement sans authentification

Chiffrer avec AES-CBC sans HMAC permet à un attaquant de modifier le chiffré sans détection. Les attaques par oracle de padding (padding oracle attacks) exploitent cette faiblesse pour déchiffrer le message sans connaître la clé.

Correction : utilisez un mode authentifié (AES-GCM, ChaCha20-Poly1305) ou appliquez Encrypt-then-MAC avec un HMAC séparé.

Erreur 6 : génération de nombres aléatoires non cryptographiques

Utiliser Math.random() en JavaScript ou rand() en PHP pour générer des tokens, des clés ou des sels. Ces fonctions ne sont pas cryptographiquement sûres et leurs sorties sont prédictibles.

Correction : utilisez crypto.getRandomValues() en JavaScript, random_bytes() en PHP, secrets en Python, SecureRandom en Java.

Erreur 7 : validation de certificat désactivée

verify=False en Python requests, rejectUnauthorized: false en Node.js, curl -k en production. Désactiver la vérification TLS pour résoudre un problème de certificat rend toute la communication vulnérable aux attaques man-in-the-middle.

Ce que nous vérifions

Chez CleanIssue, nous analysons les choix cryptographiques de vos applications : algorithmes utilisés, gestion des clés, modes de chiffrement, qualité de l'aléatoire. Parlez-nous de votre revue externe pour identifier les faiblesses cryptographiques de votre application.