Caractères d’injection dans les mots de passe : pourquoi le mot de passe le plus solide fait planter le site

Le patron a posé la question avec un sourire : et si le meilleur mot de passe était celui qui fait planter le site ? C’est plus profond qu’il n’y paraît.

Voici comment la plupart des gens pensent aux caractères d’injection dans les mots de passe et à la sécurité : choisir quelque chose de long, mélanger des majuscules, ajouter un chiffre, peut-être un point d’exclamation. Les conseils n’ont quasiment pas changé depuis vingt ans. Mais la menace réelle, elle, a complètement évolué. Aucun attaquant ne va s’asseoir devant un clavier et taper 500 millions de tentatives à la main. Le matériel moderne de craquage peut tester des milliards de hachages par seconde. La longueur de votre mot de passe compte. Le spectacle de la complexité, non.

Ce qui compte vraiment, et dont presque personne ne parle, c’est ce qui se passe quand votre mot de passe contient des caractères qui ont une signification particulière pour le logiciel derrière le formulaire de connexion. Des caractères comme ', ", ;, --, /, #, $ et |. Ce ne sont pas de simples signes de ponctuation. Ce sont des instructions en SQL, en scripting shell, en analyse d’URL. Et quand un développeur négligent construit un formulaire de connexion qui envoie votre mot de passe directement dans une requête de base de données sans le nettoyer au préalable, ces caractères cessent d’être votre mot de passe pour devenir du code.

Caractères d’injection dans les mots de passe : comment un formulaire de connexion devient une porte dérobée

L’exemple classique est l’injection SQLAttaque où du code SQL malveillant est inséré dans un champ de saisie pour manipuler ou contourner une requête de base de données.. Imaginez une page de connexion qui vérifie vos identifiants ainsi :

SELECT * FROM users WHERE username = 'vous' AND password = 'votremotdepasse'

Si vous tapez nimportequoi' OR '1'='1 dans le champ mot de passe, la requête devient :

SELECT * FROM users WHERE username = 'vous' AND password = 'nimportequoi' OR '1'='1'

Comme '1'='1' est toujours vrai, la base de données renvoie tous les utilisateurs. Vous êtes connecté. Sans mot de passe. Comme le documente la Web Security Academy de PortSwigger, un attaquant peut se connecter en tant que n’importe quel utilisateur sans connaître le mot de passe, simplement en utilisant la séquence de commentaire SQL -- pour supprimer entièrement la vérification du mot de passe.

Ce n’est pas un problème théorique. L’injection SQL est à l’origine de certaines des plus grandes violations de données de l’histoire. C’est ce qu’OWASP qualifie de l’une des attaques les plus courantes et les plus dangereuses sur les applications web.

Le test ironique : s’ils interdisent vos caractères, ils sont probablement incapables de les gérer

Voilà le paradoxe que le patron voulait souligner. Quand un site vous dit « les mots de passe ne peuvent pas contenir de caractères spéciaux », il vous révèle involontairement quelque chose d’important sur sa sécurité.

Une application bien construite ne se soucie jamais des caractères dans votre mot de passe. Le mot de passe est haché avant de toucher une base de données. Une fonction de hachage transforme P@$$w0rd';DROP TABLE-- en la même sorte de charabia de longueur fixe qu’elle fait de correcthorsebatterystaple. Les caractères dangereux disparaissent dans le processus de hachage. Ils n’atteignent jamais la requête SQL, la commande shell ni quoi que ce soit d’autre.

Si un site interdit les caractères spéciaux, l’une de deux choses est vraie : soit les développeurs font preuve d’une prudence excessive face à un problème qu’ils pourraient résoudre correctement, soit (plus préoccupant) ils font transiter votre mot de passe par des systèmes qui s’étoufferaient sur ces caractères. Le second scénario implique que votre mot de passe pourrait atteindre une requête de base de données, un script shell ou un système hérité sans nettoyage approprié.

Le chercheur en sécurité Daniel Miessler tient depuis 2007 une liste de la honte des sites qui rejettent les caractères spéciaux. La liste originale incluait de grandes banques comme Chase, Wells Fargo et Suntrust. Le développeur Scott Hanselman a rencontré un service financier qui lui indiquait « Password should not contain any special characters, symbols or spaces » (« Le mot de passe ne doit contenir aucun caractère spécial, symbole ou espace ») et a souligné l’absurdité : un site qui gère votre argent décourage activement les mots de passe solides.

