Il semble qu'il y ait une confusion possible à la lecture du journal entre obscurité et secret. Même si il y a une petite phrase au milieu clarifiant un peu.
On peut considérer que le codage de César (ou rot 13 ou autre décalage) se repose sur l'obscurité parce qu'il n'y a que l'algorithme qui protège. Pu on peut considérer que l'algorithme est public (décaler) et que le secret est le nombre de décalages. Dans ce cas c'est juste une très mauvaise solution car il est facile d'essayer toutes les combinaisons. L'exemple est donc assez bancal à mon avis.
Dans le monde de la cryptographie, il y a de nombreux algorithmes de chiffrement/déchiffrement, qu'ils soient symmetriques ou asymétriques, qui sont publics. Mais la clef (privée si asymétrique) doit rester un secret. Ce n'est pas de la sécurité par l'obscurité. C'est le principe même.
Il en est de même des mots de passes ou des séquences de port knocking. Ce sont des secrets. Les principes/algorithmes peuvent être publics sans nuire à la sécurité.
Il reste que si un attaquant a besoin d'acquérir une certaine information avant de pouvoir concevoir une attaque (par exemple que ssh n'est pas sur le port habitué, qu'il faut faire du port knocking, que tel ou tel nom d'utilisateur est utilisé et peut se connecter) cela rend l'attaque plus difficile. Vu le nombre de tentatives de connexions que reçoit un serveur ssh connecté à internet sur le port par défaut, ce genre de technique simple réduit énormément les risques d'exploitation opportuniste. Les plus simples sont beaucoup moins efficace contre des attaques ciblées.
Mais il me semble que là encore, on est un peu à la limite de la sécurité par l'obscurité. Quand on parle de sécurité par l'obscurité, il me semble que c'est plutôt dans le contexte de garder le code source (et éventuellement les algorithmes) secrets afin d'éviter que des gens malintentionnés y trouvent des failles. Le problème c'est que ça empêche aussi des gens bien intentionnés d'y trouver des failles. Et donc les failles y restent. Elles ne sont pas impossibles à trouver cependant, et de nombreux outils peuvent aider à les trouver. Mais oa barrière est plus haute et ve sont en général les gens mal intentionnés qui ont le plus de moyens.
D'ici à conclure que l'open source est plus sûr que le closed source, il n'y a qu'un pas, que je ne franchirais personnellement pas. Autant le code de projets centraux comme Linux est très scruté car trouver une faille critique dedans est très prestigieux pour un chercheur ou ingénieur dans le domaine de la sécurité, autant le prestige diminue très vite avec la baisse de visibilité du projet et l'on se retrouve avec des failles majeures qui peuvent passer inaperçu pendant des années dans des outils pourtant largement utilisés. La récente backdoor dans xz montre même que le caractère opensource peut faciliter l'introduction de backdoor (même si un scénario semblable peut être imaginé dans un environnement closed source et serait d'autant plus difficile à détecter).
# Confusion
Posté par Colin Pitrat (site web personnel) . En réponse au journal Les toqueurs ont la tactique. Évalué à 10. Dernière modification le 30 juin 2024 à 11:16.
Il semble qu'il y ait une confusion possible à la lecture du journal entre obscurité et secret. Même si il y a une petite phrase au milieu clarifiant un peu.
On peut considérer que le codage de César (ou rot 13 ou autre décalage) se repose sur l'obscurité parce qu'il n'y a que l'algorithme qui protège. Pu on peut considérer que l'algorithme est public (décaler) et que le secret est le nombre de décalages. Dans ce cas c'est juste une très mauvaise solution car il est facile d'essayer toutes les combinaisons. L'exemple est donc assez bancal à mon avis.
Dans le monde de la cryptographie, il y a de nombreux algorithmes de chiffrement/déchiffrement, qu'ils soient symmetriques ou asymétriques, qui sont publics. Mais la clef (privée si asymétrique) doit rester un secret. Ce n'est pas de la sécurité par l'obscurité. C'est le principe même.
Il en est de même des mots de passes ou des séquences de port knocking. Ce sont des secrets. Les principes/algorithmes peuvent être publics sans nuire à la sécurité.
Il reste que si un attaquant a besoin d'acquérir une certaine information avant de pouvoir concevoir une attaque (par exemple que ssh n'est pas sur le port habitué, qu'il faut faire du port knocking, que tel ou tel nom d'utilisateur est utilisé et peut se connecter) cela rend l'attaque plus difficile. Vu le nombre de tentatives de connexions que reçoit un serveur ssh connecté à internet sur le port par défaut, ce genre de technique simple réduit énormément les risques d'exploitation opportuniste. Les plus simples sont beaucoup moins efficace contre des attaques ciblées.
Mais il me semble que là encore, on est un peu à la limite de la sécurité par l'obscurité. Quand on parle de sécurité par l'obscurité, il me semble que c'est plutôt dans le contexte de garder le code source (et éventuellement les algorithmes) secrets afin d'éviter que des gens malintentionnés y trouvent des failles. Le problème c'est que ça empêche aussi des gens bien intentionnés d'y trouver des failles. Et donc les failles y restent. Elles ne sont pas impossibles à trouver cependant, et de nombreux outils peuvent aider à les trouver. Mais oa barrière est plus haute et ve sont en général les gens mal intentionnés qui ont le plus de moyens.
D'ici à conclure que l'open source est plus sûr que le closed source, il n'y a qu'un pas, que je ne franchirais personnellement pas. Autant le code de projets centraux comme Linux est très scruté car trouver une faille critique dedans est très prestigieux pour un chercheur ou ingénieur dans le domaine de la sécurité, autant le prestige diminue très vite avec la baisse de visibilité du projet et l'on se retrouve avec des failles majeures qui peuvent passer inaperçu pendant des années dans des outils pourtant largement utilisés. La récente backdoor dans xz montre même que le caractère opensource peut faciliter l'introduction de backdoor (même si un scénario semblable peut être imaginé dans un environnement closed source et serait d'autant plus difficile à détecter).