自分で作ったアプリにログイン機能をつけて公開する。そこまで来ると一区切りついた気になりますが、インターネットに公開したログイン画面は、早ければ公開直後から、自動化されたログイン試行の対象になります。誰かが手で試すのではなく、プログラムが大量のパスワード候補を次々に打ち込んでくるのです。
これがブルートフォース攻撃です。この記事では、なぜ総当たりという単純な手口が今も通用するのか、Webサイト以外に何が狙われるのか、そして使う側と作る側それぞれで何をすればいいのかを整理します。


結論:総当たりは「単純だからこそ」効いてしまう
ブルートフォース攻撃とは、プログラムを使って大量のパスワード候補を入力し、正しい組み合わせが見つかるまで試す攻撃です。高度な抜け道を使うのではなく、多数の候補を力任せに試します。
それでも脅威が続いているのは、攻撃を自動化できるからです。攻撃する人は、公開されているシステムを見つけてはボットに任せ、延々とログインを試させます。手間もほとんどかからないので、広い範囲のシステムに対して自動で試行できます。
オンラインとオフラインで、試せる速さは大きく違う
「毎秒何万回も試される」と聞くことがありますが、これは場面を分けて理解する必要があります。
ログイン画面に対する攻撃(オンライン攻撃)では、通信やサーバー側の処理をはさむため、通常そこまで高速には試せません。実際には、複数の端末やIPアドレスを使い分けて、自動で試行を繰り返す形になります。
一方、毎秒何千、何万、場合によってはそれ以上を試せるのは、主にパスワードのデータ(ハッシュ)が漏えいし、攻撃者が自分の手元で解析するオフライン攻撃です。ここでは通信の制約がなくなるため、桁違いに速くなります。守り方も、この2つで少しずつ変わってきます。
パスワードは「長さと、使い回さないこと」で守る
総当たりに対しては、パスワードの作り方が効きます。ただ、単に記号を足せばよいという話ではありません。
人が作るパスワードは、先頭だけ大文字、末尾に123、単語と誕生日の組み合わせ、といった具合に偏りがちです。攻撃者はこの偏りを知っていて、全組み合わせを順番に試すのではなく、よくあるパターンから先に試します。だから見た目が複雑でも、推測しやすければ早く破られます。
強くするうえで中心になるのは、次の3つです。
- 十分に長いこと。
- サービスごとに異なること(使い回さない)。
- 人が考えず、パスワードマネージャーで生成すること。
BitwardenやiCloudキーチェーンなどの管理ツールに、サービスごとの長いランダムなパスワードを持たせておけば、この3つを一度に満たせます。
狙われるのはWebサイトだけではない
ブルートフォース攻撃というとログインフォームを思い浮かべがちですが、狙われるのはそれだけではありません。外部から到達できる認証機能は、どれも対象になります。
Webサイトだけでなく、VPN、リモートデスクトップ(RDP)、SSH、NAS、クラウドの管理画面など、外から到達できてログインを求めるものは、どれも攻撃対象になり得ます。これらは業務システムの根っこにつながっていることも多く、破られたときの被害がWebサイト以上に大きくなりがちです。
ログイン画面を自動で試す攻撃は、総当たりだけではない
実際の攻撃では、総当たりと並んで、次のような手口も使われます。
- 辞書攻撃:よく使われるパスワードや単語のリストを優先して試す。ランダムな総当たりより速く当たりやすい。
- パスワードスプレー:1つのIDに何度も試すとロックされるので、逆に「よくあるパスワード1つ」を大量のIDに広く浅く試す。
- リスト型攻撃(クレデンシャルスタッフィング):総当たりではなく、他サービスから漏えいした「正しいIDとパスワードの組」を、そのまま別サービスで試す。使い回している人ほど当たる。
これらは、まず「実在するID」が分かると精度が上がります。ログイン画面が「IDとパスワードのどちらが違うか」をわざとぼかしているのも、この足がかりを与えないためです。理由はログインエラーでID・パスワードのどちらが違うか教えない、意外な理由で整理しています。


使う側にできること
- 長く、サービスごとに異なるパスワードにする(使い回さない)。
- パスワードマネージャーで生成・保存し、入力もツールに任せる。
- 多要素認証(MFA)を有効にする。認証アプリやセキュリティキー、スマホでの確認など、パスワードとは別の認証がもう一段あれば、パスワードを知られただけでは入られにくくなる。
作る側・管理する側にできること
自分でログイン機能を作る、あるいはシステムを管理するなら、「試し続ける」性質そのものを止める仕組みを用意します。単純に失敗回数でアカウントをロックするだけだと、他人のアカウントをわざとロックさせるいやがらせ(DoS)に悪用されるので、いくつかを組み合わせます。
- ログイン失敗はアカウント単位で追跡しつつ、IPアドレスや端末などの情報も組み合わせて制限する。同じIPだけを見ると、複数IPに分散した攻撃やパスワードスプレーを見逃します。
- 失敗が続いたら段階的に待ち時間を延ばす。必要に応じてCAPTCHAをはさみ、自動試行の手間とコストを増やす。
- 多要素認証を用意する。
- ログイン試行を記録し、異常があれば通知・遮断する。
「異常を検知して遮断」といっても、ここで必要なのはネットワーク全体を見る仕組みではなく、主にアプリケーション側のレート制限、WAF、認証基盤のリスク検知、IPレピュテーション、ログ監視とアラートです。
パスワードの保存も重要です。平文や単純なハッシュではなく、Argon2idやbcryptといったパスワード保存専用の方式を使います。適切なライブラリを使えば、ユーザーごとのソルトは通常、自動で生成・管理されます。計算コストは環境に合わせて適切に設定し、独自にハッシュ処理を実装しないことが重要です。これはログイン画面への総当たりを止めるものではなく、データベースが漏えいした後の、手元での解析(オフライン攻撃)を遅らせるための対策です。
なお、これらはAIに実装させると抜けやすい部分ですが、人が書いても普通に抜けます。AIを使った場合も、ログインできることだけで完成とせず、レート制限・MFA・ログ・パスワード保存方式まで確認しましょう。作ったアプリの認証まわりはAIで作ったアプリのサーバは安全かもあわせてどうぞ。
まとめ
- ブルートフォース攻撃は、大量のパスワードを機械的に試す総当たり。自動化できるため、公開システムは狙われ続ける。
- 試せる速さはオンライン(ログイン画面)とオフライン(漏えいしたデータの解析)で大きく違い、守り方も分けて考える。
- 狙われるのはWebサイトだけでなく、VPN・RDP・SSH・NAS・クラウド管理画面など、外部から到達できる認証機能全般。
- 使う側は、長く・使い回さないパスワードとマネージャー、そして多要素認証。
- 作る側は、アカウントとIPなど複数の単位での試行制限、段階的な待ち時間、MFA、ログ監視、そして漏えい対策としてのArgon2id/bcryptでの保存。
まずは、公開しているシステムのログを一度眺めてみてください。見覚えのないログイン試行が記録されていることは、珍しくありません。




