ブルートフォースアタック対策がしたい

現在この投稿に設定したタグの技術を使ってログイン画面の実装をしています。

質問があるのですが、
結論から言うと、
ブルートフォースアタック（総当たり攻撃）対策のためログイン画面のサーバー側の実装に１秒のウェイトをかけたいのですが、どのように実装したらいいでしょうか？

具体的なコードに関しては以下で行おうと思っています。（おそらく後者）

java
1- Thread.sleep(1000)
2- TimeUnit.SECONDS.sleep(1)

あとはどのタイミングにこの実装を入れるか、なのですが、こちらに関してご意見をお聞きしたいです。
レスポンスを返すタイミングだとは思うのですが、
具体的にはどこでしょうか？

「（ログインボタン押下）→エラーチェック→ログイン情報更新→（トップ画面を表示）」
というサーバー側の大まかな処理に対して、タイミングとしては、
・エラーチェックの前でしょうか？
・エラーチェックの後でしょうか？
・トップ画面を表示の後でしょうか？

もしアドバイスを頂ける方がいらっしゃいましたらよろしくお願いいたします。

行動規範の内容に同意します

回答4件

ベストアンサー

ブルートフォースは認証突破を目的とした攻撃ですので、認証時間を意図的に長くする方法は
根本的な解決ではありませんが、劇的に突破までの時間を伸ばせますので少なからず効果はあります。
時間がかかりそうなサイトであれば、攻撃者も他のサイトを狙った方が効率いいですしね。

家の鍵が２個ついてるのを見つけた時点で諦めて、鍵が１個の家にターゲットを変えるという
泥棒の心理です。

遅延させるタイミングはいつか？という質門ですが、
認証に失敗したら遅延させてレスポンスするというのでいいのではないでしょうか。
認証OKな内容にも関わらず遅延させるのは意味がないですし、
不正アクセスではない、本物のユーザーにも影響が出ますし。

一定回数失敗したらブロック

この仕組みが、同じユーザーIDに対する試行が一定回数失敗したらブロックというものであれば、
ブルートフォースは防げますので、ないよりは断然いいのですが、
リバースブルートフォースに対しては効果がありません。
リバースブルートフォースは良くありそうなパスワード（Password, password, asdfghjkなど）
で固定して、ユーザーIDを総当りするという攻撃です。

なので、一定回数失敗と判断するのは同一IPアドレスでというものにした方が効果は高いでしょう。
同一セッションIDとかも、毎回Cookieを削除されて送信されれば効果はありません。

csrf対策のトークンがクライアント側に設置されています。

これは二要素認証ではないです。
レスポンスボディを見れば、どれがトークンかはわかりますので、
それをリクエストに乗せればトークンチェックをすり抜けることは可能ですし、
単純にブラウザでのログイン処理を自動化するプログラムでも攻撃は可能です。

二要素認証は、ユーザー自らの入力により認証を２回行うことですね。
１つ目の認証がOKだと、もう１つ認証画面を挟んで、そこでコメントに記載されているような
『ユーザだけが知っている何か』
『ユーザだけが所有している何か』
『ユーザ自身の特性（指紋など）』
を入力させたりといったものです。

他にも１つ目の認証がOKだと、登録されているメールアドレスにアクセストークンを送信し、
そのアクセストークンを入力してもらうなどもあります。
メールの確認にはメールアカウントの認証が必要になりますので、二要素認証となります。

ただ、二要素認証はログインするまでのステップが増えるため、
ログインするのにめんどくさいというユーザーが少なからず出てはきますね。。。
ユーザビリティとセキュリティはトレードオフなので、難しいとこではあります。

CAPTCHAを設置するのが比較的ユーザーへの負担も軽く効果的かもしれませんね。
よくある「この画像に書かれている文字を入力してください」みたいなやつです。

投稿2018/03/05 02:29

編集2018/03/05 02:49

root_jp

総合スコア4666

k499778

2018/03/05 15:53

