La sécurité par l'obscurité consiste à protéger un système en cachant son fonctionnement, en espérant qu'un attaquant ne le comprendra pas. C'est une fausse sécurité : le secret finit toujours par fuiter, et un mécanisme caché n'est jamais vérifié par personne, donc jamais corrigé. La bonne règle, énoncée dès 1883 par Auguste Kerckhoffs, est l'inverse : un système doit rester sûr même si tout le monde connaît son mécanisme, car seule la clé secrète le protège. Cette page définit le principe sans aucun prérequis technique, montre pourquoi cacher le mécanisme échoue, et explique la nuance utile entre reposer sur l'obscurité et simplement ne pas trop en dire.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Le sujet a mauvaise réputation, mais il cache une nuance que beaucoup ratent. Concrètement, vous saurez :
- Définir la sécurité par l'obscurité et le principe de Kerckhoffs avec des exemples du quotidien.
- Comprendre pourquoi cacher un mécanisme donne une fausse confiance et finit toujours par se retourner contre vous.
- Distinguer « reposer sur l'obscurité » (mauvais) de « ne pas divulguer inutilement » (acceptable et même utile).
- Repérer les pièges classiques, comme croire qu'un port non standard ou un code fermé suffit à protéger.
- Relier ce principe à la surface d'attaque, à la défense en profondeur et au modèle de menaces SOCLE, qui traduisent cette idée en décisions concrètes.
Qu'est-ce que la sécurité par l'obscurité
Section intitulée « Qu'est-ce que la sécurité par l'obscurité »La sécurité par l'obscurité désigne toute protection qui repose sur le fait de cacher comment un système fonctionne. L'idée sous-jacente est simple : si personne ne sait comment votre serrure est faite, personne ne saura la crocheter. Le problème, c'est que cette protection ne tient que tant que le secret tient, et un secret partagé, utilisé, déployé partout, ne reste jamais secret longtemps.
Le contre-principe a un nom et une date. En 1883, Auguste Kerckhoffs, un linguiste et cryptographe néerlandais, énonce une règle restée fondatrice : un système de protection doit rester sûr même si l'attaquant connaît tout de son fonctionnement, à la seule condition qu'il ignore la clé. Autrement dit, on ne cache pas la machine, on cache uniquement le secret qui l'ouvre. Cette idée porte aussi le nom d'open design (conception ouverte) : le mécanisme est public, la clé est privée.
Une analogie rend la différence limpide. Imaginez deux maisons. La première a une serrure d'une marque obscure, et le propriétaire compte sur le fait que personne ne connaît son modèle pour se sentir protégé. Le jour où un cambrioleur identifie la marque, souvent en un coup d'oeil, il trouve la méthode de crochetage en ligne et la serrure ne vaut plus rien. La seconde maison a une serrure éprouvée, dont le mécanisme est connu, étudié, testé par des milliers de spécialistes, et dont seule la clé est secrète. Tout le monde sait comment elle fonctionne, personne ne peut l'ouvrir sans la bonne clé. La seconde approche est celle de Kerckhoffs, et c'est celle sur laquelle repose toute la cryptographie moderne.
Ce raccourci du quotidien vaut aussi pour le chiffrement (transformer des données en une suite illisible sans la clé). Les algorithmes de chiffrement sérieux sont publics, documentés, analysés depuis des années. Leur solidité ne vient pas du secret de la méthode, mais du fait que même en la connaissant parfaitement, on ne peut rien faire sans la clé.
Pourquoi c'est une fausse sécurité
Section intitulée « Pourquoi c'est une fausse sécurité »Le premier problème de l'obscurité est brutal : le secret finit toujours par fuiter. Il fuite par rétro-ingénierie (le fait d'analyser un logiciel ou un objet pour reconstituer son fonctionnement interne, en l'observant ou en le décortiquant). Il fuite par accident, quand une configuration se retrouve exposée sur Internet. Il fuite par les gens : un départ d'employé mécontent, un prestataire bavard, une capture d'écran partagée. Une protection qui dépend d'un secret que des dizaines de personnes connaissent n'est pas une protection, c'est un compte à rebours.
Le second problème est plus insidieux : un mécanisme caché n'est jamais audité. Quand une méthode reste secrète, personne d'extérieur ne peut la vérifier, chercher ses failles, ni signaler ses défauts. Les erreurs restent donc cachées avec le mécanisme, jusqu'au jour où un attaquant, lui, les trouve. À l'inverse, un mécanisme public est examiné par des chercheurs, des curieux et des concurrents. Ses faiblesses sont découvertes et corrigées avant d'être exploitées. La transparence n'affaiblit pas le système, elle le rend plus robuste, car elle transforme des milliers de regards en autant de relecteurs.
C'est exactement ce qui distingue les algorithmes de chiffrement modernes des recettes maison. Une entreprise qui invente son propre chiffrement secret croit se protéger en le cachant. En réalité, elle se prive de toute vérification et hérite presque toujours de failles grossières qu'un algorithme public aurait éliminées depuis longtemps. Dans le domaine, la formule est connue : ne réinventez jamais votre propre cryptographie.
Obscurité et défense : une nuance importante
Section intitulée « Obscurité et défense : une nuance importante »Il serait faux de conclure qu'il faut tout publier de son système. Le principe de Kerckhoffs interdit de reposer sur l'obscurité, il n'interdit pas de rester discret. La nuance est capitale, et beaucoup la ratent dans les deux sens : certains cachent tout en croyant que ça suffit, d'autres exposent tout en croyant faire preuve de rigueur.
La bonne posture tient en une phrase : l'obscurité ne doit jamais être la seule défense, mais réduire l'information exposée reste utile en complément. Un exemple parlant est la bannière de version (le message qu'un logiciel affiche pour annoncer son nom et sa version, comme un serveur qui répond « je suis tel logiciel version 1.4 »). Masquer cette bannière n'empêche personne de vous attaquer, mais cela évite d'offrir sur un plateau la liste des failles connues de cette version précise à un attaquant qui scanne au hasard. Vous ne comptez pas sur ce secret pour être en sécurité, vous êtes déjà protégé par ailleurs, et vous réduisez juste le bruit exposé.
Il faut donc bien distinguer deux attitudes. « Reposer sur l'obscurité » signifie que votre sécurité s'effondre si le secret tombe : c'est la mauvaise idée. « Ne pas divulguer inutilement » signifie que votre sécurité tient toujours sans ce secret, mais que vous évitez de faciliter le travail de l'attaquant : c'est acceptable, et même recommandé. Cette seconde attitude est une couche parmi d'autres, ce qu'on appelle la défense en profondeur, où l'on empile plusieurs protections indépendantes plutôt que de tout miser sur une seule.
Un scénario concret
Section intitulée « Un scénario concret »Prenez une petite équipe qui héberge une application de gestion en ligne. Pour « sécuriser » l'accès administrateur, elle déplace la page d'administration à une adresse peu évidente, du genre une longue suite de lettres, et se dit que personne ne la trouvera. Il n'y a pas de mot de passe fort derrière, pas de limitation des tentatives, pas de second facteur : toute la protection repose sur le fait que l'adresse reste secrète. C'est de la sécurité par l'obscurité à l'état pur.
Le secret ne tient pas. Un jour, un développeur colle par erreur le lien complet dans un ticket public. Une autre fois, l'adresse apparaît dans les journaux d'un service tiers. Un robot qui scanne des milliers de sites finit par tomber dessus. Le jour où l'adresse circule, il n'y a plus rien pour arrêter l'attaquant, car toute la défense reposait sur ce seul secret désormais éventé.
La même équipe, en appliquant Kerckhoffs, raisonne autrement. Elle suppose que l'adresse d'administration sera connue, et elle place la vraie protection derrière : un mot de passe robuste, une authentification à deux facteurs (une seconde preuve d'identité, comme un code à usage unique, en plus du mot de passe), et un blocage après plusieurs échecs. Elle peut, en complément, garder l'adresse discrète pour réduire le bruit, mais elle ne compte pas dessus. Le jour où l'adresse fuite, l'attaquant se heurte à un mur, et l'incident reste sans conséquence. La différence ne tient pas à un outil magique, elle tient au fait de ne jamais faire reposer la sécurité sur un secret fragile.
Pièges courants
Section intitulée « Pièges courants »Le principe est simple à énoncer, mais quelques réflexes trompeurs reviennent sans cesse. Les repérer évite de croire son système protégé alors qu'il ne l'est qu'en apparence.
Le piège le plus répandu est de croire qu'un port non standard protège. Un port est un numéro qui identifie un service réseau sur une machine, un peu comme un numéro d'appartement dans un immeuble. Déplacer un service d'un port habituel vers un port inhabituel réduit le bruit des scans automatiques, mais un attaquant déterminé balaie tous les ports en quelques secondes. Le port discret est un confort, jamais une serrure. Si la seule chose qui protège votre service est son numéro de port, vous n'êtes pas protégé.
Le deuxième piège est de croire qu'un code fermé est plus sûr. Garder le code source (les instructions qui composent un logiciel) secret ne le rend pas robuste : cela empêche seulement les relecteurs honnêtes de trouver ses failles, pas les attaquants, qui les trouvent quand même par rétro-ingénierie. Un logiciel n'est pas sûr parce qu'il est fermé, ni faible parce qu'il est ouvert. Sa solidité vient de sa conception, pas de sa visibilité.
Le troisième piège est de confondre discrétion et protection. Ne pas afficher sa version, ne pas nommer sa technologie, ne pas exposer ses chemins internes : tout cela réduit la surface d'attaque, la somme des points par lesquels on peut être attaqué, ce que détaille la page sur la surface d'attaque. Mais réduire l'information exposée n'est utile qu'en plus de vraies protections. Prise seule, la discrétion ne fait que retarder l'inévitable.
À retenir
Section intitulée « À retenir »-
L'obscurité n'est pas une sécurité : cacher le fonctionnement d'un système donne une fausse confiance, car le secret finit toujours par fuiter.
-
Principe de Kerckhoffs : un système doit rester sûr même si l'attaquant connaît tout de son mécanisme, seule la clé doit rester secrète.
-
Un mécanisme public est plus robuste : il est audité, testé et corrigé, alors qu'un mécanisme caché garde ses failles jusqu'à ce qu'un attaquant les trouve.
-
Ne jamais réinventer sa cryptographie : les algorithmes publics et éprouvés battent toujours une recette maison gardée secrète.
-
Reposer sur l'obscurité ≠ ne pas divulguer : le premier s'effondre si le secret tombe, le second reste debout et sert juste de couche complémentaire.
-
Discrétion utile en complément : masquer une bannière de version ou un port réduit le bruit, mais ne remplace jamais une vraie protection.
-
Traduire le principe en menaces réelles : le modèle de menaces SOCLE montre, domaine par domaine, quelles attaques exploitent une défense qui reposait sur un secret fragile.