Webアプリケーションでのパスワードリスト攻撃に対するベストプラクティス
-
19-08-2019 - |
質問
ボットがパスワードで保護された脆弱なアカウントをハッキングするのを防ぎたい。 (たとえば、これはebayや他の大きなサイトで起こりました)
したがって、IP、試行回数、最後の試行のタイムスタンプ(memcache-fall-out)で(mem-)キャッシュ値を設定します。
しかし、ボットが1つのパスワードだけでアカウントを開こうとするとどうなりますか。たとえば、ボットは、パスワード<!> quot; password123 <!> quot;で500.000のすべてのユーザーアカウントを試行します。たぶん10が開きます。
したがって、私の試みは、試行回数でIPをキャッシュし、max-triesを〜50に設定することでした。ログインが成功した後、私はそれを削除します。したがって、グッドボットは、49回ロックをリセットしようとするたびに有効なアカウントでログインします。
それを正しく行う方法はありますか? 大きなプラットフォームはこれについて何をしますか? 50回の再試行で、ばかがプロキシ上のすべてのユーザーをブロックするのを防ぐにはどうすればよいですか?
ベストプラクティスがない場合-これは、プラットフォームがブルートフォース可能なことを意味しますか?少なくともカウンターがリセットされるタイミングに関するヒントはありますか?
解決
ソリューションとキャプチャを組み合わせることができると思います:
- IPごとの試行回数をカウントする
- 特定の時間内に特定のIPアドレスからの試行が多すぎる場合は、 captcha ログインフォームに。
他のヒント
一部のサイトでは、ユーザー名/パスワードと一緒にキャプチャを入力する前に、2〜3回試行することがあります。ログインに成功すると、キャプチャは消えます。
数日前にコーディングホラーに比較的良い記事がありました。 。
コードはDjangoに焦点を当てていますが、ベストプラクティスの方法については本当に良い議論があります Simon Willison <!>#8217; sブログ。彼はmemcachedを使用してIPとログインの失敗を追跡します。
ユーザーが設定するときにパスワード強度チェッカーを使用できますパスワードを使用して、簡単にブルートフォースされたパスワードを使用していないことを確認します。
編集:明確にするために、これはあなたが解決しようとしている問題に対する完全な解決策と見なされるべきではありませんが、他の回答のいくつかと組み合わせて考慮されるべきです。
多くの異なるIPアドレスからボットのグループがこれを試みることを防ぐことはできません。
同じIPアドレスから:<!> quot; suspicious <!> quot;の例を見るなら、言うでしょう。動作(無効なユーザー名、または誤ったログイン試行のあるいくつかの有効なアカウント)、数秒間だけログインをブロックします。正当なユーザーであれば、数秒待ってもかまいません。ボットの場合、これは非現実的なレベルまで速度を落とします。 IPアドレスからの動作が引き続き見られる場合は、それらをブロックしますが、正当なユーザーには帯域外のドアを残します(電話番号xに電話するか、このアドレスにメールを送信します)。
注: IPアドレスは、何千人、または何百万人ものユーザー間で共有できます!!!たとえば、AOLのネットワークアーキテクチャにより、ほとんど/すべてのAOLユーザーは非常に小さなIPアドレスのセットとして表示されます。ほとんどのISPは、大規模なユーザーベースを少数のパブリックIPアドレスにマップします。
IPアドレスが1人のユーザーのみに属すると想定することはできません。
1人のユーザーが1つのIPアドレスのみを使用すると想定することはできません。
ブルートフォース攻撃や辞書攻撃に対するベストプラクティスについて説明している次の質問を確認してください。