わかりやすく、丁寧名ご説明ありがとうございます。新たな知識も具体例があり、なおかつ馴染みがあるものなのでスッと頭の中に入ってきました。二要素認証はよくあるメールが送られてきてそれのリンクを踏むと認証成功となるものですね！勉強になります。

k499778

2018/03/05 15:56

それも踏まえて質問があるのですが＞認証に失敗したら遅延させてとありますが、今回の場合具体的にはどのタイミングでしょうか？「エラーチェックの後」で合ってますよね？エラーチェック判定が失敗したらエラーメッセージをviewに返しますが、その前に１秒遅延させるイメージで合っていますでしょうか？

root_jp

2018/03/06 00:04

エラーチェックというのが何なのか良く分からないと、それ以上具体的に言うのが難しいんですが、例えば以下のタイミングです。１．IDとパスワードがリクエストされてくる２．それらが正しい組み合わせかをデータベースに問い合わせる３．正しければログイン後の画面に遷移。正しくなければ遅延させて再度入力画面を表示「エラーチェック」が上記のような認証処理のことを言っており「エラーチェックの後」が上記の３のタイミングで言っているのであれば違います。そちらの言葉に合わせると、エラー（認証失敗）であれば遅延です。エラーでない（認証成功）時に遅延させる意味はありません。

k499778

2018/03/06 23:18

返答ありがとうございます。はい、エラーであれば遅延という意味です。丁寧に対応していただきありがとうございました。

退会済みユーザー

2018/03/06 23:20

ログインフォームでパスワードはn文字以上で入力してくださいとか出したいんですって（別質問）

k499778

2018/03/06 23:22

それ結果なくなりました！(笑)

行動規範の内容に同意します

そもそもやろうとしてることがブルートフォースアタックの対策として間違ってるのでは…。
一定回数失敗したらブロックとか二要素認証とか一般的な対策が先。
ログインに限らず大量アクセスは自動ブロック。これはサーバーに届く前にやること。

投稿2018/03/04 16:31

kawax

総合スコア10377

k499778

2018/03/04 23:15

回答ありがとうございます。そーなのですね！要求としては、1秒レスポンス送る前に遅延させるというものでして、それをブルートフォース対策と勝手に認識していました。であれば、1秒遅延はどのような対策にあたりますでしょうか？もしご存知であれば教えていただければと思います。一定回数失敗したらブロックは取り入れております。二要素認証は知識としてなかったので、調べています。

k499778

2018/03/04 23:29

二要素認証に関してもできています。調査の結果、『ユーザだけが知っている何か』『ユーザだけが所有している何か』『ユーザ自身の特性（指紋など）』の２つの組み合わせだと知りました。ATMで言うと、暗証番号とキャッシュカード。今回spring-securityを使っていることもあり、csrf対策のトークンがクライアント側に設置されています。・トークン・ログインパスワードの2点でその要件を満たしています。

行動規範の内容に同意します

ブルートフォースアタック対策でログイン認証を1秒遅延させるという行為ですが、結論から言うと、対策にはなりません。

そもそも、人間が手動やるのであれば、Chrome等のブラウザによって、画面が表示され、IDやパスワードを入力し、ログインボタンを押下等をしなければ、ログインを試せませんが、プログラムで自動的にやる場合は、画面が表示されたりするのを待つ必要はないんです。

ウェブアプリのログイン認証を試行したい場合、HTTPリクエストを特定のパラメーターで送ればすみますし、ログインボタンを押下時にどういうリクエストが送られてるかは開発者ツール等で容易に知ることができます。

また、サーバーからのレスポンス（認証結果OK or NG)が返ってこないと、再度、リクエストが送れないわけでもないので、1秒遅延がかかっていようと関係なく、トラフィックの許す限りリクエストを送り続けて
試すことも可能です。

他の人も書いている通り、特定のユーザーIDに対して、連続して一定回数認証失敗したらアカウントロックする等が現実的な対策だと思います。

投稿2018/03/06 01:01