Mon école veut garder secrets les détails de notre système d'authentification de porte. est-ce une bonne idée?
Donc, je conçois un système d'authentification de porte (ne peut pas vraiment entrer dans les détails) pour notre école, afin que seules les personnes authentifiées puissent passer par une certaine porte interne. Ils soutiennent que son fonctionnement intérieur doit être gardé secret, afin que personne ne puisse le désosser. Je maintiens que ce serait la sécurité par l'obscurité , ce qui est mauvais. J'ai conçu le système de telle sorte que savoir comment il fonctionne ne vous aiderait pas à entrer, seulement avoir la clé vous aiderait à entrer, comme selon principe de Kerckhoff . Ils soutiennent toujours qu'au lieu que plus de gens le sachent, moins le devraient.
Est-ce une bonne idée d'aller avec un design fermé? Sinon, pourquoi exactement?
P.S. Ils ne m'ont dit que c'était un secret qu'après en avoir conçu la plupart et en ont parlé à un tas de gens, si cela faisait une différence (je ne savais pas qu'ils voulaient que ce soit un secret).
P.P.S. Bien qu'il ne soit pas ouvert sur l'extérieur, la pièce qu'il protège contient des objets plus précieux que le reste de l'école, donc je m'attendrais à ce que les adversaires soient en mesure de procéder à une ingénierie inverse de toute façon si nous optons pour une conception fermée au lieu d'une conception ouverte , mais je ne sais pas comment communiquer cela.
L'obscurité n'est pas une mauvaise mesure de sécurité à mettre en place. Se fier à l'obscurité, en tant que mesure de sécurité unique ou la plus substantielle, est plus ou moins un péché cardinal.
Principe de Kerckhoff est peut-être l'argument le plus souvent cité contre l'implémentation de la sécurité par l'obscurité. Cependant, si le système est déjà correctement sécurisé selon ce principe, cela est mal orienté.
Le principe, paraphrasé, dit "supposez que l'ennemi sait tout sur la conception de vos systèmes de sécurité". Cela n'implique en aucune façon "tout dire à l'ennemi sur votre système, car il le sait quand même".
Si le système est déjà bien conçu selon le principe de Kerckhoff, le pire qui puisse être dit à propos de l'application de la sécurité par l'obscurité, c'est qu'il n'ajoute que peu ou pas de valeur. Dans le même temps, pour un tel système, la protection de la confidentialité de sa conception présente également peu ou pas de préjudice.
Garder le design secret ne rend pas la porte peu sûre en soi; cependant, croire que cela renforce la sécurité est une illusion dangereuse.
Si révéler les détails du système d'authentification permettait de le casser, alors ce système est de la pure ordure et devrait être jeté. Par conséquent, si vous avez fait votre travail correctement, révéler les détails devrait être sans danger. Si vous avez fait pas faire votre travail correctement, alors tirez-vous et embauchez quelqu'un de compétent.
En général, la publication des détails du système favorise les révisions externes, ce qui entraîne le cycle de résolution des problèmes, ce qui améliore finalement la sécurité. Dans un contexte scolaire, ne pas publier les détails du système nuit à la sécurité, car les écoles sont pleines d'étudiants, et les étudiants sont connus pour être des anarchistes curieux qui seront particulièrement attirés par la rétro-ingénierie de tout ce qui leur est secret. Il est bien connu que dans une salle informatique pour étudiants, la meilleure façon de réduire les incidents de sécurité est de donner le mot de passe root/administrateur à quelques étudiants - lorsqu'un étudiant veut se familiariser avec la sécurité informatique, lui donnant un accès complet supprime toute incitation à essayer de casser des choses ET le transforme en auxiliaire de police gratuit pour surveiller les autres élèves.
En outre, détailler le fonctionnement interne d'un système de sécurité pourrait être une entreprise hautement pédagogique. J'ai entendu dire que dans certaines écoles, ils pratiquent la pédagogie, au moins occasionnellement. Votre école voudra peut-être essayer.
Vous avez déjà reçu plusieurs excellentes réponses, bien que les réponses de @ TomLeek et @ Iszi (toutes deux excellentes) semblent en contradiction directe.
Ils font tous deux d'excellents arguments: d'une part, garder le design secret ne sécurisera pas le système, tandis que le réviser publiquement vous permettra (éventuellement) de trouver certaines vulnérabilités que vous n'aviez pas envisagées; d'un autre côté, cela ne fait pas de mal de garder le design secret, tant que ce n'est pas un facteur clé dans la sécurité du design.
Les deux côtés sont absolument corrects - parfois .
Je pense qu'il serait juste de dire que les deux parties dans l'argument général conviendraient que garder le design secret n'augmente pas directement la sécurité du tout.
Dans le pire des cas, il cache simplement les failles de sécurité (qui peuvent ou non être une bonne chose, selon qui vous le considérez) être le plus caché).
Dans le meilleur des cas (où il n'y a pas de vulnérabilités triviales qui seraient exposées en publiant la conception), cela n'augmente toujours pas la sécurité - mais cela le fait minimiser la surface d'attaque.
Minimiser la surface d'attaque (même sans la présence d'une vulnérabilité) est définitivement une bonne chose; Cependant, cela doit être pesé et compromis par rapport aux avantages de la publication (à savoir être révisé par des groupes d'yeux supplémentaires), et l'inconvénient de le garder secret - par exemple la tentation de s'appuyer sur elle comme un contrôle de sécurité (la sécurité toujours populaire par l'obscurité), comme une forme de théâtre de la sécurité.
Il convient également de noter que, comme @Tikiman y a fait allusion, il ne suffit pas de publier le design pour s'assurer qu'il est examiné - en particulier par ceux qui sont capables pour trouver les vulnérabilités et qui sont également enclins à vous les divulguer. Dans de nombreux cas, une conception publiée ne serait examinée que par des individus malveillants ayant une intention illicite, vous n'obtiendrez donc pas le bénéfice escompté. De plus, souvent un ne sait même pas si leur conception tombe dans le meilleur ou le pire des cas susmentionné.
Donc, en fin de compte - comme dans tant de choses en matière de sécurité, la réponse directe est toujours: Cela dépend.
Il y a ici un compromis à prendre en considération - s'il s'agissait d'un cryptosystème complexe, la réponse serait claire; s'il s'agissait d'un système d'entreprise typique lourd d'implémentation, une réponse différente serait claire.
Mon penchant dans ce cas est comme l'a dit @Tom, mais pour les raisons secondaires mentionnées - en partie la base d'utilisateurs anarchique, et surtout l'objectif pédagogique.
Notez qu'il ne s'agit en fait pas vraiment de considérations de sécurité - du moins pas directement.
(Oh et quant au point de @ Tikiman - la pédagogie impliquée ici signifie que vous pouvez réellement vous assurer que le design est révisé, au moins par toute la classe ;-))
Ce article de Daniel Missler est super!
Il déclare que
La sécurité par obscurité est mauvaise, mais l'obscurité lorsqu'elle est ajoutée en tant que couche au-dessus d'autres contrôles peut être absolument légitime.
en ayant ce concept, une bien meilleure question serait
L'ajout d'obscurité est-il la meilleure utilisation de mes ressources étant donné les contrôles que j'ai en place, ou serais-je mieux d'ajouter un contrôle différent (non basé sur l'obscurité)?
Nous pouvons également utiliser l'anologie de camouflage comme obscurity as another layer of security
Un exemple puissant de ceci est camouflage . Considérons un char blindé tel que le M-1. Le char est équipé de certaines des armures les plus avancées jamais utilisées , et il a été prouvé à plusieurs reprises qu'il était efficace dans une bataille réelle.
Donc, étant donné cette armure très efficace, le danger pour le char augmenterait-il d'une manière ou d'une autre s'il devait être peint de la même couleur que son environnement? Ou que diriez-vous à l'avenir quand nous pourrons rendre le réservoir complètement invisible? Avons-nous réduit l'efficacité de l'armure? Non, nous ne l'avons pas fait. Rendre quelque chose de plus difficile à voir ne facilite pas l'attaque si ou quand il est découvert. C'est une erreur qui doit tout simplement se terminer.
Lorsque l'objectif est de réduire le nombre d'attaques réussies, en commençant par une sécurité solide et testée et en ajoutant de l'obscurité en tant que couche, vous bénéficiez globalement de la sécurité. Le camouflage accomplit cela sur le champ de bataille, et PK/SPA accomplit cela lors de la protection des services renforcés.
Je souligne.
Le commentaire d'Iszi est grand aussi, il déclare qu'il est beaucoup mieux de changer le mot adding en enforcing, donc en résumé ça ressemblera à ça
Résumé:
La sécurité par obscurité est mauvaise, mais la sécurité appliquée avec obscurité en tant que couche au-dessus d'autres contrôles peut être absolument légitime. Supposer que vous êtes en sécurité sur le champ de bataille parce que vous pensez que votre char est peint de la même couleur que l'environnement est tout simplement absurde . Mais rendre la défense de vos chars excellente et appliquer la peinture qui vous confère la capacité de camouflage comme une autre couche de protection est génial!
Bien qu'il ne réponde pas vraiment à votre question, cela pourrait servir d'argument à votre école.
Je considérerais que quelqu'un ayant accès à une clé/identité autorisée est le vrai risque. Les gens sont bâclés, utilisent de mauvais mots de passe et écrivent des secrets tout le temps. Il y a longtemps, un enseignant de mon école a laissé les clés de toute l'école dans une salle de bain pour étudiants.
Si je voulais entrer dans cette pièce, je ne prendrais même pas la peine d'essayer de trouver une faille de sécurité dans le logiciel; Je volerais la clé, j'essaierais de falsifier le verrou physique ou une autre méthode externe.
Ou, comme l'a dit un de mes amis, alors que le directeur lui avait demandé comment il procéderait pour pirater le système scolaire afin de détruire les données; "J'utiliserais une batte de baseball".
J'ai une longue explication qui peut sembler errer, je vais donc donner une réponse abrégée, puis la justifier. Réponse courte, c'est la sécurité par l'obscurité, mais ce n'est probablement pas un problème en raison du nombre de personnes qui entrent en contact avec le système. Cela ne vaut donc probablement pas la peine de se disputer.
Vous avez raison d'affirmer que garder secret la conception du système est la sécurité par l'obscurité (STO). La principale raison pour laquelle la STO est une mauvaise idée est qu'un système dont le fonctionnement interne n'est pas initialement connu peut être rétro-conçu dans tous les cas grâce à une observation attentive et à la bonne application de l'ingénierie sociale. Si vous êtes la seule personne à comprendre le fonctionnement d'un système, vous êtes la seule personne à pouvoir vérifier son intégrité. Par conséquent, s'il existe une faille potentiellement contournable dans votre conception et que quelqu'un d'autre procède à l'ingénierie inverse de votre conception et la découvre, il peut l'exploiter plus facilement que si vous n'aviez pas gardé vos conceptions secrètes. Ils sont également plus susceptibles de garder secret leur découverte et leur utilisation illicite.
En effet, si vous rendez votre conception publique, plus de personnes l'examineront, plus il y aura de personnes qui examineront une conception, plus il y aura de chances que quelqu'un découvre un défaut existant et vous en parle. Un défaut de conception peut même ne pas être dans le concept général, mais dans l'implémentation spécifique, comme la possibilité d'un débordement de tampon dans la mise en œuvre d'un algorithme autrement sécurisé. Le concept principal de l'utilisation des primitives cryptographiques publiques est qu'en informant tout le monde de vos algorithmes primitifs cryptographiques, d'autres peuvent les examiner. Une fois qu'un grand nombre de personnes l'ont fait, vous pouvez être raisonnablement assuré que votre conception est sécurisée. La difficulté est que parce que vous créez un design pour une école, seul un très petit nombre de personnes sont susceptibles de voir vos designs, dont très peu sont susceptibles de les comprendre. Moins il y a de personnes qui consultent vos créations, plus il est probable que tous ceux qui découvrent un défaut ne le signalent pas.
À moins que vous n'ayez accès à une grande communauté de professionnels de la sécurité désireux d'examiner votre conception, les laisser faire leur chemin peut être à peu près égal en termes de sécurité réelle.
Si j'étais responsable de la porte, j'aurais la même exigence de confidentialité. Si le monde (et votre travail) était parfait, l'obscurité serait en effet inutile.
Mais pensez à ce qui se passe réellement dans un monde réel. Je suppose que vous avez fait votre travail du mieux que vous pouviez, en utilisant des algorithmes de pointe. Mais le diable se cache dans les détails, et un détail d'implémentation peut affaiblir la sécurité. C'est arrivé à la bibliothèque SSL il n'y a pas si longtemps, même si les algos étaient en effet sécurisés.
Ce que vous voulez lorsque vous divulguez les détails de votre système de sécurité, c'est que les pairs examinent votre implémentation et vous avertissent d'éventuels défauts avant qu'ils ne soient découverts et utilisés par des attaquants. Si vous connaissez des experts en système de sécurité et demandez-leur de revoir votre travail, je pense que ce serait considéré comme une bonne pratique même dans votre école - à mon humble avis devrait au moins. Mais si vous venez de le publier, il est plus probable que vos premiers lecteurs seront ceux contre lesquels la sécurité de la porte a été construite! Et vous ne voulez certainement pas qu'ils soient les premiers à examiner votre travail pour d'éventuels défauts.
TL/DR: Si vous construisez un système de sécurité général, cela pourrait avoir un large public et que vous ne l'utilisez pas immédiatement en production, vous devez le publier aussi largement que possible pour obtenir de bonnes critiques. Mais si vous construisez une implémentation dédiée qui sera immédiatement utilisée pour une sécurité réelle, ne divulguez les détails qu'à des experts de confiance pour éviter d'aider les attaquants à trouver d'éventuelles failles.
Un objectif évident serait que le système d'authentification de porte ne puisse pas être piraté par les étudiants.
Si nous supposons que le système d'authentification est légèrement mais pas très difficile à pirater, et qu'il y a des étudiants avec certaines mais pas de compétences avancées en piratage, il est fort possible que la difficulté supplémentaire posée par la non-disponibilité des détails du système soit juste suffisante. le mettre hors de portée de ce groupe (les élèves).
D'un autre côté, une fois que le système est si sécurisé qu'il est beaucoup plus difficile de le craquer que de trouver ou de procéder à une ingénierie inverse du fonctionnement du système, garder les détails secrets n'est plus très utile.