Ce que le NIST dit désormais

L’Institut national américain des normes et de la technologie a mis à jour ses recommandations sur les mots de passe dans SP 800-63B-4, publié en version finale en 2025. Les changements sont significatifs. Le NIST exige désormais que les systèmes acceptent tous les caractères ASCII et Unicode dans les mots de passe, autorisent jusqu’à 64 caractères, et imposent une longueur minimale de 15 caractères. Les règles de complexité obligatoires ont été explicitement abandonnées : plus de majuscules imposées, plus de caractères spéciaux requis, plus de renouvellement périodique.

Le raisonnement est simple. Les règles de complexité obligatoires poussaient les gens à créer des mots de passe comme P@ssw0rd1!, qui semble complexe à un vérificateur de politique mais est trivial pour un outil de craquage. C’est la longueur et l’aléatoire qui résistent réellement aux attaques par force brute.

Mais voici ce que le NIST a bien compris et que la plupart des gens manquent : la norme dit d’accepter tous les caractères. Elle ne dit pas de les exiger. Le point est que rien dans votre mot de passe ne devrait faire planter le système. Si c’est le cas, c’est le système qui est défaillant.

La vraie menace n’est pas la devinette, c’est la fuite

Le plus grand danger pour les mots de passe en 2026 n’est pas que quelqu’un devinera le vôtre. C’est que l’entreprise qui le stocke le laissera fuiter. En 2019, Facebook a admis qu’entre 200 et 600 millions de mots de passe d’utilisateurs avaient été stockés en texte clair, consultables par plus de 20 000 employés, avec des archives remontant à 2012. Pas hachés. Pas chiffrés. En texte clair.

Facebook n’était pas un cas isolé. Une analyse de F5 Labs de 2021 a révélé que le stockage en texte clair était responsable de la majorité des incidents de fuite d’identifiants en 2020. De nombreuses organisations stockaient encore des mots de passe sans les hacher du tout, ou utilisaient des algorithmes obsolètes comme MD5 sans salage.

Quand les mots de passe sont stockés en texte clair, la complexité de votre mot de passe est sans importance. $uP3r_S3cur3!@#% et password123 sont exposés de la même façon. La seule défense, c’est de ne pas avoir de compte là-bas.

Ce qu’il faut retenir

Que faire concrètement ?

• Utilisez un gestionnaire de mots de passe. Laissez-le générer des mots de passe longs et aléatoires. 20 caractères ou plus, n’importe quel caractère que le site accepte.
• Testez la tolérance du site. Si un formulaire d’inscription rejette ', " ou ; dans votre mot de passe, c’est un signal. Cela peut être une conception trop prudente, ou un signal d’alarme sur l’architecture de sécurité du site.
• Ne traitez pas ce signal comme une preuve. Rejeter les caractères spéciaux est suspect, mais les accepter ne garantit pas non plus une bonne sécurité. Beaucoup de sites acceptent n’importe quoi et stockent quand même les mots de passe en texte clair.
• Utilisez la double authentification partout où elle est disponible. Un mot de passe fuité compte beaucoup moins quand l’attaquant a aussi besoin de votre téléphone.
• Ne réutilisez pas les mots de passe. Si un site laisse fuiter vos identifiants, tous les autres sites partageant ce mot de passe sont compromis.

La vérité inconfortable, c’est que la sécurité des mots de passe ne dépend pas vraiment de vous. Vous pouvez tout faire correctement et être quand même exposé par une entreprise qui stocke votre mot de passe dans un tableur. La meilleure défense est de minimiser la confiance que vous accordez à un seul service dans votre vie numérique.

La question posée fonctionne aussi comme heuristique de test d’intrusion : que se passe-t-il quand votre mot de passe est lui-même une charge utile d’injection ? La réponse en dit plus sur la posture de sécurité d’un site que n’importe quelle politique de confidentialité.

La sagesse conventionnelle sur les caractères d’injection dans les mots de passe se concentre sur l’entropie : des mots de passe plus longs avec des jeux de caractères plus larges résistent mieux aux attaques par force brute. C’est vrai mais incomplet. Le tableau des mots de passe Hive Systems 2025 évalue les temps de craquage en utilisant 12 GPU RTX 5090 contre bcrypt (facteur de travail 10). Un mot de passe de 8 caractères composé uniquement de chiffres tombe en quelques secondes. Un mot de passe de 8 caractères mélangeant tous les types de caractères tient des mois. Un mot de passe aléatoire de 16 caractères en ASCII complet demande un temps géologique. La longueur gagne.

