L'important est la maintenance . Que vous ayez réutilisé le code existant ou écrit le vôtre, vous n'obtiendrez une sécurité décente que s'il y a quelqu'un, quelque part, qui comprend le code et est capable de le maintenir à flot en ce qui concerne, par exemple, l'évolution des compilateurs et des plates-formes. Avoir du code sans bogues est préférable, mais en pratique, vous devez vous fier à la prochaine meilleure chose, à savoir la correction rapide des bogues (en particulier les bogues qui peuvent être exploités pour une utilisation malveillante, également appelés vulnérabilités ), dans peu de temps.

Si vous écrivez votre propre code, alors le travail de maintenance repose carrément sur vos propres épaules. Et ce travail peut prendre beaucoup de temps. Par exemple, si vous décidez d'écrire et de maintenir votre propre bibliothèque SSL / TLS, et de l'utiliser en production, vous devez comprendre toutes les particularités de la mise en œuvre cryptographique, en particulier la résistance aux attaques de canaux secondaires, et vous devez garder un œil sur les attaques et contre-mesures publiées. Si vous avez les ressources pour cela, à la fois en temps et en compétence, alors très bien! Mais le coût de la maintenance ne doit pas être sous-estimé. La réutilisation d'une bibliothèque existante, en particulier une bibliothèque open source largement utilisée, peut être bien moins coûteuse à long terme, car la maintenance est effectuée par d'autres personnes et une utilisation généralisée garantit un examen externe. En prime, vous ne pouvez pas être blâmé pour les failles de sécurité dans une bibliothèque externe si la moitié du monde les partage.

Pour résumer, la question ne concerne pas vraiment la réutilisation du code , mais sur effort de maintenance réutilisation.

(J'écris tout cela indépendamment des grandes qualités pédagogiques de l'écriture de votre propre code. Je vous encourage à faire vos propres implémentations - mais certainement pas pour les utiliser en production. Ceci est pour apprentissage .)

Encore plus.

Le code de sécurité est délicat . Le code de cryptographie est carrément difficile , même si vous êtes un cryptographe qualifié - et impossible à obtenir correctement, si vous ne l'êtes pas.

S'il y a tant de bogues critiques dans tant de grands progiciels et entreprises importants - qu'est-ce qui vous fait penser * que vous seriez en mesure de faire un meilleur travail?

_{* À moins bien sûr que ce ne soit votre domaine d'expertise spécifique et que la fonctionnalité de sécurité soit au cœur de votre produit ...}

Question intéressante! J'aimerais y répondre davantage du point de vue des probabilités que du point de vue des meilleures pratiques actuelles.

Bien que Thomas et d'autres fournissent d'excellentes réponses, je ne pense pas qu'ils touchent à la question fondamentale - qui est "est unique (ou moins utilisé) code plus résilient en pratique que le code populaire ". Notez que je n'ai délibérément pas utilisé "plus sécurisé que le code populaire". Et en quoi cela se résume-t-il à un cas particulier de «la sécurité par l'obscurité fonctionne-t-elle»?

Et (et je sais que ce ne sera pas une réponse populaire) je pense que lorsque nous remplaçons «sécurisé» par «résilient», la réponse ne sera peut-être pas toujours généralement acceptée «jamais!»

Il est clair qu'il est probablement moins sécurisé (ce qui signifie: il est très probable que votre propre code de sécurité soit plus facile / plus rapide à déchiffrer que le code populaire qui avait déjà subi de nombreuses attaques et corrigé par des personnes plus intelligentes que vous).

Cependant, à moins que vous ne soyez un site grand / populaire, il est également clair que vous êtes beaucoup moins intéressant pour les crackers potentiels s'ils ne peuvent pas réutiliser le code / l'effort dépensé pour vous cracker, et cet effort n'est pas anodin (ce qui signifie que votre site ne tombera pas en panne aux sondes de non-validation / d'injection SQL de paramètres automatisés ). Cela ne fonctionne évidemment pas si vous êtes ciblé spécifiquement (espionnage industriel, etc.), mais la grande majorité des attaques de cette époque semblent en fait être des sondes automatisées pour des logiciels populaires.

Donc, si la question n'est pas "qui est plus sûr", mais "qui est moins susceptible d'être fissuré", la réponse pourrait en fait être "cela dépend". Voici quelques exemples:

Exemple 1: Imaginez un ordinateur Microsoft Windows 8.1 (ou tout ce qui est populaire de nos jours), avec actuellement aucune faille de sécurité connue, acheté mais jamais mis à jour, connecté à Internet. Imaginez également Windows 3.11 vieux de plusieurs décennies avec winsock, jamais corrigé, avec des centaines de failles de sécurité connues, connecté à Internet. Les deux sont utilisés de la même manière. Ignorer aux fins de discussion la qualité de l'accès ... La question est de savoir, qui sera brisé plus tôt?

S'il est évident que 3.11 est beaucoup moins sécurisé, il n'y a guère d'exploits à l'état sauvage le ciblant . Il se pourrait donc qu'il y ait un exploit de 0 jour massivement populaire pour 8.1, avant que 3.11 ne frappe un exploit archaïque qui parvient à s'exécuter dessus.

Exemple 2: Imaginez que vous ayez le dernier CMS Joomla sur un serveur Web sans exploits actuels connus, et un script perl fait à la main faisant des choses CMS-ish, avec des bogues exploitables connus (mais aucun d'entre eux n'est suspect pour les tests automatisés actuellement disponibles). Après un an, quelles sont les plus grandes chances qu'il soit exploité?

