7文字のパスワードは安全ではなくなったという記事を読んだばかりです。ただし、サーバーがログイン試行のたびにログイン試行を再試行する時間を増やす場合、ブルートフォース攻撃は役に立ちません。asp.netでそのようなロジックをどのように作成しますか?どういうわけか、サーバー側のコードはログインを試みたIPアドレスを記憶する必要があり、新しい試行ごとに応答時間を増やす必要があると思いますか?
4 に答える
IPアドレスは、実際にはユーザーを識別するための安全な方法ではありません。ログイン試行が最後に送信された時刻をCookieに保存してみることができますが、ブラウザがそれらを受け入れない場合は、使用が制限されます。セッション変数にもCookieが必要なため、Cookieは使用できません。
一部のサイト(yahooが頭に浮かぶ)は、3回目程度の試行後にキャプチャフォームの表示を開始します。ログインの詳細に加えて、キャプチャに正しく答える必要があります。
もう1つのオプションは、X回の試行が失敗した後にアカウントを無効にすることです(データベースで追跡できます)が、パスワードを忘れたときに誰かに電話してパスワードをリセットするように強制する傾向があるため、個人的にはこれが嫌いです。
ASP.NET には、ログイン パスワードに対するブルート フォース攻撃を防ぐメカニズムが組み込まれています。maxInvalidPasswordAttempts メンバーシップ プロパティを参照してください。
パスワードを安全にハッシュし、ブルート フォース攻撃をブロックするなど、セキュリティのベスト プラクティスに従っていれば、7 文字のパスワードはほとんどの Web アプリケーションに完全に適しています (私の銀行では 7 文字のパスワードが許可されています)。
7 文字または 8 文字のパスワードを超えると、「私のアプリは非常に安全である必要がある」と本当に言っていることになります。この場合、個別のクライアント SSL 証明書を検討する必要があります。パスワードでより多くの文字を要求すると、利益が減少します。8 文字または 9 文字の複雑なパスワードを覚えているユーザーは何人ですか? 彼らはそれらを書き留めてしまいます。個人的には、非常に複雑なパスワードの作成を要求するサイトには断られます。
ASP.NET メンバーシップは、適切にセットアップされている限り、セキュリティに関するほとんどの困難な作業を行います。
ただし、次のように、ASP.NET メンバーシップで実行できないことがいくつかあります。
- HTTPS が使用されていることの確認
- CSRF および同様の攻撃の防止
- すべての Web 要求が ASP.NET にルーティングされるようにして、静的コンテンツが IIS によって提供され、ASP.NET 認証をバイパスするのを防ぎます。
- ユーザーが人間であることの確認 (CAPTCHA)
セキュリティのベスト プラクティスの詳細については、OWASPを参照してください。
ブルート フォース攻撃の多くはオフラインで発生します。そのため、試みに失敗した場合のロックアウトは、複雑なパスワードの要求、適切な「ソルト」の使用、および鍵の強化に代わるものではありません。
心配すべき攻撃が少なくとも 3 つあります。
- 特定のユーザーに対する標的型攻撃。攻撃者がログインするのを難しくしたいが、あまり難しくしたくない。CAPTCHA で十分です (ただし、ログイン ページにパスワードが表示されなかった場合は、ユーザーにパスワードを再度入力させないでください)。
- 多くのユーザーに対する大規模な攻撃。個々のユーザーをロックアウトするのは少し無意味です。攻撃者は (たとえば) 3 つのパスワードを試してから、別のアカウントに移動できるからです。IP ごとの CAPTCHA で十分かもしれませんが、IP ごとに (またはホワイトリストに登録されたプロキシのリストの場合は X-Forwarded-For で) レート制限することもできます。これは、攻撃者のボットネットの規模によって異なります。十分な大きさのボットネットは、複数のボット/サイトに攻撃を分散させて、各サイトが各 IP から低いレートを取得できるようにします。
- パスワード データベースに対するオフライン攻撃。この場合、適切なハッシュ (NTLM は適切なハッシュではないMD4 の単一の呼び出しを使用する) でも、少なくとも約 50 ビットのエントロピーが必要であり、比較的通常の 8 文字のパスワード (8 文字) では取得できません。 log 2 (94) はわずか 52.4 です)。
試行ごとの IP をツリーに格納して、ツリーの密度の高い部分をグループ化することができます。次に、それをバケット化します (10 分ごとに新しいツリーを構築し、古いツリーをさらに 10 分間維持します)。これには、近隣の IP が同様の動作を示す可能性が高いという誤った仮定がありますが、IPv4 を (たとえば) /24 にクラスタリングするだけに適切にダウングレードされます。
特に寛大に感じている場合は、ログアウト時にクリアされない別の Cookie をログイン時に保存し、コピーをデータベースに保存できます (128 ビットのランダム値で十分です)。ログイン試行時に、ブラウザが正しい Cookie を提示する場合は、ブラウザに「優しく」してください (たとえば、IP ごとまたはユーザーごとの失敗率をカウントせずに、その Cookie で 3 回の試行を許可します)。これは、ユーザーのアカウントが総当たり攻撃されている場合でも、アカウントへのアクセスに最後に使用されたマシンには CAPTCHA が表示されないことを意味します。
一般に、パスワードの長さや「文字の種類」よりも、パスワードのエントロピーについて話す方が便利です。ほぼ全員が最初の文字を大文字にして、末尾に 1 を付けていると確信しています。また、パスワード エントロピーも記述している「人間に優しい」パスワード ジェネレーターもまだ見たことがありません。