Question:
Systèmes open source vs systèmes fermés
blunders
2011-06-08 23:10:07 UTC
view on stackexchange narkive permalink

Je crois comprendre que les systèmes open source sont généralement considérés comme plus sûrs que les systèmes fermés.

Raisons pour adopter l'une ou l'autre approche, ou combinaison de ceux-ci, notamment: les normes culturelles, le positionnement financier, juridique, la sécurité nationale, etc. L'une des principales préoccupations est la sécurité. Une position commune contre les systèmes open source est qu'un attaquant pourrait exploiter les faiblesses du système s'il est connu. Une position commune contre les systèmes à source fermée est qu'un manque de sensibilisation est au mieux une mesure de sécurité faible; communément appelé sécurité par l'obscurité.

La question est la suivante: les systèmes open source sont-ils en moyenne meilleurs pour la sécurité que les systèmes fermés? Si possible, veuillez citer des analyses dans autant de secteurs que possible, par exemple: logiciel, militaire, marchés financiers, etc.

Cette question était Question de sécurité informatique de la semaine .
Lisez le article de blog du 25 mai 2012 pour plus de détails ou envoyez votre propre Question de la semaine.

Avant de répondre "à quel point ceci est-il sûr par rapport à cela", nous avons besoin d'un système de mesure. Comment mesurez-vous le nombre de vulnérabilités? Ce sera plus difficile pour les sources fermées, ce qui, je pense, est la raison pour laquelle les gens se sentent souvent ** plus en sécurité avec l'open source.
quand vous montrez à quelqu'un comment une serrure est fabriquée, ce n'est qu'une question de temps avant qu'il la prenne.
Sept réponses:
Jesper M
2011-06-09 01:22:01 UTC
view on stackexchange narkive permalink

L'idée que les logiciels open source sont intrinsèquement plus sûrs que les logiciels fermés - ou la notion opposée - est absurde. Et quand les gens disent quelque chose comme ça, c'est souvent juste FUD et ne fait pas avancer la discussion de manière significative.

Pour raisonner à ce sujet , vous devez limiter la discussion à un projet spécifique . Un logiciel qui gratte une démangeaison spécifique, est créé par une équipe spécifique et a un public cible bien défini. Dans un cas aussi spécifique, il peut être possible de se demander si l'open source ou le code source fermé serviront au mieux le projet.

Le problème avec la présentation de toutes les implémentations "open source" par rapport à toutes les implémentations "source fermée" est que l'on ne se contente pas de comparer les licences. Dans la pratique, l'open source est favorisé par les efforts des bénévoles, et le code source fermé est le plus courant dans les efforts commerciaux. Nous comparons donc:

  • Licences.
  • Accès au code source.
  • Des structures d'incitation très différentes, pour -profit versus amusement.
  • Des situations de responsabilité juridique très différentes.
  • Des équipes et des compétences d'équipe différentes et extrêmement variables.
  • etc.

Pour essayer de juger comment tout cela fonctionne pour la sécurité de tous les logiciels publiés en open / fermé source, il suffit de tomber en panne. Cela devient une déclaration d'opinion, pas un fait.