Mais l’entropie n’est une défense que contre un vecteur d’attaque spécifique : le craquage hors ligne par force brute de hachages volés. Elle ne dit rien de ce qui se passe quand le mot de passe lui-même est interprété comme une syntaxe exécutable.

Caractères d’injection dans les mots de passe : la mécanique

Considérons la requête de connexion vulnérable classique :

SELECT * FROM users WHERE username = '$user' AND password = '$pass'

Si $pass est concaténé dans cette chaîne sans requêtes paramétréesTechnique de requête où les données utilisateur sont traitées séparément de la structure SQL, empêchant les attaques par injection. ni échappement approprié, un mot de passe comme ' OR '1'='1 effondre la logique d’authentification. PortSwigger documente la technique spécifique : soumettre administrator'-- comme nom d’utilisateur avec un mot de passe vide réécrit la requête en SELECT * FROM users WHERE username = 'administrator'--' AND password = '', commentant entièrement la vérification du mot de passe.

L’injection SQLAttaque où du code SQL malveillant est inséré dans un champ de saisie pour manipuler ou contourner une requête de base de données. est la variante la plus connue, mais les champs de mot de passe peuvent aussi être des vecteurs pour :

• L’injection de commandes OS. Si un script backend transmet le mot de passe à une commande shell (courant dans les systèmes d’authentification hérités, les wrappers LDAP ou les scripts personnalisés), des caractères comme ;, |, $(...) et les apostrophes inversées deviennent des vecteurs d’injection de commandes. Un mot de passe contenant ; rm -rf / pourrait, dans une implémentation désastreuse, s’exécuter sur le serveur.
• L’injection LDAP. Des caractères comme *, (, ) et ont une signification particulière dans les requêtes LDAP. Une entrée de mot de passe non nettoyée dans une opération de liaison LDAP peut modifier la logique de la requête.
• L’injection XPath. Si l’authentification touche un entrepôt de données XML, ' et " peuvent briser les expressions XPath de la même façon qu’ils brisent SQL.

Le dénominateur commun : le mot de passe est traité comme faisant partie d’une structure de contrôle plutôt que comme une donnée opaque. La défense correcte est connue depuis des décennies : requêtes paramétrées pour SQL, échappement approprié pour les commandes shell, et la recommandation d’OWASP de ne jamais construire des commandes à partir d’entrées utilisateur concaténées.

L’heuristique du rejet de caractères

Quand un site rejette les caractères spéciaux dans les mots de passe, il révèle l’une de trois choses :

1. La défense en profondeurStratégie de cybersécurité utilisant plusieurs couches de protection indépendantes, de sorte qu'une défaillance isolée ne compromette pas l'ensemble du système. mal appliquée. Les développeurs connaissent l’injection mais ont choisi la restriction des entrées plutôt que la désinfection appropriée. C’est le meilleur cas et constitue toujours une violation des directives OWASP sur les mots de passe, qui listent 33 caractères spéciaux devant être acceptés.
2. Les mots de passe traversent des chemins de code non désinfectés. Les caractères sont rejetés parce qu’ils provoquent des erreurs ou des comportements inattendus en aval : dans SQL, dans les scripts shell, dans les intergiciels hérités. Cela signifie que le mot de passe transite par ces systèmes sous une forme pouvant être interprétée comme du code.
3. Les mots de passe sont stockés ou comparés en texte clair. Si le mot de passe était haché avant tout traitement, les caractères spéciaux seraient sans importance. Un hachage bcrypt de '; DROP TABLE users;-- est une chaîne inoffensive de 60 caractères. Les restrictions de caractères suggèrent que le mot de passe brut persiste plus loin dans le pipeline de traitement qu’il ne le devrait.

La « liste de la honte » de Daniel Miessler (2007) citait Chase, Wells Fargo et American Express parmi les banques rejetant les caractères spéciaux. Scott Hanselman a signalé un service financier qui demandait aux utilisateurs « Password should not contain any special characters, symbols or spaces » (« Le mot de passe ne doit contenir aucun caractère spécial, symbole ou espace »). Un commentateur sur ce billet a noté que Verizon exigeait autrefois des caractères spéciaux à l’inscription mais les rejetait à la connexion, un comportement cohérent avec un système où deux chemins de code différents gèrent le même mot de passe différemment.

