セキュリティ上重要なコードを再利用または書き直す必要がありますか？
通常、プログラミングでは、アルゴリズムを独自に実装するよりも、コードを再利用する方が常に適切です。実装が長期間存在し、まだ多くのプロジェクトで使用されている場合、それは最初からかなりうまく設計されており、十分なテストとデバッグを受けており、おそらく最も重要な誰かが保守を担当していますこれは、構築している特定のソフトウェア製品に集中するためにより多くの時間を意味します。
ただし、暗号化や認証などのタスクを実行する、または何らかの理由で高い特権で実行されるセキュリティクリティカルなコードについても、この原則が依然として当てはまるかどうか疑問に思いました。アルゴリズムの1つの実装が多くのソフトウェアシステムによって共有されている場合、人々がアルゴリズムを解読する強い動機があり、欠陥が見つかった場合、それは大規模なセキュリティ災害になる可能性があります。 HeartbleedとShellshockは最近思い浮かぶ2つの例です。クローズドソースの例については、アドビから何でも選択してください:)
単一のセキュリティクリティカルなライブラリを共有する多くの異なるソフトウェアにより、このライブラリは、バックドアを挿入したい攻撃者にとって最適なターゲットになります。多くの活動を伴う大規模なオープンソースプロジェクトでは、おとりとして他の多くの修正（コードスタイルのクリーンアップなど）も備えたバックドアコミットには気付かれそうにありません。
これらすべてを念頭に置いて、コードの再利用は、セキュリティが重要なタスクを実行するコードの良い習慣と見なされていますか？もしそうなら、そのアプローチの前述の弱点を緩和するためにどの予防策をとるべきですか？
重要なのはmaintenanceです。既存のコードを再利用したか、独自のコードを作成したかに関係なく、コードを理解し、コンパイラやプラットフォームの進化などに関してコードをフロートに保つことができる誰かがどこかにいる場合にのみ、適切なセキュリティを実現できます。バグのないコードを使用することが最善ですが、実際には次善の策、つまりバグの迅速な修正（特に、vulnerabilities /としても知られる悪意のある使用に利用される可能性のあるバグ）に依存する必要があります）、短い時間枠内。
独自のコードを作成する場合、メンテナンスジョブは自分の肩に大きく依存します。そして、その仕事は非常に時間がかかる可能性があります。たとえば、独自のSSL/TLSライブラリを作成して維持し、本番環境で使用する場合は、暗号化実装のすべての特性、特に サイドチャネル攻撃 に対する耐性を理解する必要があります。公開されている攻撃とその対策に注意する必要があります。あなたがそのためのリソースを時間と能力の両方で持っているなら、それで結構です！しかし、メンテナンスのコストを過小評価してはなりません。既存のライブラリ、特に広く使用されているオープンソースライブラリを再利用すると、メンテナンスが他の人によって行われ、広範な使用により外部からの監視が保証されるため、長期的には非常に安価になります。ボーナスとして、世界の半分がセキュリティホールを共有している場合、外部ライブラリのセキュリティホールについて非難することはできません。
要約すると、問題は実際にはcode再利用についてではなく、保守作業再利用についてです。
（私はあなた自身のコードを書くことの優れた教育学的性質とは無関係にこれらすべてを書きます。私はあなたがあなた自身の実装を行うことをお勧めします-しかし確かに実際にそれらを本番で使用するためではありません。これはlearningのためです。）
なおさら。
セキュリティコードはtrickyです。暗号化コードは実にhardであり、たとえあなたが訓練を受けた暗号学者であっても、そうでなければ正しく理解することは不可能です。
非常に多くの重要なソフトウェアパッケージや企業に非常に多くの重大なバグがある場合、何を考えればよいでしょう*。
*もちろん、これはあなたの専門分野であり、セキュリティ機能が製品のコアである場合を除いて...
興味深い質問です！ベストカレントプラクティスの観点よりも、確率の観点から答えたいと思います。
トーマスや他の人は素晴らしい答えを提供していますが、私は彼らが中心的な質問に触れているとは思いません-それは「一般的なコードよりも実際に回復力があるユニークな（またはあまり使われていない）コードです」 。 「人気のあるコードよりもsecure」を意図的に使用していないことに注意してください。そして、結局のところ、「あいまいな作業を通じてセキュリティを保護する」という特別なケースは何でしょうか。
そして（これは一般的な答えにはならないだろうと思います）「安全」を「弾力性のある」に置き換えると、答えが実際に常に受け入れられるとは限らないと思います。
それはおそらくより少ないsecure（つまり：以前に多くの攻撃を受けていた人気のコードよりも、独自のセキュリティコードが解読するのが簡単/高速である可能性が非常に高いです。あなたより賢い人によって修正されます）。
ただし、大規模で人気のあるサイトでない限り、クラッカーがあなたを解読するために費やしたコードや労力を再利用できなければ、潜在的なクラッカーにとってそれほど興味深い興味がないことにもなります。自明ではありません（つまり、サイトはautomatedパラメータ非検証/ SQLインジェクションプローブで分解されません）。これは特にターゲットを絞った場合（産業スパイなど）は機能しませんが、当時の攻撃の大部分は実際には人気のあるソフトウェアの自動化されたプローブのようです。
したがって、質問が「どちらがより安全であるか」ではなく「クラックされる可能性が低い」である場合、答えは実際には「依存する」である可能性があります。以下にいくつかの例を示します。
例1：現在既知のセキュリティホールがなく、購入したものの更新されていない、Microsoft Windows 8.1（または最近人気のあるもの）のコンピューターがインターネットに接続されているとします。また、インターネットに接続された何百もの既知のセキュリティホールがあり、パッチが適用されていないwinsockを備えた数十年前のWindows 3.11を想像してみてください。どちらも同じ方法で使用されます。アクセスの質を議論する目的で無視します...問題は、どちらがより早く分解されるかです。
3.11の方がはるかに安全性が低いことは明らかですが、それを標的とするエクスプロイトはほとんどありません。したがって、3.11がなんとか実行できる古いアーキテクトをヒットする前に、8.1をヒットするための非常に人気のあるゼロデイエクスプロイトが存在する可能性があります。
例2：現在のエクスプロイトが確認されていない1つのWebサーバーに最新のJoomla CMSがあり、CMS風の処理を行う手作りのPerlスクリプトがあり、エクスプロイト可能なバグがわかっているとします（ただし、どれもありません）。それらのうち、現在利用可能な自動テストに疑わしいもの）。 1年後、それが悪用される可能性が高いのはどれですか。
過去10年間に経験した数十（数百）の事例の事例証拠ではありますが、人気のあるソフトウェアが悪用されたのは大多数のケースでしたが、時代遅れのソフトウェアはそのまま今日まで実行され続けています。
検討する価値のあるもう1つのこと：
- 人気のあるソフトウェアが自動更新を行う場合（または管理者が常に迅速に更新する場合）、そのような人気のあるコードの弱点は大幅に軽減されます（ただし、ゼロデイおよび未公開のエクスプロイトにより排除されるわけではありません）。したがって、大きな利点があります。
- 逆に、ソフトウェアがメンテナンスを受けない場合、人気のないもの（自己作成のような）は実際には問題の疑いが少ないかもしれません
- 非難-多くの場合、人気のあるソフトウェアを使用する方が有利です。世界の半分が影響を受けている場合、あたかも一人のプログラマーであるかのように、ほとんど非難されることはありません。これは、お金を扱う場合には特に重要です。安全性は高いが悪用が発生した場合にコストを負担する必要があるよりも、安全性は低いが責任を移すことができる方が、多くの場合「優れています」。
- 仕事-すでに他の人が言及していますが、人気のあるソフトウェアはほとんどの場合それ自体で修正され、更新する必要があります-実際にバグを見つけて修正するよりもはるかに少ない作業です（ただし、が必要です） メンテナンス）
- 自己記述型ソフトウェアのもう1つの利点は、多くの機能やカスタマイズ性を通常必要としないため、多くの場合、コードの大幅な削減（バグの減少）です。たとえば、人々が必要とするのは、実際には数十行のコードで実行できる単純な「テンプレートニュースサイト」である場合でも、Joomlaを使用します。プログラマーとしては、人気のあるソフトウェアで作業する完成度の高いプログラマーの半分ではない（したがって、コードの1行あたりのバグの数が著しく多い）場合でも、桁違いにあるため、多くの場合、大きなマージンで勝つことができます（または少数！）記述/維持するコードが少ない
簡単な答えは、自分のセキュリティをロールバックしないことです。
これには2つの部分があります。アルゴリズムと実装。
アルゴリズムについては、独自の暗号化アルゴリズムを作成するのは恐ろしいことです。暗号化の分野に精通している場合でも、新しいアルゴリズムを作成する立場にはありません。あなたがそれに取り組んでいるフィールドの専門家のチームがない限り、あなたはあなた自身のアルゴリズムを導入しないでください。この点を理解するために、クラックされた最近のアルゴリズムのいくつかと、それらがどのようにクラックされたかを見てください。額面通りに見えるものには、私が想像もしなかったような弱点があります。
実装に関しては、優れたアルゴリズムの独自の実装を作成することは、独自のアルゴリズムを作成することほど恐ろしいことではありませんが、専門家でない限り、実行しないでください。実装の1つの間違い。コアアルゴリズムがどれほど優れているかは問題ではありません。この場合、あなたが尋ねなければならない質問は、あなたが最高のセキュリティライブラリをまとめるために働いた多くの専門家より優れているかどうかです。
より可能性が高いもの。エラーや弱点なしに独自のアルゴリズムと実装をロールバックできること、または使用するアルゴリズムと実装にバックドアが組み込まれることはありますか？
実装して完全なアルゴリズムを作成できれば、バックドアのリスクは問題になりません。しかし、それは現実的ではありません。
あなたがあなたのマネージャー/株主/電気ショック療法に説明したい問題もあります。業界全体が動いている、信頼できるソフトウェアパッケージの最上位にバックドアが置かれているか、セキュリティを向上させるための個人的な試みがひどく失敗したこと。私は個人的には、業界全体の専門家が行った選択をしたことを説明したいと思います。失敗した唯一の理由は、多国籍企業でさえ影響を与えているいくつかの大きなレベルの問題でした。
とはいえ、制作の光を決して見ない限り、自分でやろうとすることは良い学習経験であるとトーマスに同意します。
コードがわずかに異なる命令にコンパイルされる場合、セキュリティは必ずしも改善されません。セキュリティは：
- アルゴリズム
- 実装
- 監査
- メンテナンス
より良い、より安全なアルゴリズム（何年もの調査が必要になる可能性があります）を作成しておらず、コードを監査せず、それに応じてパッチを適用していない場合、わずかに異なる実装で安全を確保することはほとんどありません。
Heartbleed、Shellshock、BEAST、POODLE、およびその他の最後のいくつかの主要なSSL/TLS問題は、CRCと自己参照アルゴリズム自体に固有の問題、および経験豊富なコード監査の欠如が原因で発生しましたnot実装による。
それらがどのように失敗したのか本当に理解していない場合、あなたは間違いなくが独自のセキュリティコードを書くべきではありません。解決するよりも多くの問題を追加します。