何かが「あいまいさによるセキュリティ」としてカウントされるのはどの時点ですか？
だから、私は「あいまいさによるセキュリティはまったくセキュリティではない」という従来の知恵を見つけ続けますが、何かが「良いセキュリティ」であり、何かが「ちょうど」であるときを正確に伝えることができないという（おそらく愚かな）問題を抱えていますあいまい」。
私はこれに正接する他の質問をチェックしましたが、正確な違いを理解することができませんでした。
例：誰かが非標準ポートでSSHを使用すると、あいまいさによるセキュリティとしてカウントされると述べました。あなたは他の人がそれをチェックしないことを期待しているだけです。ただし、SSHが行うことはすべて、情報を不明瞭にすることです。これは、攻撃者が正しい暗号化キーを推測することを望まないという期待に依存しています。
今、私は最初の状況（特定のサービスの非標準ポートをチェックしようと考える）が2番目の状況（誰かが暗号化キーをランダムに推測する）よりはるかに可能性が高いことを知っていますが、実際には全体の違いですか？
そして、もしそうなら、私（infosec n00b、それがまだ十分に明確でない場合）はどのようにして良い（つまり何を実装する価値がある）と悪い（そうでないか）を区別できると思われますか？
明らかに、脆弱であることが証明されている暗号化スキームは使用しないでください。そのため、他の暗号化スキームよりも明確な場合がありますが、私が苦労しているのは、従来の知識がどこにあり、どこに当てはまらないかを知る方法です。
なぜなら、最初は完全にはっきりしているからですが、実際に、アイデアを審査するためのハードで高速で一貫して適用可能なアルゴリズムを推定しようとすると、問題が発生します。
あなたが持っているという誤解は、あいまいさによるセキュリティは悪いということです。実際にはそうではありません。あいまいさによるセキュリティonlyはひどいです。
このようにしてください。あなたが制御するキーシークレットコンポーネントとは別に、誰かがシステムの完全な動作を知っている場合は、システムを完全に安全にする必要があります。暗号化はこれの完璧な例です。 ROT13暗号のようなものを使用して「アルゴリズムが表示されない」ことを当てにしている場合、それは恐ろしいことです。反対に、使用されているアルゴリズムを正確に確認できても、実際には何もできない場合は、理想的なセキュリティ状況を確認できます。
理解すべきことは、不明瞭さを当てにしたくないということですが、確かに害はありません。 SSH接続でパスワードを保護/キーを使用する必要がありますか？もちろんです。接続を安全に保つには、サーバーを22からポート2222に変更する必要がありますか？絶対違う。パスワードも使用しながら、SSHサーバーをポート2222に変更するのは悪いことですか？いいえ、どちらかと言えばこれが最善の解決策です。ポートを変更する（「隠す」）と、通常のポートを検索する自動エクスプロイトスキャナーのヒープが削減されます。私たちは、あいまいさによってセキュリティの利点を得ていますが、あいまいさをカウントしていません。見つかった場合でも、パスワードを解読する必要があります。
TL; DR-あいまいさだけに頼るのは悪いことです。特に制御可能な秘密情報（パスワードなど）を除いて、システムが完全に機能していることを攻撃者に知らせて、システムを安全にしたいとします。しかし、それ自体が不明瞭であることは悪くはなく、実際には良いことです。
編集：確率の質問に正確に答えるために、はい、そのように見ることができますが、違いを理解してください。ポートの範囲は1〜65535で、nmapなどのスキャナーで1分以内にすばやくチェックできます。すべてのASCII文字の10桁のパスワードをランダムに「推測」すると、1/1.8446744e + 19となり、1秒あたり100,000個のパスワードを推測するのに580万年かかります。
編集2：以下のコメントに対処します。鍵は、完全にランダムと見なされるのに十分なエントロピーで生成できます（ http://tools.ietf.org/html/rfc4086 ）。そうでない場合、それは哲学ではなく実装の欠陥です。あなたはすべてが情報（パスワード）を知らない攻撃者に依存しており、あいまいさの辞書定義は「未知の状態」であると言うのは正しいので、すべてを正しく言うことができますは、あいまいさのレベルに頼っています。
もう一度言いますが、制御できる情報が未知のままであることを考えると、実用的なセキュリティに価値があります。パスワードや証明書などの鍵は、（比較的）シークレットを維持するのが簡単です。アルゴリズムやその他のチェックしやすい方法は、秘密にしておくことは困難です。 「それは価値があるのか」ということは、何を知らないままにしておくことが可能かを決定し、その未知の情報に基づいて妥協の可能性を判断することに帰着します。
秘密を秘密にするのは難しい。秘密が大きいほど、それを知っている人が増えるほど、漏えいする可能性が高くなります。
良い秘密は：
- 小さい。
- 一人だけ知っている。
- 簡単に変更できます。
私たちが誰かを非難するときあいまいさによるセキュリティ私たちが実際に言っていることそれらの秘密はより小さく、より少ない人々に知られている、および/または変更が容易である可能性があります。
アルゴリズム、ポート番号、共有パスワードはすべて、上記の2番目と3番目のポイントに失敗します。アルゴリズムも最初のポイントに失敗します。
何かが適切なシークレットである場合とobscureの違いは、変更が容易で、より少ない人々に知られている、より小さなシークレットで同じレベルのセキュリティを実現する方法を知っているかどうかです。
追加のあいまいさが害を与えることは決してないという主張には同意しません。
SSHポート番号の場合、SSHを使用するたびに-p 1234を入力するために少し時間が必要です。これはほんの1〜2秒ですが、SSHを使用する回数が多いと、これは重要なことになります。このクライアントは少し異なることを覚えて、新入社員に同じことを教えるというオーバーヘッドがあります。このクライアントが奇妙なポート上にあることを忘れて、接続できない理由を理解しようとするファイアウォール設定と稼働時間モニターを見て数分を無駄にする場合があります。
ポート番号はポートスキャンで簡単に検出できるため、IPSを実装してポートスキャンを検出し、チェック時に正しいポートが応答しないようにするか、ポートなどを実装する必要があります。 -knocking。これらの方法はどちらも克服でき、moreあいまいさ以上のものを追加することはできませんが、攻撃者と猫とマウスをプレイするのに時間がかかります。
Rootログインとパスワードをオフにし、キーに切り替えるのに費やした時間と同じ時間が、セキュリティにより良い影響を与えます。詳細の不明瞭化に時間を費やすことで、実際のセキュリティ対策が取り除かれます。
秘密のアルゴリズムの場合、アルゴリズムは多くのセキュリティ研究者が提供できる追加の精査を見逃します。アルゴリズムの不明瞭さ（または秘密性）が原因で、アルゴリズムの安全性が低下している可能性があります。
obscurityによるセキュリティは、攻撃者に知られていないと望む何らかの事実に依存する場所です。これに関する主な問題は、いったん事実が開示されると、セキュリティスキームが役に立たなくなることです。
ただし、SSHが行うことはすべて、情報を不明瞭にすることです。これは、攻撃者が正しい暗号化キーを推測することを望まないという期待に依存しています。
「Security by obscurity」という語句が議論されている場合、それはしばしばprocessesを指し、むしろ秘密情報より。 SSHの重要な点は、プロセスとして、秘密にしておく必要があるのは暗号化キーだけであることを確認するために厳しく検査されていることです。暗号化キーが存在する空間はvastであるため、これは原則として攻撃者が「考えて推測」することは不可能です。
Bruce Schneierは、256ビットのAESキーをブルートフォースするためには、最低限必要な 太陽のエネルギー全体を取り込む） 32年間の出力 （！）コンピュータの速度は関係ありません。これは、使用するコンピューターに関係なく保持される情報理論上の結果です（量子コンピューティングにもかかわらず）。
これは、現在の技術ではまったく実用的ではありません。 SSHがAESを使用していると言っているわけではありませんが、SSHは優れた暗号化の原則の1つです。
たとえば、ソフトウェアの一部でバグが発見され、（信頼できる）ユーザーが特定の入力を見つけて、認証のバイパスが許可される場合があります。かわいそうなマネージャーは、「ああ、でも、信頼できないユーザーがそれを発見することはほとんどありません。なぜわざわざ修正する必要があるのでしょう」。これはあいまいさによるセキュリティです。
他のいくつかの回答でも触れられていますが、このパズルには3つのピースがあります。
- メカニズム
- 実装/構成
- データ
メカニズムの例は、AES、SHA-1、または例ではSSHです。
実装/構成の例は、SSHがリッスンしているポート、またはアプリケーションのデータを暗号化するために選択した暗号化アルゴリズムです。データの例は、秘密鍵またはパスワードです。
メカニズムは曖昧であってはなりません。 「動作がわからないので安全」はセキュリティではありません。秘密のデータがない状態で実装を悪用することなく、詳細に検査できる必要があります。
実装は不明瞭になる場合と不明瞭になる場合があります。一般に、これを実行しても、セキュリティに重大な影響はありません。 SSHポートを識別するポートスキャンの数が少なくなる場合や、特定の暗号文に使用される暗号化アルゴリズムを非表示にできる場合がありますが、秘密データのない安全なメカニズムの場合は問題になりません。メカニズムはまだ悪用できないはずです。ここには、セキュリティ上の利点がわずかにあり、ユーザビリティにわずかな害があるという議論があります。あなたの走行距離は異なる場合があります。
秘密データはalwaysは不明瞭である必要があります。誰かがあなたの秘密鍵やパスワードを手に入れたら、それらを取り消し、新しい秘密のデータを作成し、次回はそれをよりよく保護することを誓います。
あいまいさに対するセキュリティは、コード/ソースレベルで特定の弱点を修正しないことに関連するすべてのものに適用され、代わりに穴をカバーする回避策を見つけます。その保護層が削除されると、脆弱性が悪用される可能性が出てきます。
そのような例の1つは、プロダクション環境のアプリケーションに接続するための一種の秘密の手段を開発者に提供するプログラムフックです。これは確かにセキュリティ神話の脅威です。しかし、リバースエンジニアリングを行うのに十分な知識を持っている人や、場合によってはネットワークを盗聴するだけですぐに傷つきます。
通常、これらの脅威がシステム/アプリケーション設計のSDLCフェーズで見逃されたときに、これらの脅威が実際に出回る主な理由です。その後、本番環境に移行すると、その時点から修理するのにコストがかかりすぎます。回避策や隠蔽工作が出始めているのです。
別の例パスワードを紙に書いてキーボードの下に置く人
市場要因としても、そのような慣行は通常、クローズドソースのベンダー/コミュニティが従うことを知っておく必要があります。オープンソースプロジェクトの場合、コードは一般向けにリリースされてレビューが行われるため、この概念は実用的な目的には当てはまりません。コードレビューなどの手法を通じて、だれでも問題に対処できます。それをキャッチする最良かつ最も信頼できる方法。
あいまいな概念の実践例によるSSHセキュリティの無効化
- ターゲットネットワークでnessusスキャンを実行すると、脆弱なサービスとマッピングされたポートが表示されます
- オープンサービスのターゲットネットワークでnmapスキャンを実行します。
あいまいさによるセキュリティはセキュリティではありません。「セキュリティシステムは、その秘密が推測されにくいほど安全である」とより正確に述べられている可能性があります。本当に、それに慣れると、暗号化キーはあいまいなので、暗号化はあいまいさによるセキュリティであると主張される可能性があります。違いは、それが非常に曖昧であり、それを見つけることが数学的に実行不可能であり、したがって安全であることです。
シークレットベースのセキュリティシステムでは、シークレットをできるだけ限定し、推測しにくいようにする必要があります。秘密が複雑であるほど、その中に欠陥がある可能性が高くなります。また、秘密にしておく必要のある量を制限すると、秘密に保つことが容易になります。
「あいまいさによるセキュリティはセキュリティではない」という発言は、多くの「巧妙な」アイデアが、何かを試みて攻撃者が何かを理解するのを困難にする複雑な方法を単に思いついているという考えに由来しますが、多くの場合、これらのアプローチは他のステップの他の詳細に影響を与えるため、秘密のアルゴリズムを部分的に知っている攻撃者が残りのアルゴリズムを決定することがどれほど難しいかを知ることは不可能です。
一方、キーはランダムである必要があり、たとえば暗号化キーの数ビットを知っていても、キーの他のビットを理解するのに役立つはずはありません。同様に、キーを理解することの難しさはかなりよく理解されています。アルゴリズムの相対的なセキュリティは、アルゴリズムの機密性に大きな影響を受けない（または確実に定量化できる）ため、統計的に重要なセキュリティは追加されません。
アルゴリズムのセキュリティに統計的に有意な影響を与えるのは、アルゴリズムの問題です。一般に、公開されたアルゴリズムは、それらを壊す欠陥がないか、より徹底的に検査されており、一般に、それらが提供するセキュリティに高い信頼を提供します。
したがって、最後に、ほとんどのセキュリティにはある程度のあいまいさが含まれていますが、秘訣は、量を最小限に抑え、それらの秘密を簡単に保護できるようにすると同時に、システムの誤動作を引き起こし、システムを明らかにする原因となる未検出の欠陥がないことを確認することです。秘密。
すべての暗号化アルゴリズムで、すべてのログインでプロンプト「あいまいさによるセキュリティ」が主要なコンポーネントです。常に何らかの種類の秘密の知識に依存します（2要素認証を除く）。
良いセキュリティと悪いセキュリティの違いは、秘密の知識の特性に関連しています：秘密のままですか？
悪い例は、他のチャネルからこの秘密に関する情報を引き出すことができるシステムです。たとえば、「Zip then XOR with your key」などの独自の暗号化アルゴリズムを発明したとしましょう。攻撃者がシステムを調査し、暗号化スキームのエンコードにかかる時間から圧縮アルゴリズムを特定する可能性があります異なるプレーンテキストメッセージ。攻撃者はシステムについての知識を得て、Zipアルゴリズムの内部を知っており、このデータを使用してキーを決定できる可能性があります。これは完全に優れたアルゴリズムのように見え、圧縮およびxorデータはかなりランダムに見えますが、巧妙な攻撃者に小さな挑戦をもたらすだけです。キーは非常に長くなる可能性がありますが、それによって、あいまいなものと悪いものを区別するのに役立ちません。誤ってパスを埋め込んで、秘密鍵をアルゴリズムに追加します：
反例はRSA公開鍵暗号化です。ここで秘密鍵は大きな素数です。公開鍵は秘密鍵と別の大きな素数の積です。よく知られているRSAアルゴリズムを使用しても公開鍵を提供できるので、必要なデータを暗号化できますが、秘密鍵に関する情報は漏洩しません。
良いセキュリティと悪いセキュリティを区別するために非常に重要なのは、誰かがあなたのデータにアクセスする必要がある時間の長さです。ポート22から2222への具体的な例では、攻撃者が必要とするもう1つの情報が含まれているため、セキュリティにプラスになります。これは短時間で簡単に理解できるので、追加される量はごくわずかですが、キーに関する情報は漏洩しません。このポートスキャンは簡単であり、1回のコストで秘密鍵を知るために必要な情報の総量のみが一定であるため、これが理由です。全体的なセキュリティを向上させることは考慮されていないため、「あいまいなセキュリティ」は一般的には役に立ちません。
「不明瞭」は仮定についてです
「あいまいさによるセキュリティ」は、実際には誤った仮定に関するものだと思います。
たとえば、自分で手作業で暗号化した暗号を単純に使用する場合、「暗号化は一意であるため、解読する方法は誰にもわからない」と考えます。
- 私は知っている鍵を持っている人によって破られる可能性があります。
- I 仮定他の方法では壊れない。これはおそらく誤りです。
実績のある暗号化方法を使用する場合：
- 私は知っている鍵を持っている人によって破られる可能性があります。
- I 良い証拠がある他の方法では壊れないこと。
私はまだ自分の鍵の「あいまいさ」に依存しています。しかし、私が守らなければならないのはそれだけです。
したがって、「あいまいさによるセキュリティ」を検出するには、仮定に挑戦します。誰かが「私たちがXを実行していることを誰も推測も検出もできない」と言った場合、正しい応答はどのくらいの証拠がありますか？セキュリティの基準は非常に高いです。
私はそれをこのように定式化します：
「あいまいさによるセキュリティ」とは、セキュリティメカニズムを破るために必要な手段/情報が攻撃者に意図的にallで提供されている状況を指し、攻撃者はそれを明らかにするために努力を費やすことはありません。
場合によっては、一部のプログラムが「自動」暗号化スキームによってセキュリティを達成しようとすることがあります。この場合、最終的に、暗号化アルゴリズムに加えて、暗号化キーがプログラム自体のどこかに含まれます。プログラム自体は、その「秘密」のデータを復号化するためにそれ以上の情報を必要としません。攻撃者もそうしません。
「本当の」セキュリティは、攻撃者がそれを破るために必要な情報allを決して持たないようにすることを試みます。暗号化を使用する場合、攻撃者が暗号化メッセージとアルゴリズムの両方にアクセスして、暗号化keyは彼に開示されていません。このようにして、彼は重要な情報を拒否され、セキュリティメカニズムをバイパスしただけの情報からは除外できません。
あいまいさは、セキュリティ値を保護されたメディアの使用をどれだけ複雑にするかと比較することで測定できると思います。 SSHポートを変更するとセキュリティが少し向上するが、シェルの使用が非常に複雑になることはすでに述べたとおりです。シェルがどのポートにあるかを覚えて、すべての新しい従業員にこのセキュリティを教える必要があるためです。測定すると、最終的には、ポートがハードコーディングされたユーザーのディスプレイまたは自動スクリプトに添付された付箋となり、セキュリティ値が無効になります。
同様に、ソースコードを難読化して保護することができます。しかし、誰かがそれにアクセスした場合、彼が関数と変数の元の意味を復元する（たとえば、注意深いデバッグによって）のは時間の問題であり、難読化は無意味になります。一方、コードをコンパイルする前に特別なプログラムを実行することを忘れないでください、または（さらに悪いことに、私は見ました）奇妙な命名規則を使用してコードで作業します。
私の意見では、隠蔽を使用することで得られる以上のものを失うので、隠蔽によるセキュリティは悪い習慣と見なされます。
「秘密鍵」には何でも使用できますが、ポートの選択は不適切です。それらの2 ^ 16のみがあり、それらはスニッフィングすることができ、接続の期間中（通常）静的です。
ただし、他に適切な選択肢がない場合は、過去に秘密鍵（の一部）として使用されていました。特に、ポートのランダム化は、数年前の Kaminsky DNSキャッシュポイズニング攻撃に対抗するために使用されました。 16ビットのクエリIDをランダム化することと組み合わせると、これにより32ビットのセキュリティが得られます。これは、通常のDNSクエリの間（約0.1秒）保護するのに十分です。秘密鍵は引き続き盗聴できますが、DNSは常にMITM攻撃に対して常に脆弱であるため、「大したことではない」と見なされます。 C'est la vie。
したがって、あなたの例が「あいまいさによるセキュリティ」であるかどうかは、実際にはコンテキストに依存します。
保護メカニズムのスイート全体がある場合、それらの保護メカニズムのいずれかは「あいまいさによるセキュリティ」だけであると言うかもしれませんが、システム全体のセキュリティを考慮することがより重要です。
個別に、保護メカニズムが攻撃者に依存しない場合、保護メカニズムは「あいまいさによるセキュリティ」と見なされます期待何か、またはその保護メカニズムが暗号よりもむしろ異常であることに依存する場合。言い換えれば、SSHをポート2222に置くことは、攻撃者がそこにあるとは期待しないため（最初の推測ではないため）、それが通常のポートではないため、あいまいさによるセキュリティです。ただし、SSHを強力なパスワードで保護することは、暗号的に強力であることを目的としているため、本当のセキュリティです。さらに、ユーザー名を「ルート」から簡単に推測できないものに変更することも、そこに暗号強度の測定値があるため、本当のセキュリティです。攻撃者がユーザー名を理解できない場合、攻撃者はシステムに侵入できません彼らは正しいパスワードを取得します。
あいまいなことに、私はあなたのセキュリティがハッカーがあなたの暗号化アルゴリズムを認識していないという事実に基づいていることを理解しています。 PASS-> SAPPのように単語の文字を元に戻すか、より複雑な難読化を行うだけで、誰もアルゴリズムを見つけない限り通信できます。暗号化アルゴリズムの公開によりすべてのセキュリティが破壊される場合、それはセキュリティではなく、あいまいさです。本当のセキュリティは、暗号化および復号化アルゴリズムが与えられた場合、ハッカーがメッセージを復号化できないときに始まります。
セキュリティは、意図した受信者またはユーザーであることを認証することによって行われます。認証には3つの要素があります
- ユーザーが知っているもの（パスワード、PIN、パターンなど）
- ユーザーが持っているもの（ATMカード、スマートカードなど）
- ユーザーが何か（たとえば、指紋などの生体認証特性）
ほとんどのセキュリティ対策は単一要素認証を使用します。たとえば、SSHでは、パスワードを知っているか、秘密鍵を持っている必要があります（鍵のパスフレーズが必要なのは、2要素認証と言えるでしょう）。
二要素認証は、最近多くのサービスプロバイダーやソフトウェアによって実装されているものです。これには、上記の2つの要素、通常はパスワードと電話番号が必要です。 2要素認証を使用すると、攻撃者はいずれかのセキュリティ資格情報にアクセスでき、セキュリティで保護されたシステムにアクセスできなくなります。
あいまいさによるセキュリティは、ゼロ要素認証です。秘密を知っている必要はなく、何かを所持している、または特定の人物である必要もありません。認証がなければ認証は行われず、そのため実際のセキュリティはありません。
あいまいさが本当のセキュリティを提供し、弱い慣行を採用していると考える場合にのみ、あなたを傷つけることができます。ただし、ベストプラクティス（強力なパスフレーズの適用、セキュリティ更新の適用、セキュリティ検証済みのアルゴリズムとプロトコルの使用など）を維持しようとする場合、将来の未知の脆弱性から時間を節約できるため、あいまいさが少し役立つことがあります。あいまいであっても、システムが脆弱である場合にあなたを標的にした誰かからの攻撃を防ぐことはできませんが、あなたが全世界に対して脆弱であることを宣伝しません。
Ruby on Rails appを使用していて、去年の1月の休暇中にたまたま離れていた場合、人々がWebサーバー上で任意のコマンドを実行した可能性があります。実際、この広告により、攻撃者は、実行しているテクノロジスタックの種類をランダムに推測し、ランダムなWebサイトをすべて試す必要がある場合よりもはるかに速くあなたを見つけることができます。
または、SSHにゼロデイの弱点があるとしましょう。数年前のDebian SSHキー生成問題のようなものです。人々はランダムにスキャンを開始し、ランダムIPアドレスのポート22で実行されているsshを見つけて、エクスプロイトを実行します。確かに、最初にポートスキャンを実行してsshを検索することはできますが、攻撃者はまず、嘘つきの果物を探します。完全検索では、スキャンが10000倍以上遅くなります。うまくいけば、それまでにあなたは問題にパッチを当てました。ほとんどのランダムIPアドレスではsshなどが実行されないため、攻撃者がポート22（および他のいくつかの222、2222、22222も同様）の後にスキャンを停止することは理にかなっています。ホームサーバーがpingに応答せず、すべてのパケットを39325以外のポートにドロップした場合、sshサーバーが見つかる前に移動する可能性があります。それはあなたを助ける曖昧さです。はい、ネットワーク盗聴者は、1つのSSH接続でリッスンしているポートを簡単に見つけることができます。しかし、ランダムにあなたを標的とした攻撃者の大多数にとって、ネットワークトラフィックをリッスンしてssh接続を観察することはありません。さらに、これらの攻撃者であっても、ssh構成が安全で脆弱性がないと予想される時間の99.9％です。
さらに、ssh -p 39325 -Y [email protected]を入力する手間を省くために、sshを使用するユーザーは頻繁に~/.ssh/configファイルを（authorized_keysおよびid_rsa.pub/id_rsaとともに）設定するので、秘密鍵のパスフレーズを入力した後、ssh fooと入力するだけで接続できます。これで、設定ファイルは完全なドメイン名、ユーザー名、ポート（22でない場合）、およびその他のフラグを記憶します。 sshの場合は、インターネットに接続している場合にポートを変更し、すべての人があなたと同じポートを使用できるようにするのが面倒なので、私だけがそれを使用します（私の自宅のマシン、私のVPS）。社内で複数のユーザーが作業する場合は、外部のインターネットに対してファイアウォールで保護し、VPNを通過するために外部アクセスを要求します。
記録のために、私のVPSは、ポート22でsshを実行していて、ログファイルに記録された約10000 /日の不正な認証試行（すべてユーザー名が存在しないもの）を記録していました。最近3か月のログファイルでは、別のポートで実行されているのはまったくゼロです。