Q&A
回答ありがとうございます。
そーなのですね！
要求としては、1秒レスポンス送る前に遅延させるというものでして、
それをブルートフォース対策と勝手に認識していました。
であれば、1秒遅延はどのような対策にあたりますでしょうか？
もしご存知であれば教えていただければと思います。
一定回数失敗したらブロックは取り入れております。二要素認証は知識としてなかったので、調べています。
現在この投稿に設定したタグの技術を使ってログイン画面の実装をしています。
質問があるのですが、
結論から言うと、
ブルートフォースアタック（総当たり攻撃）対策のためログイン画面のサーバー側の実装に１秒のウェイトをかけたいのですが、どのように実装したらいいでしょうか？
具体的なコードに関しては以下で行おうと思っています。（おそらく後者）
java
1- Thread.sleep(1000) 2- TimeUnit.SECONDS.sleep(1)
あとはどのタイミングにこの実装を入れるか、なのですが、こちらに関してご意見をお聞きしたいです。
レスポンスを返すタイミングだとは思うのですが、
具体的にはどこでしょうか？
「（ログインボタン押下）→エラーチェック→ログイン情報更新→（トップ画面を表示）」
というサーバー側の大まかな処理に対して、タイミングとしては、
・エラーチェックの前でしょうか？
・エラーチェックの後でしょうか？
・トップ画面を表示の後でしょうか？
もしアドバイスを頂ける方がいらっしゃいましたらよろしくお願いいたします。
回答4件
0
ベストアンサー
ブルートフォースは認証突破を目的とした攻撃ですので、認証時間を意図的に長くする方法は
根本的な解決ではありませんが、劇的に突破までの時間を伸ばせますので少なからず効果はあります。
時間がかかりそうなサイトであれば、攻撃者も他のサイトを狙った方が効率いいですしね。
家の鍵が２個ついてるのを見つけた時点で諦めて、鍵が１個の家にターゲットを変えるという
泥棒の心理です。
遅延させるタイミングはいつか？という質門ですが、
認証に失敗したら遅延させてレスポンスするというのでいいのではないでしょうか。
認証OKな内容にも関わらず遅延させるのは意味がないですし、
不正アクセスではない、本物のユーザーにも影響が出ますし。
一定回数失敗したらブロック
この仕組みが、同じユーザーIDに対する試行が一定回数失敗したらブロックというものであれば、
ブルートフォースは防げますので、ないよりは断然いいのですが、
リバースブルートフォースに対しては効果がありません。
リバースブルートフォースは良くありそうなパスワード（Password, password, asdfghjkなど）
で固定して、ユーザーIDを総当りするという攻撃です。
なので、一定回数失敗と判断するのは同一IPアドレスでというものにした方が効果は高いでしょう。
同一セッションIDとかも、毎回Cookieを削除されて送信されれば効果はありません。
csrf対策のトークンがクライアント側に設置されています。
これは二要素認証ではないです。
レスポンスボディを見れば、どれがトークンかはわかりますので、
それをリクエストに乗せればトークンチェックをすり抜けることは可能ですし、
単純にブラウザでのログイン処理を自動化するプログラムでも攻撃は可能です。
二要素認証は、ユーザー自らの入力により認証を２回行うことですね。
１つ目の認証がOKだと、もう１つ認証画面を挟んで、そこでコメントに記載されているような
『ユーザだけが知っている何か』
『ユーザだけが所有している何か』
『ユーザ自身の特性（指紋など）』
を入力させたりといったものです。
他にも１つ目の認証がOKだと、登録されているメールアドレスにアクセストークンを送信し、
そのアクセストークンを入力してもらうなどもあります。
メールの確認にはメールアカウントの認証が必要になりますので、二要素認証となります。
ただ、二要素認証はログインするまでのステップが増えるため、
ログインするのにめんどくさいというユーザーが少なからず出てはきますね。。。
ユーザビリティとセキュリティはトレードオフなので、難しいとこではあります。
CAPTCHAを設置するのが比較的ユーザーへの負担も軽く効果的かもしれませんね。
よくある「この画像に書かれている文字を入力してください」みたいなやつです。
投稿2018/03/05 02:29
編集2018/03/05 02:49
総合スコア4666
0
そもそもやろうとしてることがブルートフォースアタックの対策として間違ってるのでは…。
一定回数失敗したらブロックとか二要素認証とか一般的な対策が先。
ログインに限らず大量アクセスは自動ブロック。これはサーバーに届く前にやること。
投稿2018/03/04 16:31
退会済みユーザー
総合スコア0
二要素認証に関してもできています。調査の結果、
『ユーザだけが知っている何か』『ユーザだけが所有している何か』『ユーザ自身の特性（指紋など）』の２つの組み合わせだと知りました。ATMで言うと、暗証番号とキャッシュカード。
今回spring-securityを使っていることもあり、csrf対策のトークンがクライアント側に設置されています。
・トークン
・ログインパスワード
の2点でその要件を満たしています。
0
ブルートフォースアタック対策でログイン認証を1秒遅延させるという行為ですが、結論から言うと、対策にはなりません。
そもそも、人間が手動やるのであれば、Chrome等のブラウザによって、画面が表示され、IDやパスワードを入力し、ログインボタンを押下等をしなければ、ログインを試せませんが、プログラムで自動的にやる場合は、画面が表示されたりするのを待つ必要はないんです。
ウェブアプリのログイン認証を試行したい場合、HTTPリクエストを特定のパラメーターで送ればすみますし、ログインボタンを押下時にどういうリクエストが送られてるかは開発者ツール等で容易に知ることができます。
また、サーバーからのレスポンス（認証結果OK or NG)が返ってこないと、再度、リクエストが送れないわけでもないので、1秒遅延がかかっていようと関係なく、トラフィックの許す限りリクエストを送り続けて
試すことも可能です。
他の人も書いている通り、特定のユーザーIDに対して、連続して一定回数認証失敗したらアカウントロックする等が現実的な対策だと思います。
投稿2018/03/06 01:01
総合スコア253
回答ありがとうございます。
アカウントロックに関しては対応済みです。
うーん、やはりそうなのですね、、、。少し検討してみます。貴重なご意見ありがとうございました。
0
質問者さんの質問（オンライン攻撃への対処方法）の直接の回答ではなく、オフライン攻撃の話ですので、興味がなければスルーしてください。
オフライン攻撃というのは、何らかの形で漏洩したデータを、辞書攻撃・総当たり攻撃・レインボーテーブルによる探索などによって攻撃者の手元で解析して、読み出し可能な情報に戻すことを言ってます。
オンライン攻撃の場合、アカウントロックや IP アドレス単位のアクセス制限などが有効だと思いますが、これに対して、オフラインの総当たり攻撃は、いくらでも好きなだけ時間をかけて何回でも試行できます。
なので、このスレッドの表題にある「ブルートフォースアタック」という言葉から、自分的はオフライン攻撃の話と思いました。
オフライン攻撃の対策は、ハッシュのアルゴリズムその他の情報は攻撃者にバレているという前提で、それでも元のパスワードが保護できるかを考えることだそうです。
そのために有効な手段が、(1) 利用者に良質なパスワードを設定してもらう、(2) ハッシュ、(3) ソルト、(4) ストレッチングだそうです。
詳しくは以下の記事に書いてありますので、興味があれば読んでください。
本当は怖いパスワードの話
http://www.atmarkit.co.jp/ait/articles/1110/06/news154.html
投稿2018/03/05 09:05
退会済みユーザー
総合スコア0
あなたの回答
tips
プレビュー
2018/03/05 15:53
2018/03/05 15:56
2018/03/06 00:04
2018/03/06 23:18
退会済みユーザー
2018/03/06 23:20
2018/03/06 23:22