Je suis d'accord. Ce qui compte le plus, c'est le nombre de personnes ayant des connaissances et une expérience dans le domaine de la sécurité qui conçoivent, implémentent, testent et maintiennent activement le logiciel. Tout projet où personne ne s'intéresse à la sécurité présentera des vulnérabilités importantes, quel que soit le nombre de personnes participant au projet.
C'est vrai, mais donner "accès au code source" est potentiellement extrêmement précieux. Avoir des yeux extérieurs sur votre code apporte de nouvelles perspectives qui pourraient manquer dans l'équipe de développement. Vous pouvez même faire quelque chose comme https://stripe.com/blog/capture-the-flag, avec un vrai projet, avec des prix pour le meilleur bug trouvé (évidemment, ne pas divulguer les détails jusqu'à ce qu'un correctif soit sorti!)
Heartbleed en est un bon exemple. OpenSSL est bien, ouvert, depuis des années. Pourtant, cet énorme trou de sécurité n'a pas été détecté pendant des siècles.
@SameerAlibhai Mais il a été détecté.Avec les logiciels fermés, nous ne savons tout simplement pas si de tels bogues existent.Il est beaucoup plus difficile de les tester (bien que nous puissions faire une analyse dynamique limitée).De tels bogues pourraient exister dans des logiciels fermés populaires avec une fréquence beaucoup plus élevée ... ou peut-être pas.Nous ne savons tout simplement pas.
La source fermée ne fait rien pour atténuer les inquiétudes des utilisateurs finaux concernant la possibilité d'une porte dérobée, ce qui constitue une menace de sécurité valide.
Les incitatifs n'ont pas grand-chose à voir avec cela.Dire que la source fermée est à but lucratif et que l'open source est pour le plaisir est non seulement trompeur, mais carrément incorrect.Une société entièrement open source, Red Hat, est dans le Fortune 500. Google travaille fortement sur l'open source (par exemple Chromium et AOSP), et ceux-ci sont utilisés par des milliards.
@Geremia Un exemple tristement célèbre de porte dérobée placée par le fournisseur serait le [rootkit Sony] (https://en.wikipedia.org/wiki/Sony_rootkit).Donc, IMO, cela dépend vraiment de votre modèle de menace.Si votre modèle de menace comprend la protection contre le fournisseur, alors le logiciel libre est un meilleur choix.
Thomas Pornin
2011-06-09 01:20:23 UTC
view on stackexchange narkive permalink
Les logiciels

maintenus sont plus sécurisés que les logiciels qui ne le sont pas. L'effort de maintenance étant, bien entendu, relatif à la complexité dudit logiciel et au nombre (et à la compétence) des personnes qui le consultent. La théorie derrière le fait que les systèmes open source sont plus sûrs est qu'il y a "de nombreux yeux" qui regardent le code source. Mais cela dépend beaucoup de la popularité du système.

Par exemple, en 2008 ont été découverts dans OpenSSL plusieurs débordements de tampon, dont certains conduisant à l'exécution de code à distance. Ces bogues se trouvaient dans le code depuis plusieurs années. Ainsi, bien qu'OpenSSL était open source et avait une base d'utilisateurs substantielle (il s'agit, après tout, de la principale bibliothèque SSL utilisée pour les sites Web HTTPS), le nombre et la compétence des auditeurs de code source n'étaient pas suffisants pour surmonter les complexité du décodage ASN.1 (la partie d'OpenSSL où les bogues se cachaient) et du code source d'OpenSSL (franchement, ce n'est pas le code source C le plus lisible qui soit).

Les systèmes source fermés ont, en moyenne , beaucoup moins de gens pour faire Q&A. Cependant, de nombreux systèmes fermés ont des développeurs et des testeurs rémunérés , qui peuvent s’engager à plein temps. Ce n'est pas vraiment inhérent à la question ouverte / fermée; certaines entreprises emploient des personnes pour développer des systèmes open source et, en théorie, on pourrait produire gratuitement un logiciel à code source fermé (ceci est relativement courant dans le cas des «freewares» pour Windows). Cependant, il existe toujours une forte corrélation entre avoir des testeurs rémunérés et être source fermée (la corrélation n'implique pas de causalité, mais cela ne signifie pas non plus que les corrélations doivent être ignorées).

D'un autre côté, être la source fermée permet de dissimuler plus facilement les problèmes de sécurité, ce qui est mauvais , bien sûr.

Il existe des exemples de systèmes open source et fermés, avec de nombreux ou très peu de problèmes de sécurité. Les systèmes d'exploitation OpenSource * BSD ( FreeBSD, NetBSD et OpenBSD, et quelques autres) ont de très bons antécédents en matière de sécurité. Il en va de même pour Solaris, même lorsqu'il s'agissait d'un système d'exploitation à source fermée. D'un autre côté, Windows a (avait) une réputation terrible dans ce domaine.

