web-dev-qa-db-ja.com

ログインにX回失敗した後、ユーザーアカウントをロックする必要がありますか？

ログインシステムの開発はほぼ終了し、もう1つ不明な点があります。無効なログインのカウントとユーザーアカウントのロックについてインターネットで見つけた非常に多くの議論。私のシステムは、ユーザー名とパスワード（ソルト[ユーザーごとに異なるソルト]でハッシュされている）をデータベースに保存しています。ユーザーが無効なユーザー名またはパスワードを入力した場合、ユーザー名、パスワード、LoginTime、SessionID、IP、およびブラウザーを追跡します。次に例を示します。

LoginID   LoginTime                 LoginUN    LoginPW    LoginSessionID    LoginIP     LoginBrowser    
   1    2018-03-15 13:40:25.000     jpapis     test       E72E.cfusion      10.18.1.37  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
  98    2018-03-15 13:48:45.000     mhart      mypass55   E72E.cfusion      10.12.1.87  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
  32    2018-03-15 14:29:14.000     skatre     1167mmB!   378E.cfusion    10.36.1.17    Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Xの試行後にアカウントをロックする必要があるかどうか疑問に思っていますか？もしそうなら、それを行うためのベストプラクティスは何でしょうか？ここに私が見つけた1つのアプローチがあります：

SELECT COUNT(LoginID) AS countID, DATEDIFF(mi,LoginTime,GETDATE ( )) AS TimeElapsed
FROM FailedLogins
WHERE (LoginUN = '#username#' OR LoginSessionID = '#SESSION.sessionid#' OR LoginIP = '#REMOTE_ADDR#')
    AND DATEDIFF(mi,LoginTime,GETDATE ( )) <= 60
GROUP BY LoginID, LoginTime
HAVING COUNT(LoginID) >= 5;

上記のクエリは、ユーザー名、セッションID、またはIPアドレスを探します。これらのいずれかが60分以内にFailedLoginテーブルで見つかり、5より大きい場合、アカウントをロックします。ここでの唯一の問題は、これが何を防ぐことができるかわからないことです。ブルートフォース攻撃は60分で送信しようとする試みが多すぎるため、この方法で失敗したログインをチェックするメリットが何であるかわかりません。今日失敗したログインを処理するより良い方法はありますか？アカウントをロックする必要がありますか？誰かがいくつかの考えや例を提供できる場合は、私に知らせてください。また、システムについての詳細を共有したいと思います。システムにはお金の取引はありません。また、ユーザーアカウントに関連付けられていません。私たちはシステムに機密情報を持っているので、ハッカーがいくつかのハッカー技術でパスワードを破ろうとするのを防ぐためにセキュリティ機能を実装したいと思います。ありがとうございました。

authenticationpasswordsbrute-forceaccount-securityaccount-lockout
3
espresso_coffee

リモートアプリケーションのアカウントロックアウト（攻撃者が追加の作業なしに試行回数をリセットできない場合など）は、アカウントに対するブルートフォース攻撃を簡単に防ぐためです。非常に弱いまたは一般的なパスワードを選択するユーザーがいて、システムがこれらの使用を阻止しようとしない場合、アカウントロックアウトが実装されていても、攻撃者が一部のアカウントにアクセスできる可能性があります。ただし、それが実装する価値がないことを意味しているわけではありません。わずかに優れたパスワードを選択するユーザーの場合、攻撃者の速度が大幅に低下し、潜在的な攻撃についてユーザーまたはユーザーに警告する場合があります。

これは、パスワードの保存方法を選択することとは異なります。パスワードの保存方法は、通常、ユーザーデータベースを取得した攻撃者から身を守るためのものです。明らかに、その場合、誰かが好きなだけパスワードを推測しようとするのを止めることはできません-彼らは単純にあなたのDBからソルトでパスワードの束をハッシュし、同じを与えるパスワードが見つかるまで比較することができますハッシュ。

ただし、失敗した試行をログに記録するために使用している特定の方法には問題があります。ユーザー名と間違ったパスワードをログに記録しています。ほとんどの場合、正当なユーザーがパスワードを打ち間違える可能性は、攻撃者がシステムにログインしようとする可能性よりも高くなります。その場合、保持しているログテーブルは攻撃者にとって貴重になります。ログテーブルには、アカウントの有効なパスワードに近い可能性が高い文字列を含むユーザー名が含まれています。ユーザーがサイト専用のパスワードを持っている場合、DBにアクセスした場合や、他のシステムがアカウントロックアウトスキームを使用している場合でも、同じパスワードを持つ他のシステムにユーザーがアカウントを持っている場合は、ブルートフォースパスワードに必要な労力を大幅に減らすことができます。攻撃者は、試行制限内で正しいパスワードを推測する可能性がはるかに高くなります。

パスワードを保存する必要はありません。各アカウントに対する試行回数のみが気になります。これは、loginidにリンクされた整数値である可能性があり、ロックアウトプロセスには十分です。ソースIPを個別に保存し、異常なトラフィックパターンを監視できますが、NATされた接続を介してサイトに接続している正当なユーザーをブロックするリスクがあります-モバイルプロバイダーは、多くのユーザーをグループ化して、たとえば、単一のIPアドレス。

アカウントロックアウトの一般的なパターンの1つは、アカウントに対する失敗した試行の数を監視してから、そのアカウントに対して増分時間ブロックを適用することです。たとえば、試行が3回失敗した後、さらに5分間試行をブロックできます。さらに3回の試行が失敗した場合は、アカウントを10分間ブロックします。これにより、正当なログインが発生するとリセットされます。ログイン時に失敗した試行の数をユーザーに表示することも役立ちます。ユーザーが何か奇妙なものを見つけた場合、潜在的に問題を警告することができます。

アカウントロックアウトスキームを実装する際に注意する必要がある微妙な点の1つは、適切に実装されていない場合、Oracleのユーザー名として機能できることです。この場合、有効なアカウントと存在しないアカウントの間の異なる動作を特定し、特定のユーザー名が有効であることを攻撃者に知らせます。これを防ぐには、提供されたすべてのユーザー名を監視し、存在しないユーザーに対して有効なユーザーと同じ動作を表示するか、アカウントがロックされているときに単に表示しないようにします。これを選択すると、ユーザーが混乱して、ユーザーが知らないうちに攻撃を受けた場合にログインできない可能性があります。

4
Matthew