Bien que des preuves anecdotiques, dans quelques dizaines (à des centaines) de cas que j'ai eues au cours des dernières décennies, c'était dans la grande majorité des cas aussi populaire le logiciel a été exploité, alors que les logiciels obsolètes continuent de fonctionner jusqu'à ce jour sans être dérangés.

Autre chose à considérer:

• si un logiciel populaire effectue une mise à jour automatique (ou si les administrateurs le mettent TOUJOURS à jour rapidement), alors les faiblesses d'un tel code populaire sont beaucoup réduites (mais pas éliminées, en raison d'exploits de 0 jour et non publiés) et présentent donc un grand avantage
• à l'inverse, si le logiciel ne reçoit aucune maintenance, non populaire (comme l'auto-écriture) peut en fait être moins suspecte de problèmes
• blâme - il peut souvent être avantageux d'utiliser des logiciels populaires. Si la moitié du monde est touchée, vous ne serez pas autant blâmé que si vous étiez un programmeur unique. Ceci est particulièrement important si vous travaillez avec de l'argent. Il est souvent «préférable» d’être moins sûr, mais de pouvoir rejeter la responsabilité, que d’être plus sûr, mais de devoir assumer le coût vous-même lorsque l’exploit se produit.
• travail - déjà mentionné par d’autres, populaire le logiciel se corrigera dans la grande majorité des cas, il vous suffit de mettre à jour - ce qui est beaucoup moins de travail que de trouver et de corriger les bogues vous-même (mais nécessite encore une maintenance)
• un autre L'avantage des logiciels auto-écrits est souvent la réduction de masse du code (ce qui entraîne moins de bogues), car vous n'avez généralement pas besoin de la plupart des fonctionnalités ou de la personnalisation. Par exemple, les gens utiliseront Joomla même si tout ce dont ils ont besoin est un simple "modèle de site de nouvelles" qui pourrait en pratique être réalisé avec quelques dizaines de lignes de code. Même si vous, en tant que programmeur, n'êtes pas deux fois moins performant que ceux qui travaillent sur un logiciel populaire (vous avez donc un nombre de bogues sensiblement plus élevé par ligne de code), vous pouvez souvent gagner avec une grande marge en raison de l'ordre de grandeur ( ou peu!) moins de code à écrire / maintenir

La réponse simple est: ne lancez pas votre propre sécurité.

Il y a deux parties à cela. Algorithme et implémentation.

En ce qui concerne l'algorithme, créer votre propre algorithme de chiffrement est horrible. Même si vous êtes versé dans le domaine de la cryptographie, vous n'êtes toujours pas en mesure de créer un nouvel algorithme. À moins qu'une équipe d'experts dans le domaine ne travaille dessus, vous ne lancez pas votre propre algorithme. Pour comprendre ce point, regardez certains des algorithmes récents qui ont été fissurés et comment ils l'ont été. Ce qui a l'air génial à première vue a des faiblesses que je n'aurais jamais imaginées.

En ce qui concerne l'implémentation, créer sa propre implémentation d'un bon algorithme n'est pas aussi horrible que créer son propre algorithme, mais à moins d'être un professionnel, ne le faites pas. Une erreur de mise en œuvre et peu importe la qualité de l'algorithme de base. Dans ce cas, la question que vous devez vous poser est de savoir si vous êtes meilleur que les nombreux experts qui ont travaillé à mettre en place une bibliothèque de sécurité haut de gamme.

Ce qui est plus probable. Que vous pouvez rouler votre propre algorithme et implémentation sans aucune erreur ou faiblesse ou que l'algorithme et l'implémentation que vous utilisez auront une porte dérobée?

Si vous pouviez créer un algorithme parfait avec implémentation, le risque de la porte dérobée ne serait pas un problème. Mais ce n'est pas réaliste.

Il y a aussi la question que vous souhaitez expliquer à votre manager / actionnaires / ect.? Qu'il y avait une porte dérobée dans un progiciel de confiance haut de gamme qui fait tourner toute l'industrie ou que votre tentative personnelle d'améliorer la sécurité a terriblement échoué. Personnellement, je préférerais beaucoup expliquer que j'ai fait le choix que les professionnels de l'industrie ont fait et que la seule raison pour laquelle cela a échoué était un problème de niveau énorme qui affecte même les entreprises multinationales.

Cela dit, je suis d'accord avec Thomas pour dire qu'essayer de le faire soi-même est une bonne expérience d'apprentissage tant que cela ne voit jamais la lumière de la production.

La sécurité n'est pas nécessairement améliorée simplement si le code se compile selon des instructions légèrement différentes. La sécurité est:

1. Algorithme
2. Mise en œuvre
3. Audit
4. Maintenance

Si vous n'écrivez pas de meilleurs algorithmes plus sécurisés - ce qui peut prendre des années de recherche - et vous ne faites pas auditer votre code et ne le corrigez pas en conséquence, alors il est très peu probable qu'une implémentation légèrement différente vous sécurise. p> Heartbleed, Shellshock, BEAST, POODLE et d'autres derniers problèmes majeurs de SSL / TLS sont survenus en raison de problèmes inhérents au CRC et aux algorithmes autoréférentiels eux-mêmes, et au manque d'audits de code expérimentés, pas dus à l'implémentation.

Si vous ne comprenez pas vraiment comment ils ont échoué, vous ne devriez certainement pas écrire votre propre code de sécurité. Vous allez ajouter plus de problèmes que vous n'en résoudrez.