Résumé: à mon avis, l'idée «open source implique la sécurité» est surfaite. Ce qui est important, c'est le temps (et la compétence) consacré au suivi et à la résolution des problèmes de sécurité, et ceci est principalement orthogonal à la question de l'ouverture de la source. Cependant , vous voulez non seulement un système sécurisé, mais également un système que vous savez positivement être sécurisé (ne pas être cambriolé est important, mais pouvoir dormir la nuit aussi). Pour ce rôle, les systèmes open source ont un léger avantage: il est plus facile d'être convaincu qu'il n'y a pas de trou de sécurité délibérément caché lorsque le système est open source. Mais la confiance est une chose instable, comme cela a été démontré avec la tragicomédie récente autour des prétendues portes dérobées dans OpenBSD (pour autant que je sache, cela s'est avéré être un hareng rouge, mais, conceptuellement, je ne peux pas être bien sûr, sauf si je vérifie le code moi-même).

Bien sûr, l'importance de la sécurité pour le responsable du logiciel est essentielle. Il peut être maintenu pour la facilité d'utilisation sans être maintenu pour la sécurité.
+1 pour avoir soulevé la question de la maintenance. De plus, la théorie «assez de globes oculaires» (également connue sous le nom de loi de Linus) dépend grandement de la présence de globes oculaires * entraînés * - et quand il s'agit de bogues de sécurité subtils, il y en a beaucoup moins.
user2213
2011-06-09 03:22:09 UTC
view on stackexchange narkive permalink

Je pense que la solution la plus simple et la plus simple est celle du génie logiciel. L'argument est généralement le suivant: le logiciel open source est plus sûr car vous pouvez voir la source !

Avez-vous les connaissances en génie logiciel pour comprendre le noyau de haut en bas? Bien sûr, vous pouvez regarder un tel pilote, mais avez-vous une connaissance complète de ce qui se passe vraiment pour dire "ah oui, il doit y avoir un bug là-bas"?

Voici un exemple intéressant: non il y a si longtemps, un bogue de déréférence de pointeur nul est apparu dans l'un des noyaux bêta, ce qui était assez important, découvert par le gars de grsecurity (correctifs PaX):

Il a été introduit dans un morceau de code comme celui-ci:

  pointer = struct->otherptr; if (pointer == NULL) {/ * gestion des erreurs * /} / * le code continue, en déréférençant ce pointeur qui, avec l'extraction optimisée, peut être NULL. Problème. * /  

et la vérification pointer == NULL a été optimisée par le compilateur, à juste titre - puisqu'un pointeur nul ne peut pas être déréférencé vers une structure contenant des membres, il n'a aucun sens pour que le pointeur de la fonction soit jamais nul. Le compilateur supprime ensuite la vérification que le développeur s'attendait à être là.

Bon, vis-à-vis, de manière concordante, le code source d'un projet aussi volumineux peut bien sembler correct - mais ne l'est pas.

Le problème est le niveau de connaissance nécessaire ici. Non seulement vous devez être assez familier avec (dans ce cas) C, l'assembly, le sous-système du noyau particulier, tout ce qui accompagne le développement des noyaux, mais vous devez également comprendre ce que fait votre compilateur.

Ne vous méprenez pas, je suis d'accord avec Linus pour dire qu'avec suffisamment d'yeux, tous les insectes sont superficiels. Le problème est la connaissance du cerveau derrière les yeux. Si vous payez 30 whiz kids pour développer votre produit mais que votre projet open source ne compte que 5 personnes qui ont une réelle connaissance de la base de code, alors il est clair que la version source fermée a une plus grande probabilité de moins de bogues, en supposant une complexité relativement similaire .

De toute évidence, c'est aussi pour tout projet donné transitoire au fil du temps, comme Thomas Pornin en parle.

Mise à jour modifiée pour supprimer les références à gcc qui sont fausses, car ce n'était pas le cas.

+1, j'ai toujours proposé un amendement à la loi de Linus: "Avec suffisamment de globes oculaires * entraînés *, la plupart des bogues sont relativement superficiels".
from isc.sans.edu/diary.html?storyid=6820 "En d'autres termes, le compilateur introduira la vulnérabilité du code binaire, qui n'existait pas dans le code source." c'est une déclaration dénuée de sens manifestement absurde. ** Le code source est bogué, il est donc vulnérable. ** La façon dont le compilateur génère du code détermine les exploits possibles.
Ok, vous avez raison, je me suis trompé - il déréférence `tun` alors que` tun` pourrait être `NULL` - ce qui est carrément mauvais. C'est suffisant. Je supprimerai la référence à une option gcc offensante, car ce n'était pas le problème. Le reste de l'exemple, à titre illustratif, est très bien.
Si vous regardez l'exemple de code et que vous vous demandez en quoi il s'agit d'une erreur de codage, ne perdez pas votre temps.L'exemple de code est bâclé et ne reflète pas le code réel.Ma modification a été rejetée car "Cette modification ne correspond pas à l'intention d'origine du message.".Je suppose que l'intention initiale est de semer la confusion.
Ori
2011-06-12 06:27:34 UTC
view on stackexchange narkive permalink

Je pense que les prémisses les plus utilisées pour faire la différence entre fermé et open source sont assez bien définies. Beaucoup d'entre eux sont énumérés ici, les deux ont leurs avocats. Sans surprise, les promoteurs de Closed Source sont ceux qui le vendent. Les partisans de l'Open Source en ont également fait une entreprise agréable et ordonnée (au-delà de quelques-uns qui l'ont adopté comme religion.)

Le mouvement Pro Open Source parle des bases, et quand il s'agit de sécurité en général, voici les points qui correspondent le plus à la discussion:

  1. Le principe de la personnalisation
  2. Le principe de la gestion des licences
  3. Le principe du format ouvert
  4. La prémisse de Many Eyes
  5. La prémisse de Quick Fix

Donc, en décomposant cela par prémisse, je pense que les deux derniers ont été couverts assez succinctement par d'autres ici, alors je vais les laisser tranquilles.

  1. La prémisse de personnalisation
    S'agissant de la sécurité, la prémisse de personnalisation donne aux entreprises qui adoptent le logiciel la possibilité de créer des éléments supplémentaires contrôle de sécurité sur une plate-forme existante sans avoir à sécuriser une licence ou à convaincre un fournisseur de réparer quelque chose qui lui appartient. Il permet aux organisations qui ont besoin, ou qui voient une lacune, d'augmenter la sécurité globale d'un produit. SELinux est un exemple parfait, vous pouvez remercier la NSA de redonner cela à la communauté.

  2. Le principe de gestion des licences
    On évoque souvent le fait que si vous utilisez des technologies F / OSS, vous n'avez pas besoin de gérer des licences technologiques avec des tiers (ou si vous le faites, c'est beaucoup moins.), Et cela peut être vrai des écosystèmes entièrement Open Source. Mais de nombreuses licences (notamment la GPL) imposent des exigences aux distributeurs, et la plupart des environnements du monde réel sont des mélanges hétérogènes de technologies fermées et open source. Ainsi, même si elle réduit finalement les dépenses en logiciels, la disponibilité de la source peut conduire certaines entreprises à violer les licences OSS en gardant la source privée lorsqu'elles ont l'obligation de libérer la source. Cela peut finalement transformer le principe de gestion des licences en responsabilité (qui est l'argument de source fermée contre les licences comme la GPL.)

  3. Le Open Format Premise
    C'est un gros problème, et je suis plutôt d'accord, donc je resterai bref pour ne pas prêcher. Dans 30 ans, je veux pouvoir ouvrir un fichier que j'ai écrit. Si le fichier est "protégé" à l'aide de contrôles DRM propriétaires et que le logiciel dont j'ai besoin pour y accéder n'est plus vendu, la difficulté d'accéder à mon propre contenu a considérablement augmenté. S'il existe un format utilisé pour créer mon document qui est ouvert et disponible dans un produit open source d'il y a 30 ans, je serai probablement en mesure de le trouver et de l'utiliser légalement. Certaines entreprises se lancent dans le wagon du groupe "Open Formats" sans sauter dans le train en marche Open Source, donc je pense que cet argument est assez solide.

Il y a un Sixième prémisse que je n'ai pas énumérée, car elle n'est pas bien discutée. J'ai tendance à rester coincé là-dessus (appelez cela paranoïa.) Je pense que la sixième prémisse est la plume dans le chapeau des départements de la défense du monde entier. Il a été expliqué au monde entier lorsqu'une partie de la source Windows 2000 a été divulguée.

La prémisse de la responsabilité fermée de source
Si une entreprise a produit une bibliothèque de code source fermée ou une API via plusieurs versions au fil des décennies, de petits groupes d'individus ont eu accès à cette source tout au long de sa production. Certains d'entre eux sont des groupes d'audit tiers et des développeurs qui sont passés à d'autres entreprises / gouvernements. Si ce code est suffisamment statique, pour maintenir la compatibilité, comme c'est le cas pour une source fermée, certaines faiblesses peuvent rester inopinées pendant de nombreuses années. Ceux qui ont accès à cette source fermée ont la liberté d'exécuter des outils d'analyse de code pour étudier ces faiblesses, les référentiels de bogues de ces ateliers de développement de logiciels sont pleins de bogues "mineurs" qui pourraient conduire à des exploits. Toutes ces informations sont accessibles à de nombreuses personnes internes.

Les attaquants le savent et veulent ces informations pour eux-mêmes. Cela met une cible géante sur l'infrastructure interne de votre entreprise si vous êtes l'un de ces magasins. Et dans l'état actuel des choses, vos processus de développement deviennent un passif de sécurité. Si votre entreprise est suffisamment grande et que votre base de code est suffisamment bien distribuée, vous pouvez même être la cible d'efforts d'infiltration humaine. À ce stade, la technique de Charlie Miller: soudoyer un développeur avec suffisamment d'argent et il vous écrira un bug indétectable devient une possibilité distincte.

Cela ne signifie pas non plus qu'il n'entre pas dans les produits OSS de la même manière. Cela signifie simplement que vous avez un ensemble de données, puis une fois publié, peut exposer des faiblesses dans votre base d'installation. Le garder privé a créé une dette de codage contre les systèmes installés par vos clients que vous ne pouvez pas rembourser immédiatement.

+1 @Ori: Connaissez-vous un OSS qui avait une porte dérobée qui a été trouvée et clairement conçue pour en être une? En outre, Charlie Miller est qui, ce qui signifie qu'il y a une page wikipedia, ou quelque chose du genre.
C'est un "chercheur en sécurité" qui est célèbre pour ses exploits Pwn2Own. Il mentionne l'élément humain des exploits de codage dans son discours Defcon 2010, qui est suffisamment humoristique pour être regardé seul. http://www.youtube.com/watch?v=8AB3NcCkGNQ
+1 @Ori: Ah, j'ai pensé que vous vouliez peut-être dire un «Charlie Miller» qui avait été acheté, puis découvert. Exploiter les gens n'a rien de nouveau, il pourrait donc être difficile de l'appeler la «technique Charlie Miller». Connaissez-vous un OSS qui avait une porte dérobée qui a été trouvée et clairement conçue pour en être une?
@blunders Rien qui a été identifié et publié comme tel. Je pourrais aller chercher quelques détails, mais le problème avec un «bug» bien conçu est qu'il ne devrait pas être facile de faire la différence entre un accident et un placement délibéré.
@Ori: D'accord, et je me demandais simplement si vous en saviez déjà, pas besoin d'en chercher un. Merci!
Les allégations d'@blunders ont volé dans ce cas, mais me semblent douteuses: [Quel est l'impact potentiel de l'attaque présumée d'OpenBSD IPSEC? - Sécurité informatique] (http://security.stackexchange.com/questions/1166/what-is-the-potential-impact-of-the-alleged-openbsd-ipsec-attack)
@blunders comme @nealmcb l'a mentionné, l '"attaque" présumée d'OpenBSD IPSec, bien que douteuse, était possible sans effort d'imagination, et en fait considérée comme vraie pendant une courte période. De plus, le "rootkit" original se trouvait dans un package open source, et très populaire (http://en.wikipedia.org/wiki/Rootkit#History). Ainsi, les portes dérobées dans OSS sont une possibilité définitive.
@Ori, ce que vous appelez la "technique Charlie Miller" est bien mieux reconnue comme la "technique [Kevin Mitnick] (http://en.wikipedia.org/wiki/Kevin_Mitnick)".
@Ori, votre troisième point - prémisse Open Format - bien qu'un bon point, n'est pas nécessairement un avantage strictement du logiciel F / OSS. En effet, votre dernière affirmation dans ce paragraphe contredit le reste: «Certaines entreprises sautent sur le wagon du groupe« Open Formats »sans sauter dans le train de l'Open Source» », ce qui prouve que ce n'est pas pertinent. (Certes, dans certains esprits, ce n'est pas le cas, mais ce n'est pas vrai.)
@AvID J'ai lu les livres co-écrits par Kevin, recherché ses actions présumées, et entendre Charlie dire (essentiellement) "Voici une pile d'argent, codez-moi une porte dérobée" était une première pour moi. Je suppose que vous pourriez l'appeler le piratage de l'argent, ou quelque chose d'équivalent pour le rendre neutre.
@Avid, la bataille des formats ouverts est menée par à peu près les mêmes personnes, je n'essayais pas de présenter l'argument comme le mien, juste qu'il est souvent présenté comme l'argument open source. Je suis tout à fait d'accord qu'il a été découplé et adopté par les partisans du système fermé et de l'open source.
Bruce Ediger
2012-06-27 22:24:39 UTC
view on stackexchange narkive permalink

Vous voudrez consulter ces articles:

Le résultat est qu'ouvert ou fermé est à peu près équivalent selon la façon beaucoup de tests sont effectués sur eux. Et par "tester", je ne veux pas dire ce que fait votre "testeur" de drone d'entreprise moyen, mais plutôt une expérience sur le terrain.

knocte
2016-04-12 15:59:35 UTC
view on stackexchange narkive permalink

Soyons honnêtes ici, quand quelqu'un prétend que l'open source est plus sûr que le code source fermé, il généralise ce qui se passe aujourd'hui dans les systèmes d'exploitation serveur / bureau, tels que Linux (open source) contre Mac / Windows (propriétaire, source fermée ).

Pourquoi les logiciels malveillants sont-ils plus susceptibles d'affecter ce dernier et non le premier? Pour plusieurs raisons, pour lesquelles je pense que la plus importante est la première (empruntée à cette autre réponse à une question marquée comme duplicata de celle-ci):

  1. Le logiciel installé par l'utilisateur dans le cas d'une distribution Linux (ou d'un autre système d'exploitation open source), est généralement emballé par une organisation centralisée (c'est-à-dire dans le cas d'Ubuntu, il est réalisé par Canonical, et hébergé by it), qui héberge des binaires compilés à partir de sources organisées / surveillées par la communauté open source. Cela signifie que la probabilité que l'utilisateur installe un logiciel infecté, ou la probabilité que la communauté open source accepte des changements de code malveillants, est beaucoup plus faible que dans le cas de Mac / Windows, où l'utilisateur installe généralement des logiciels à partir de nombreux endroits différents sur le Web. , ou de nombreux fournisseurs différents des AppStores. Il y a aussi le risque que les serveurs de l'organisation (par exemple Canonical) soient piratés, mais ce risque est mineur car ces organisations emploient des experts informatiques de premier ordre pour faire fonctionner leurs serveurs.
  2. Linux (ou d'autres systèmes d'exploitation open source) le nombre d'utilisateurs est bien inférieur à celui des utilisateurs Windows / Mac , les créateurs de malwares préfèrent donc ne pas les cibler (car le rapport bénéfice / coût est plus faible dans ce cas).
  3. Linux, étant juste un noyau, est disponible dans différentes distributions parmi lesquelles vous pouvez choisir , donc les créateurs de logiciels malveillants devraient consacrer plus d'efforts pour rendre leur code malveillant compatible avec beaucoup d'entre eux (le rapport avantages / coûts est donc inférieur dans ce cas).
  4. Les sources de Linux (ou d'autres OS Open Source) sont ouvertes à tout le monde pour voir / modifier. Cela signifie que lorsqu'une vulnérabilité de sécurité est trouvée, n'importe qui peut écrire un correctif (il n'y a pas de verrouillage du fournisseur, vous n'êtes pas lié à une organisation spécifique que vous devez attendre pour développer un correctif), donc en théorie, le les correctifs de sécurité se produisent plus tôt que dans les cas de logiciels propriétaires. (Cependant, dans la pratique, il n'y a généralement pas de différence, car les entreprises qui exploitent des plates-formes propriétaires telles que Windows et MacOS, sont de grandes entreprises suffisamment compétentes.)
Geremia
2016-09-13 04:55:43 UTC
view on stackexchange narkive permalink

L'article OpenSource.com de Jim Fruchterman " Votre logiciel de sécurité open source est-il moins sécurisé?" donne une très bonne analogie pour savoir comment l'open source, même si les attaquants savent comment cela fonctionne, rend le logiciel plus sécurisé pour utilisateurs finaux:

Considérez le chiffrement comme une combinaison verrouillée sûre pour vos données. Vous pouvez être le seul à avoir la combinaison ou vous pouvez lui confier la sélection de quelques collaborateurs proches. Le but d'un coffre-fort est d'empêcher les personnes non autorisées d'accéder à son contenu. Il peut s'agir de cambrioleurs qui tentent de voler des informations commerciales précieuses, d'employés essayant d'obtenir des informations salariales confidentielles sur leurs pairs ou d'un fraudeur qui souhaite obtenir des informations confidentielles afin de perpétrer une arnaque. Dans tous les cas, vous voulez que le coffre-fort garde vos affaires en sécurité et empêche les personnes non autorisées d'entrer.

Maintenant, disons que je choisis un coffre-fort pour mes objets de valeur. Dois-je choisir Safe Number One qui a des murs en acier d'un demi-pouce, une porte d'un pouce d'épaisseur, six boulons de verrouillage, et qui est testé par une agence indépendante pour confirmer que le contenu survivra pendant deux heures dans un incendie? Ou dois-je choisir le coffre-fort numéro deux, un coffre-fort auquel le vendeur dit simplement de faire confiance, car les détails de conception du coffre-fort sont un secret commercial? Cela pourrait être Safe Number Two est fait de contreplaqué et de tôle mince. Ou, il se pourrait qu'il soit plus fort que Safe Number One, mais le fait est que je n'en ai aucune idée.

Imaginez que vous ayez les plans détaillés et les spécifications de Safe Number One, suffisants pour créer une copie exacte de ce coffre-fort si vous disposiez des bons matériaux et outils. Cela rend-il Safe Number One moins sûr? Non. La sécurité de Safe Number One repose sur deux protections: la solidité du design et la difficulté de deviner ma combinaison. Avoir les plans détaillés m'aide, ou des experts sûrs, à déterminer la qualité de la conception. Cela aide à établir que le coffre-fort n'a aucun défaut de conception ou une deuxième combinaison de «porte dérobée» autre que ma propre combinaison choisie qui ouvre le coffre-fort. Gardez à l'esprit qu'une bonne conception sûre permet à l'utilisateur de choisir sa propre combinaison au hasard. Connaître la conception ne devrait pas du tout aider un attaquant à deviner la combinaison aléatoire d'un coffre-fort spécifique utilisant cette conception.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...