je signe mon -1 sur ton commentaire sans intérêt.Envoyé par Nagato Yuki
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
je signe mon -1 sur ton commentaire sans intérêt.
Limite ceux que j'ai reçus, avant d'apprendre l'existence de ceux ci par le fait d'avoir des points négatif dans le profil, je m'en fou un peu mais je vois avec stupeur que les autres commentaires étant eux pas vraiment en faveur sont largement noté négativement pourtant ils abordent le sujet de manière neutre.
Si tu trouves mon analogie douteuse, moi pas, un coffre, ça à beau être fortifié ou quoi que ce soit, ça peut toujours s'ouvrir, il en va de même pour un code closed source, la source est protégée mais l'objet en question peut se désassembler, néanmoins, ça reste une protection minimal si on ne laisse pas le «code» dessus.
Quand on ne veut pas laisser l'objet open source c'est parce qu'on a pas vraiment envie que n'importe qui mette le nez dedans si quelqu'un veut l'améliorer qu'il se propose pour le faire mais lorsqu'il s'agit de sécurité il est hors de question de laisser un simple développeur qui sait juste utiliser une bibliothèque. Il y a aucun problème à laisser le code source d'un service pour des utilisateur normaux excepté lorsque l'ouverture de ce code source peut provoquer des expériences désagréables auprès des utilisateurs :
-Un navigateur Web, ok, ça aura besoins de diverses modifications et améliorations (par exemple le blocage réel des popup qui n'a pas l'air d'être encore intégré à Chrome et qui a disparu d'Opera).
-Un MMO ou juste un jeu en ligne, c'est hors de question, si il fini open source, le ratio des gens cherchant à cheater est tellement grand que ça va finir en une destruction du plaisir de jeu des autres joueurs qui ne cheatent pas.
-Un système de sécurité, SSL/TLS etc... enjoy, de toute manière, que ce soit open ou pas, j'y crois pas vraiment à la sécurité qu'offre cette chose, pourquoi un autre ordinateur pourrait moins décoder les informations que le serveur cible le puisse ?
Lorsque c'est pour l'entreprise ou pire un hopital, il vaut mieux éviter, ça limitera les petites attaques après pour les grosses il vaut mieux avoir un opérateur qui soit présent en permanence ne serait-ce que pour désactiver tout le système de transite des données en cas de problème. Les machines séparés doivent être autonomes en cas de coupure du flux.
Enfin bref, l'open source, oui et non, il faut pas l'utiliser pour n'importe quoi mais ceci a déjà été dit ce pourquoi j'ai rien ajouté.
LOL. Différencie intérêt et bien fondé du message. Bref, je vais pas me rabaisser à ton niveau, c'est pas parce que je ne poste pas activement que je vais réagir comme tu le souhaite initialement. (Par ailleurs, tu sembles vouloir me donner une leçon, apprends déjà à appuyer sur Shift quand tu commences une phrase et pas la peine de me répondre sur ma grammaire et ma conjugaison horrible, je suis déjà au courant :b).
Il manque la fin de ta phrase. Je suppose que tu voulais dire "il est hors de question de laisser un simple développeur qui sait juste utiliser une bibliothèque participer au code" ?
Si oui, il serait peut être bien de regarder comment fonctionne l'open source
Pourtant les navigateurs web sont quand même un des points assez sensibles du point de vue de la sécurité.
Déjà, combien parmi les joueurs de MMO savent comment trouver des failles etc. ?
Ensuite, je ne vois pas en quoi laisser le code source visible de tous pourrait ouvrir la voie à la triche.Est-ce que tu aurais un exemple concret pour appuyer tes dire ?
Il est tellement plus simple et plus rapide d’arnaquer les autres joueurs... pourquoi s'embêter à rechercher des failles ?
Est-ce que tu sais au moins comment cela fonctionne ?
Ça s'appliquait aussi au closed pour laisser un dev' qui sait juste utiliser une bibliothèque, je pense que cette connaissance n'est pas suffisante dans ce domaine, il faut aussi savoir comment les bon et mauvais utilisateurs se comportent.
J'avoue que niveau open source, je n'ai pas vraiment d'expérience, j'ai jamais participé à de quelconques projet de ce genre...
Je suis d'accord sur la sensibilité de la sécurité des nav' web mais est-ce que open source implique que tous les composant utilisés doivent être open source ?
Si c'est le cas, ça risque d'être un peu problématique.
Des exemple concret, sur des MMOs pas tellement, j'en connait pas des masse qui sont open source, pour la plupart ils utilisent HackShield qui met 500 ans à détecter CE, qui ne détecte pas Ruby etc... Mais niveau jeu, lorsque c'est open, ou facilement modifiable, on peut être très facilement tenté par le cheat, une fois j'ai joué à un jeu qui sauvegardait en claire, mais genre "Vie=5" donc forcément à un moment, je me suis amusé à modifier ces valeurs pour voir ce que le jeu contenant. (Il y avait de belles armes xD)
Sinon, des failles dans certains MMO c'est ceux qui laissent le client tout faire du genre Dofus, tu change deux fichier et hop t'es over cheaté, imagines si le code était visible de tous... Alors vie perdue... =0 \\o//
Enfin, pour résumer, c'est pas tant les failles qui sont à trouver mais des manières de cheat, lorsque c'est open, il suffit de modifier le code et de recompiler, il y aura beau avoir n'importe quel système de vérification, vu qu'on peut savoir comment ils agissent on peut les contourner. A ce niveau il y a les jeux RMXP qui intègre les interactions en ligne et la fameuse clef de voute, ça a fait chié pas mal de joueurs d'un jeu dont je ne cite pas le nom et en plus, ça a surchargé le serveur à cause d'intégration d'automates x)
(Après, le serveur était codé n'importe comment donc forcément ça a pas bien fonctionné).
Pour SSL, j'ai pas une connaissance accrue de la chose en effet. Niveau sécurité le problème réside entre avant l'utilisation et après, mais ce qu'il y a entre, aucune interception de données n'est impossible, les modifications c'est autre chose mais ce n'est pas trop un problème.
Merci des petites remises en question que tu me proposes dans ton message :b Je n'y pense pas forcément xD
Rien n'empêche dans un projet open source d'utiliser des bibliothèques non-open source.
Attention, le manque de sécurité n'est pas dû à l'open source.
Dans le cas d'un jeu en ligne, on ne fera pas confiance à l'utilisateur et on sauvegardera les données sur le serveur.
Dans le cas d'un jeu hors ligne, que le joueur triche ou pas... au final ça ne regarde que lui.
Encore une fois, cela n'a rien à voir avec l'open source. Faire confiance au client est l'une des plus grosses erreurs qu'on peut faire. Le problème n'est pas que le code soit open source, le problème c'est de faire confiance au client.
On peut savoir les vérifications qui sont faites mais pas les paramètres utilisés. Ensuite, théoriquement, la seule triche qu'on pourrait faire, c'est la création de bots. Et cela que ce soit open ou closed source, il n'y a pas une si grande différence. En closed source, on se rend bien vite compte des conditions utilisées pour repérer les bots.
Après, la lutte contre les bots est un sujet très vaste.
Si je devais installer un système de sécurité pour ma maison, je n'irai pas publier les plans sur Facebook, ça tombe sous le sens.
Comme dit précédemment, il y a une question d'échelle qui est importante. Un système populaire bien surveillé et maintenu (disposant par exemple d'une forte communauté) sera plus à même d'être mis en Open Source qu'un système à dimension plus restreinte ayant des ressources humaines limitées pour la surveillance et la maintenance.
Même s'il est vrai qu'idéalement la sécurité ne devrait reposer que sur sa robustesse "mathématique" et non pas par un masquage de l'information, d'une part un système parfait n'existe pas et n'existera probablement jamais, et d'autre part, à partir d'une certaine taille, même modeste, il est très difficile de prouver rigoureusement (et pas seulement tester) la fiabilité d'un système.
Donc je pense qu'une approche mixte, un système globalement fermé (car à usage restreint) reposant sur des composantes Open Source (car ces composantes sont diffusées à large échelle) est tout à fait pertinent.
Aucun rapport. Des geeks peuvent faire des logiciels propriétaires sur leur temps libre, et des sociétés solides peuvent faire du logiciel libre.
C'est là où ton raisonnement est hors des réalités.
Avant les procédés cryptographiques étaient basés sur le masquage le masquage des informations concernant l'algorithme. Comment il fonctionne etc ...
Aujourd'hui, les algorithmes sont publics et le masquage d'information ne concerne que la clef et uniquement la clef.
Ce procédé est beaucoup plus facile à protéger, tout simplement parce que si une clef est trouvée par hasard ou bien volée, elle ne remet pas en cause la totalité du système et plus aucune communication ne pouvait être considérée comme sure.
Ensuite, on ne prétend pas prouver mathématiquement qu'un système est inviolable. On constate qu'il est inviolable parce que personne n'arrive à le violer. Comme RSA.
Pour que la confiance s'installe il est nécessaire que toutes les données liées à l'algorithme (à l'exception des clefs qui sont générées pour chaque utilisateur) soient publiques afin que n'importe qui puisse tenter de casser le système. Et c'est ça qui crée la confiance.
En d'autres termes, personne ne prouve mathématiquement que le système est inviolable, mais tant que le système n'est pas craqué, il est considéré comme inviolable.
Ainsi les systèmes de chiffrements modernes ont une durée de vie, les longueurs de clefs sont réévaluées régulièrement.
Maintenant au niveau des logiciels, qu'ils soient ouvert ou fermés on s'en balance, tout dépends :
1/ de l'implémentation des algorithmes dans les librairies utilisées, et vu le fonctionnement de la sécurité moderne les grandes librairies opensources (openssl, bouncycastle pour java, ...) ont toutes les chances d'être de grande qualité.
2/ de l'utilisation de ces fonctions de sécurité dans le programme. Faire un import de la librairie ne suffit pas à sécuriser, encore faut-il utiliser les fonctions aux bons endroits. Là encore, que ce soit opensource ou fermé si les devs se plantent ou n'ont pas le temps d'écrire correctement le code nécessaire à la sécurité ben ça sera pas sécurisé.
Et là encore, un code source ouvert et un meilleur gage de sécurité puisqu'il est possible de checker que c'est fait correctement.
Et oui ça permet aussi de checker que ce n'est pas fait correctement et donc de trouver des failles mais c'est vraiment prendre le problème par le mauvais bout et sans tenir compte du tableau général.
Au final, avec un soft proprio tu peux ... rien vérifier. T'es obligé de croire sur parole l'éditeur. Avec un soft ouvert tu peux vérifier ... si t'en as les moyens
Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.
"Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
Kenneth E. Boulding
"Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
Jean-Baptiste Say, Traité d'économie politique, 1803.
"/home/earth is 102% full ... please delete anyone you can."
Inconnu
Pour ou contre ?
bah ! toujours ce vieux débat sur les systèmes sécurisés (ou de logiciel incluant une implémentation de sécurité)...
Premièrement: Le titre de l'article n'a rien à voir avec le contenu où est relaté une banale histoire de "pompage" de logiciel (sécure ou pas).
Pour répondre à la question apportée par le titre, un système logiciel de sécurité se DOIT d'être open source, en offrant la transparence du code source, tout à chacun (Particulier, Etats, partis politique) peut analyser (ou faire analyser) le code COMPLET pour se garantir qu'aucune "backdoor" n'est ouverte pour compromettre leur système confidentiel. Pour ce qui est de la résistance aux attaques, on vous l'a déjà dit et répété: ce point est complètement décorrellé du système dans son ensemble. Pour faire bref, un bon algorithme de chiffrement correctement implémenté dans le code source du système complet est inviolable, tout le reste n'est que méconnaissance, spéculations ou "buzz"
Alors le juge qui décide "que publier les codes de Sophia donneraient les moyens au pirate de déjouer le système de sécurité." ne sait pas de quoi il parle ou alors connait très bien le système qu'il a évalué en tant que "passoire"... Il faut juste savoir que la sécurité est basée sur un système d'authentification et que si le système global ne contient pas de "bypass", "backdoor" ou autre tare, un système basé sur une paire de clé de 512 bits ou plus avec un chiffrement de type "courbes elliptiques" est à ce jour inviolable par un "hacker" aussi balèze soit t'il
Le problème le plus fréquent est un mauvais codage de l'appli générale qui permet le shunt de la partie authentification, c'est un problème de développement de code d'une application et non pas un problème de sécurité propre à une solution de chiffrement.
Voila pour le ch'ti coup de gueule pour une nouvelle qui n'en est pas
Bon code à tous !
Principe de Kerckhoffs
Ca fait longtemps qu'il est établit que la robustesse d'un système cryptographique ne doit reposer que sur sa clef.
Tout le reste n'est que conjecture.. un jour où l'autre on perce le secret de son algorithme mal audité et on fait des découvertes.......
Un peu de lecture:
http://fr.wikipedia.org/wiki/Principe_de_Kerckhoffs
Aucun papier scientifique sérieux n'a prouvé qu'un système fermé était plus sûr.Le principe de Kerckhoffs a été énoncé par Auguste Kerckhoffs à la fin du XIXe siècle dans un article en deux parties "La cryptographie militaire" du Journal des sciences militaires (vol. IX, pp. 5–38, Janvier 1883, pp. 161–191, Février 1883). Ce principe exprime que la sécurité d'un cryptosystème ne doit reposer que sur le secret de la clef. Autrement dit, tous les autres paramètres doivent être supposés publiquement connus. Il a été reformulé, peut-être indépendamment, par Claude Shannon : « l'adversaire connaît le système ». Cette formulation est connue sous le nom de la maxime de Shannon. Il est considéré aujourd'hui comme un principe fondamental par les cryptologues, et s'oppose à la sécurité par l'obscurité.
Le principe de Kerckhoffs n'implique pas que le système de chiffrement soit public, mais seulement que sa sécurité ne repose pas sur le secret de celui-ci. Une tendance plus récente est de considérer que quand les systèmes de chiffrement sont publics, largement étudiés et qu'aucune attaque significative n'est connue, ils sont d'autant plus sûrs.
Obfuscation piège à con, code publié sécurité éprouvée.Qu'en pensez-vous ?
Le code assembleur n'est pas une obfuscation...
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
J'ai pas dit ça (enfin même si c'est pas de l'obfuscation, le problème reste entier). Ce que je dit, c'est que pour faire du code propriétaire de sécurité, il faut faire de l'obfuscation, sinon on risque le reverse engineering. Qui dit reverse engineering dit code connu, donc égalité avec l'open-source. La différence, c'est qu'à ce stade, l'open-source est éprouvé puisque déjà connu, alors que le propriétaire contiendra fatalement des failles, qui du coup sont des 0 day, alors que les failles de l'open-source sont déjà connues et colmatées.
Seulement ça c'est la théorie, parce que dans la pratique il y a deux problèmes pour le propriétaire obfusqué (ou l'assembleur):
-Le code est quand même déplombable (pour peu qu'on y mette les moyens)
-En cas de fuite interne, dans tous les cas, c'est foutu.
Moralité:
-propriétaire (obfusqué, c'est quand même mieux) = faux sentiment de sécurité
-open-source = faux sentiment d'insécurité
Ça me fait bien marrer de lire sur ce forum des soit-disant développeurs (j'ose espérer qu'ils ne s'auto-proclament pas experts en sécurité), qui disent que l'open-source est logiquement moins sécurisé puisque le code est connu. Ou que plus un code est attaqué, moins il est sécurisé (encore une fois, c'est paradoxalement une fausse évidence, puisqu'il est au contraire plus éprouvé).
Comme l'a fait si justement remarquer __l__:
(principe de Kerckhoffs 1883)
Jvachez nous l'avait pourtant bien dit !
"Sur Internet devinez ce que j'ai trouvé : des sources de Linux libres de droit !!!! Autrement dit n'importe quel pirate voit les failles de Linux et peux les exploiter ! "
En même temps la dernière faille de sécurité sérieuse de linux a fait mal et sur une vrai c... en plus.
D'un autre côté un code propriétaire ça signifie peut-être des backdoor intégrés volontairement.
Je n'ai pas d'avis réel sur la question mais on pourrait couper la pomme en deux.
Une solution serait de donner un délai de publication pour le code source. Par exemple une publication au bout d'un an.
Ce serait même un gain en terme de sécurité, les sociétés sachant que le code sera publié assez vite auront intérêt à travailler en continu à son amélioration.
Ensuite libre à elle de sortir une nouvelle version tous les ans, et libre à leurs clients de les acheter ou pas...
De toutes les façons la plupart du temps les failles exploitées sont plus du à l'humain qu'au logiciel, quand on pense que Sony c'est fait pirater 17 fois en un an sur des injections SQL connus depuis des années...
L'ajout de nouvelles fonctionnalités n'est pas la même chose que la maintenance hein !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager