新語は本当のセキュリティを追加しますか？
このホワイトペーパー は、パスワードデータベースが危険にさらされているかどうかを検出するためのハニーワードの概念を提案しています。
私が理解している限り、これは次のように機能します。
ユーザーごとにn個のパスワードハッシュを保存します。1つは実際に実際のパスワードを含み、n-1はいわゆるハニーワード（誤ったパスワード）を含みます。正しいパスワードハッシュは、それらのハニーワードハッシュ間のランダムインデックスに格納されます。
これらのハニーワードの1つが実際のパスワードの代わりにログイン試行で使用された場合、サーバーはアカウントを禁止したり、サイレントアラートをトリガーしたり、攻撃者をある種のハニーポットにリダイレクトしたりできます。どちらの方法でも、サーバーはパスワードデータベースが侵害されたことを認識します。
パスワードが本物かどうかを確認するために、サーバーは指定されたパスワードハッシュのインデックスを決定し、これがこのユーザーの正しいインデックス（またはハニーワードインデックス）かどうかを確認する別の「安全な」サーバーに連絡します。
この方法は、実際のセキュリティ上の利点を本当に追加しますか？
これは紙からの攻撃シナリオであり、ハニーワードが役立つはずです：
パスワードハッシュの盗まれたファイル：攻撃者は、何らかの方法でパスワードハッシュのファイルを盗み、オフラインのブルートフォース計算を使用して多くのパスワードを解決することができます。より一般的には、多くのシステム、または1つのシステムでさまざまなタイミングでパスワードハッシュファイルを盗むことができます。
このシナリオでは、攻撃者は明らかにシステムにすでにアクセスしています。
- とにかく彼は本当にパスワードデータを必要とするでしょうか？
- 彼がパスワードストアにアクセスできた場合、実際のパスワードを識別する "安全な"インデックスストアにもアクセスできる可能性はありませんか？ 2つのサーバーに認証を分散するだけでは、安全性ははるかに高くなります。
- 侵害されたシステムが正しいインデックスを見つけることができれば、攻撃者も同様にできるはずです。
概念に何か欠けているかもしれませんが、パスワードが安全にハッシュされ、最初のセキュリティ層が攻撃者をそもそも侵入させないようにすることは、より有用ではないでしょうか？
愛らしい単語は、実際のWebアプリケーションに組み込むことを検討する価値がありますか？
あなたは提案を少し間違って読んでいます。これは、すでに侵害されたシステムへの侵入を検出するための安全策ではなく、侵害されたシステムのデータベースを検出する手段として意図されています。これはまったく異なるシナリオであり、攻撃者はエンドユーザーのパスワードを知っていてもシステムにアクセスすることはできませんが、somehow（不適切に破棄されたバックアップ、物理的な侵入など）ハッシュされたパスワードを格納するリークされたユーザーデータベースを手に入れました。
想定されるのは、攻撃者はどのブルートフォースハッシュが個々のユーザーの実際のパスワードと一致するかを知らず、代わりにハニーワードパスワードを使用してアラームをトリガーする可能性があることです。これについては、これまでに読んだのと同じくらいまともな方法ですが、実際の実装はまだ確認されていません（計算のオーバーヘッドは、遅いアルゴリズムを使用した適切なハッシュではかなりのものになります）。また、ハニーポット自体の機能が制限されているため、以前に使用したIPがすでにブラックリストに登録されている場合、攻撃者が他のIPによる追加のログイン試行を防ぐことができるため（これは攻撃者になることは簡単です）、検出はわずかです。それにもかかわらずメカニズムは健全です。
問題は、そのような試みが検出された後、次に何が起こるかです。最も明白な解決策は、問題のユーザーアカウント（攻撃者がハッキングしようとしたアカウント）を無効にすることですが、実際のユーザー自身がそのようなhoneywordsを誤って入力するとどうなりますか？これらの単語は、ユーザー自身がパスワードとして選択したものとは実質的に異なる必要があります。また、ハニーワードの単語に対して実際のパスワードを配置するデータベース内の場所など、他の制約があります。
それでも、これらの質問は適切に対処するのが簡単な場合があり、そのような保護手段がない場合に何が起こるかと比較して安いです。これは言った、あなたの質問への答えは-はい、間違いなくです。
これが機能しない主な理由は、スマート攻撃者は、DBダンプを取得し、別のサーバーから有効なハッシュ選択を取得する必要があるとわかった場合、それが何であるかをすぐに理解することです。別のレベルの難易度が追加されますが、1人のユーザーに対して50個のパスワードハッシュがある場合、何が起こっているかは非常に明白であるため、ハッカーがこれをトリガーするとは思わないでしょう。
これは、メインDBにユーザーへのリンクなしですべてのパスワードを保存し、2番目のサーバーに毎回使用するパスワードハッシュをサーバーに指示させることと実質的に同じですが、おそらく誤検知の可能性が高くなります。人々が同様のパスワードを使用し、誤って他人のパスワードを使用する可能性があるためです。異なるユーザーと一致する複数の不正なパスワードの試行を探すことは、誰かがそれらを一致させようとしていることを迅速に理解する良い方法であり、攻撃者が何が起こっているのかを知るのが少し難しいでしょう。 （ただし、メインのDBがユーザー名をPWにリンクしていないことが確認され、その情報が検索されます。）
- この論文は、trap-passwordsは実際のパスワードよりも簡単に解読できるはずだと述べています。次に：
- また、クラッカーがトラップパスワードを取得できる場合でも、実際のパスワードが危険にさらされているとは決して言えません。
- 'qwe123' 'complexity'のパスワードを設定した場合、攻撃者がログインプロセスを利用できる場合、そのようなパスワードがすぐに解読されることを予測する新しい方法は必要ありません。
この方法は「あいまいさによるセキュリティ」モデルを強調しているようです-誰もパスワードを解読しようとしない限り、パスワードが安全であることを確認します。また、このようなスキーマを実装するために必要なリソース（BillにWindowsセキュリティモデルの変更を依頼する人はいますか？）も考慮に入れてください。ちなみに、このアイデアは蜂蜜の基本的な実践を損なうものです-あなたはあなたの作品をどんな目的でもより脆弱にしないでください。
ネットワークハニーネットは、本番環境から完全に分離できるという点で優れているため、実際の妥協があったとしても、被害はありません。ここで、攻撃者がそのようなハニーパスワードを気付かないうちに早く侵害した場合はどうなりますか？また、設定時の人為的ミスによるこのハニーパスワードが実際のユーザーレベルのアクセスを許可する場合はどうなりますか？
はい、それはいくつかのセキュリティ価値をもたらします。
これはCCTVに例えることができるセキュリティ手段であり、それは探偵のコントロールであり、物事が手に負えなくなる前にあなたが措置を講じることを可能にするかもしれません。アカウントを無効にする/ユーザーアカウントのパスワードをリセットする/パスワードを再利用した場合に備えてユーザーに迅速に通知する.
とにかくパスワードデータが本当に必要ですか？
このシステムでは必ずしも必要ではありませんが、パスワードの再利用のために、このメールとパスワードの組み合わせを他のサイトで試す可能性があります。