NIST SP 800-63B-4 : la norme est désormais d’accord

NIST SP 800-63B-4 (finalisé en août 2025) codifie ce que les praticiens de la sécurité soutiennent depuis des années. Les exigences clés pour l’authentification par mot de passe :

• Les vérificateurs DOIVENT accepter tous les caractères ASCII imprimables, le caractère espace, et les caractères Unicode.
• Longueur minimale du mot de passe : 15 caractères (quand le mot de passe est l’unique authentificateur).
• Longueur maximale : au moins 64 caractères.
• Aucune règle de composition (pas de majuscules, chiffres ou caractères spéciaux obligatoires).
• Pas de rotation périodique des mots de passe sauf en cas de preuve de compromission.

Le projet de septembre 2024 qui a précédé la version finale déclarait explicitement : « Humans have a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. » (« Les humains ont une capacité limitée à mémoriser des secrets complexes et arbitraires, ils choisissent donc souvent des mots de passe faciles à deviner. ») Le virage va de l’exigence de complexité (qui produit P@ssw0rd1!) vers l’exigence de longueur et d’acceptation des caractères (ce qui permet correct horse battery staple et ses 44 bits d’entropie).

Le problème du stockage éclipse le problème de la devinette

Le craquage hors ligne est une menace sérieuse, mais il nécessite une base de données de hachages volés. La défaillance la plus courante est bien plus simple : des mots de passe stockés sous forme récupérable.

En mars 2019, Brian Krebs rapportait que Facebook stockait entre 200 et 600 millions de mots de passe en texte clair, consultables par plus de 20 000 employés. Les journaux d’accès montraient environ 9 millions de requêtes internes touchant des données contenant des mots de passe en texte clair. Les archives remontaient à 2012.

Facebook n’était pas un cas isolé. Le rapport F5 Labs 2021 sur le credential stuffingUne cyberattaque où des outils automatisés testent de grandes listes d'identifiants et mots de passe volés sur de nombreux sites, en exploitant le fait que beaucoup d'utilisateurs réutilisent les mêmes identifiants., résumé par Securden, a révélé que le stockage en texte clair représentait la majorité des incidents de fuite d’identifiants en 2020. Les organisations continuaient à utiliser des hachages faibles (MD5, SHA-1 sans salage) ou aucun hachage du tout. Face aux critères de référence de Hive Systems, un mot de passe haché en MD5 tombe des ordres de grandeur plus vite qu’un mot de passe haché en bcrypt de longueur et complexité identiques.

Quand les mots de passe sont stockés en texte clair ou avec un hachage faible, l’entropie de votre mot de passe est sans importance. Tous les mots de passe sont également compromis. La seule défense est l’isolation des identifiants : mots de passe uniques par service, gérés par un gestionnaire de mots de passe, avec la double authentification comme filet de sécurité.

Le diagnostic

L’observation initiale tient comme heuristique pratique :

• Essayez de vous inscrire avec des caractères spéciaux dans votre mot de passe. Des caractères comme ', ", ;, --, $ et | constituent le jeu de test minimal. Si le site les rejette, il est soit trop prudent, soit réellement vulnérable.
• L’acceptation est nécessaire mais pas suffisante. Un site peut accepter ' dans un mot de passe et le stocker quand même en texte clair. Le test élimine les pires contrevenants ; il ne certifie pas les autres.
• Si un site ne peut pas gérer la ponctuation standard dans un champ de mot de passe, interrogez-vous sur ce qu’il ne peut pas gérer d’autre. L’entrée de mot de passe est l’entrée utilisateur la plus simple qu’une application web traite. S’ils ratent ça, la surface d’attaque est probablement plus large que le seul formulaire de connexion.

La logique sous-jacente est solide : si les développeurs étaient trop paresseux pour paramétrer correctement un champ de mot de passe, il y a peu de raisons de penser qu’ils l’ont haché, salé, ou sécurisé la base de données dans laquelle il vit. Le mot de passe le plus solide n’est pas seulement long et aléatoire. C’est celui qui ferait planter un système mal conçu. Et s’il plante le système, vous avez votre réponse : n’y créez pas de compte.