パスワードに関するサイバー攻撃の仕組みと対策

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

1. 導入：パスワード攻撃の全体像
2. パスワード攻撃が成立する背景
3. オンラインでのパスワード推測攻撃
4. オフラインでのパスワードクラック
5. 認証情報窃取型の攻撃（フィッシング・キーロガー等）
6. リスト型攻撃（パスワードリスト攻撃）とクレデンシャルスタッフィング
7. 攻撃に強いパスワード設計と運用
8. まとめ：エンジニアとして押さえるべきポイント
A. 参考サイト
B. 関連書籍

1. 導入：パスワード攻撃の全体像

パスワードは現在も、多くのシステムやサービスで利用される代表的な認証要素（本人確認のための情報）である。
一方で、SNS・EC サイト・ネットバンキングなどのサービスでは、不正ログイン被害が継続的に報告されている。日本の公的機関やメディアの報告でも、総当たり攻撃・辞書攻撃・リスト型攻撃（パスワードリスト攻撃）・フィッシングなどが主な手口として挙げられている。(IPA)

本記事では、次の点を整理する。

代表的な「パスワードに関するサイバー攻撃」の分類と特徴
各攻撃が成立する前提条件（人間要因・技術要因）
システム設計者・開発者・利用者それぞれの立場で取り得る実践的な対策

2. パスワード攻撃が成立する背景

2.1 認証の三要素とパスワード

認証方式は一般に次の三要素で分類される。

知識要素：パスワード・PIN・秘密の質問など「知っていること」
所持要素：スマートフォン・トークン・IC カードなど「持っているもの」
生体要素：指紋・顔認証など「本人の身体的特徴」

パスワードは知識要素に分類され、実装が容易でコストも低いことから、多くのサービスで単一要素または多要素認証の一部として利用されている。

2.2 人間が作るパスワードの弱さ

ユーザが自分で考えるパスワードには、次のような傾向がある。

短い（8 文字未満など）
意味のある単語を含む（名前・誕生日・サービス名・password・123456 など）
複数サービスで使い回す
複雑なルール（例：記号必須）を嫌い、似たパターンを繰り返す（Password1!, Password2! …）

IPA や各種報告では、こうした性質のために、辞書攻撃や総当たり攻撃、流出パスワードを使うリスト型攻撃が成功しやすくなっていると指摘されている。(IPA)

2.3 技術的な前提条件

パスワード攻撃を成立させる技術的な要因として、主に次がある。

オンライン認証
- HTTP/HTTPS 経由でログインフォームに送信される ID／パスワード
- ログイン試行回数やレート制限が不十分な場合、総当たり攻撃やパスワードスプレー攻撃の余地が生じる
パスワード保存方式
- 平文保存、もしくは弱いハッシュ（ソルトなしの高速ハッシュ）で保存されている場合、侵害後のオフラインクラックが容易になる。(IT の学び)
流出情報の二次利用
- 侵害されたサービスから流出した ID・パスワードリストがダークウェブ等で流通し、他サービスへのクレデンシャルスタッフィング攻撃に再利用される。(NEC ソリューションイノベータ)

エンジニアの観点では、「ユーザの行動」と「システム仕様」の両方が攻撃成功率に影響することを押さえておく必要がある。

3. オンラインでのパスワード推測攻撃

オンライン攻撃とは、「サービスのログイン画面など、正規の認証インタフェースを経由して行う攻撃」である。
代表的なものとして、総当たり攻撃、辞書攻撃、パスワードスプレー攻撃がある。(でんこ社 Note)

3.1 総当たり攻撃（ブルートフォース攻撃）

総当たり攻撃（ブルートフォース攻撃） は、パスワードに使用可能な文字の全組み合わせを機械的に試行する方法である。

例：小文字英字のみ・長さ 4 の場合
- 組み合わせ数 = 26^4 = 456,976 通り
オンラインでの実行
- 1 秒に数十〜数百回程度の試行でも、制限が甘ければ短時間で多くの組み合わせを試せる
制限要素
- アカウントロックアウト、reCAPTCHA、IP ベースのレート制限などが適切なら、現実的な時間での成功は難しくなる

総当たり攻撃は、パスワードが短いほど成功しやすく、長くなるほど現実的でなくなる。

3.2 辞書攻撃（ディクショナリーアタック）

辞書攻撃 は、よく使われる単語や典型的なパターン（password, 123456, qwerty, 名前＋誕生日など）を集めたリスト（辞書）を用いて、順に試行する攻撃である。(でんこ社 Note)

特徴は次のとおり。

人間が好みがちなパターンに特化しているため、少ない試行回数で成功する可能性が高い
攻撃者は公開された「よく使われるパスワード一覧」や、過去の漏えいパスワードから辞書を構築する
オンライン環境だけでなく、後述するオフラインクラックにも利用される

3.3 パスワードスプレー攻撃（Password Spraying）

パスワードスプレー攻撃 は、総当たり攻撃の一種で、「多数のアカウントに対して、少数のよく使われるパスワードを試す」攻撃である。(SOMPO CYBER SECURITY)

従来の総当たり攻撃が「1 アカウントに対し多数のパスワードを試す」のに対し、パスワードスプレー攻撃は次のように動作する。

攻撃者が、会社のメールアドレスパターンなどから大量のアカウント候補を収集する
Password123、123456、Company2025! など、よく使われるパスワード候補を少数用意する
すべてのアカウントに対し、1 つ目のパスワードを試す
一定時間待機し、次のパスワードで同様の手順を繰り返す

この方法により、1 アカウントあたりの試行回数は少ないため、アカウントロックアウトや挙動監視に引っかかりにくい。

3.4 攻撃手法の比較

代表的なオンライン攻撃の特徴をまとめる。

攻撃名	主な対象	試行パターン	前提条件・弱点
総当たり攻撃（ブルートフォース）	単一アカウント	全組み合わせ	パスワードが短い、試行制限が緩い
辞書攻撃	単一アカウント	「よくあるパスワード」の集合	意味のある単語・典型的パターンを使用
パスワードスプレー攻撃	複数アカウント	少数のパスワード × 多数のアカウント	多数のアカウントが類似・弱いパスワード

オンライン攻撃の対策は、

ユーザ側：推測されにくいパスワードを選ぶ
サービス側：レート制限・アカウントロックアウト・多要素認証

の両面が必要になる。

4. オフラインでのパスワードクラック

オフライン攻撃とは、「サービスの認証 DB（パスワードハッシュなど）を盗み出した後、攻撃者が自分の環境で制限なくパスワードを解読する攻撃」である。(IT の学び)

4.1 パスワードハッシュとソルト

多くのシステムでは、パスワードの平文を保存せず、ハッシュ関数によるハッシュ値のみを保存する。

ハッシュ関数：入力から固定長の値を計算する関数で、一般に「一方向性（元の入力を復元できない）」を特徴とする
ソルト：パスワードごとにランダムな値を追加し、同じパスワードでも異なるハッシュ値になるようにする

ソルトを使わない場合、同じパスワードは常に同じハッシュ値になるため、「レインボーテーブル攻撃」が成立しやすくなる。

4.2 レインボーテーブル攻撃

レインボーテーブル攻撃 は、「パスワードとそのハッシュ値の対応表（レインボーテーブル）をあらかじめ作成し、盗んだハッシュ値と照合して元のパスワードを特定する攻撃」である。(IT の学び)

特徴：

攻撃前に時間をかけてテーブルを作っておくことで、攻撃時には高速に照合できる
ソルトなしのハッシュや、短いパスワードに対して特に有効
ソルトを十分にランダムかつ長く設定すると、実用的なレインボーテーブルの作成はほぼ不可能になる

4.3 オフライン総当たり・辞書攻撃

ハッシュ値さえ入手できれば、攻撃者はオンラインのレート制限やアカウントロックに縛られず、マシンパワーの許す限り総当たり攻撃・辞書攻撃を実行できる。

GPU を多数搭載したクラスターなどを使い、高速ハッシュ（SHA-1、MD5 等）であれば短時間で膨大な候補を試せる
専用ツール（例：hashcat など）を用い、辞書＋ルール（末尾に数字を付与、先頭を大文字にする等）を組み合わせ、現実的な時間で多数のパスワードを解読可能

このため、サービス側は次のような対策を取ることが推奨される。

高速ハッシュではなく、ストレッチング（計算コストを意図的に上げる）機能を持つハッシュ（例：bcrypt、scrypt、Argon2 など）
適切な長さのランダムソルト

4.4 図：オフラインクラックの流れ

このように、一度 DB が侵害されると、オンライン側でどれだけレート制限を厳しくしても、オフラインクラック自体は止められない。保存方式を「攻撃に強いもの」にすることが重要になる。

5. 認証情報窃取型の攻撃（フィッシング・キーロガー等）

パスワードを「推測して当てる」以外にも、「ユーザから直接盗み取る」タイプの攻撃がある。代表的なものとして、フィッシング攻撃、キーロガー、ソーシャルエンジニアリングなどが挙げられる。(でんこ社 Note)

5.1 フィッシング攻撃

フィッシング攻撃 は、実在する企業・サービスを装ったメールや SMS、偽サイトを用いて、ユーザに ID・パスワードを入力させる攻撃である。

特徴
- ログイン画面を本物そっくりに模倣
- SSL/TLS を利用してブラウザの鍵マークを表示し、安心感を与えるケースもある
- ネットバンキングや EC サイト、クラウドメールなどが標的になりやすい
成立条件
- ユーザが URL や証明書の確認を行わない
- メールの差出人やドメインを信じ込み、リンクをクリックしてしまう

多くの場合、技術的防御だけでは完全に防げないため、ユーザ教育と多要素認証の併用が重要になる。

5.2 キーロガー・マルウェアによる窃取

キーロガー は、PC やスマートフォンに侵入し、キーボード入力やクリップボードを監視してパスワードを盗むマルウェアである。

攻撃の流れ
- 添付ファイルや悪意あるサイトからマルウェアに感染
- ログインフォームへの入力が記録され、攻撃者のサーバに送信される
対策
- OS・ブラウザ・アプリの更新
- 不審なファイルの実行を避ける
- エンドポイントセキュリティ製品の導入

この種の攻撃は、パスワードの「強さ」に関係なく成功するため、端末の衛生管理と多要素認証が重要になる。

5.3 ソーシャルエンジニアリング

ソーシャルエンジニアリング は、人間の心理や組織の手続きを悪用して情報を聞き出す手法である。(でんこ社 Note)

例：

サポート担当者を装い、「本人確認」を口実にパスワードやワンタイムコードを聞き出す
「アカウントがロックされています」「至急対応が必要です」といった文言でユーザを焦らせ、冷静な判断を奪う

技術的な防御に加え、「サポートがパスワードを尋ねることはない」「ワンタイムパスワードを第三者に伝えない」といったルールを徹底する必要がある。

6. リスト型攻撃（パスワードリスト攻撃）とクレデンシャルスタッフィング

6.1 リスト型攻撃（パスワードリスト攻撃）

リスト型攻撃 とは、あるサービスから流出した ID・パスワードのリストを用いて、別のサービスに対して不正ログインを試みる攻撃である。
IPA やメディアの報告では、不正ログインの主要因のひとつとして整理されている。(IPA)

特徴
- 攻撃者は、自らパスワードを推測しない
- すでに漏えいした「本物の認証情報」を機械的に試すだけである
- ユーザが複数サービスでパスワードを使い回しているほど成功率が高い

6.2 クレデンシャルスタッフィング（Credential Stuffing）

クレデンシャルスタッフィング攻撃 は、盗まれたアカウント情報（ID とパスワードの組）を大量に使い、さまざまなサービスへ自動ログインを試行する攻撃である。(NEC ソリューションイノベータ)

攻撃の特徴
- ボットや専用ツールで大規模に自動化
- 一つのサービスで侵害された認証情報を、他の多数のサービスに対して再利用
- パスワードの再利用が一般的である現状に依存している
オンライン総当たり攻撃との違い
- 総当たり攻撃：パスワード候補を自動生成しながら試す
- クレデンシャルスタッフィング：すでに「正しい」可能性の高い組み合わせを試す

6.3 システム側から見た兆候

リスト型攻撃やクレデンシャルスタッフィングでは、次のような兆候がログに現れる。

世界中または広い IP レンジからの大量ログイン試行
多数のアカウントに対し、短時間でログイン試行が集中
ユーザの通常利用とは異なる時間帯・地域からのアクセス

WAF やボット対策サービス、多要素認証と組み合わせて検知・防御する必要がある。

7. 攻撃に強いパスワード設計と運用

ここでは、利用者とサービス提供者の両方の視点から、実務的な対策を整理する。
パスワードポリシに関しては、NIST SP 800-63B などのガイドラインや、それを解説する記事が更新され続けているため、定期的な確認が必要である。(sakimura.org)

7.1 ユーザ側：強いパスワードと多要素認証

7.1.1 長く・覚えやすいパスフレーズ

近年のガイドラインでは、「記号を強制するよりも、長さを重視したパスフレーズ」を推奨する傾向が強い。(sakimura.org)

例：

NG 例
- P@ssw0rd!（典型的で辞書に載りやすい）
良い例（パスフレーズ）
- correct-horse-battery-staple のように、複数の単語を組み合わせた 15 文字以上のフレーズ
- 日本語環境でも、「意味のある文章」をローマ字＋記号で表現するなどの工夫

※ サービス側のポリシによっては使用できる文字・長さに制限があるため、それに従う必要がある。

7.1.2 サービスごとに異なるパスワード

リスト型攻撃・クレデンシャルスタッフィングを避ける上で、パスワードの使い回し禁止は極めて重要である。(サイバーセキュリティポータル)

実際には、人間がすべてのサービスで異なる長いパスワードを記憶するのは現実的ではないため、次のような運用が現実解となる。

パスワードマネージャの利用（例：1Password など）(インプレスブックス)
パスワードマネージャの「生成機能」でランダムな長いパスワードを作成し、サービスごとに保存

7.1.3 多要素認証（MFA）の活用

多要素認証（Multi-Factor Authentication, MFA） は、パスワードに加え、ワンタイムパスワードや生体認証などを組み合わせる方式である。

代表例
- TOTP アプリ（Google Authenticator, Authy 等）
- SMS によるワンタイムコード
- FIDO2 セキュリティキー・プラットフォーム認証（端末内の生体認証等）

警察庁や公的機関も、パスワードに加え二要素・多要素認証の利用を推奨している。(警察庁)

MFA を有効にすると、

パスワードが漏えいしても、ワンタイムコードや物理トークンがなければログインできない
フィッシングやクレデンシャルスタッフィングの成功率を大きく下げられる

7.2 サービス側：設計・実装のポイント

7.2.1 パスワード保存方式

サービス側が実装で押さえるべきポイントを、擬似コードを交えて整理する。

平文保存は禁止
高速ハッシュ（MD5、SHA-1 等）単体での保存も望ましくない
ソルト付き・計算コスト調整可能なハッシュ（bcrypt、Argon2 等）を利用する

擬似コード例（概念レベル、実装には専用ライブラリを利用）：

import bcrypt

def hash_password(plain_password: str) -> bytes:
    # ランダムソルト + コスト付きハッシュ（bcrypt）
    return bcrypt.hashpw(plain_password.encode("utf-8"), bcrypt.gensalt())

def verify_password(plain_password: str, stored_hash: bytes) -> bool:
    return bcrypt.checkpw(plain_password.encode("utf-8"), stored_hash)

※ 実際のパラメータ設定（コスト、メモリ使用量など）は、システム規模・性能要件を踏まえる必要がある。

7.2.2 認証まわりのレート制限とロックアウト

オンライン攻撃（総当たり攻撃・辞書攻撃・パスワードスプレー攻撃）に対しては、次の制御が有効である。(カスペルスキー)

単一アカウントに対するログイン失敗回数の制限（例：5 回連続失敗で一時ロック）
IP アドレスごとのレート制限
ログインページへの CAPTCHA 導入
地理的に異常なログインに対する追加認証（プッシュ通知、追加質問など）

7.2.3 クレデンシャルスタッフィング対策

クレデンシャルスタッフィング・ボット攻撃向けには、次のような対策が有効である。(NEC ソリューションイノベータ)

ボット検知・ WAF・CDN の活用
異常なトラフィックパターン（短時間で多数のアカウントにアクセスなど）の検知
既知の漏えいパスワードリストとの照合（ユーザ登録・変更時に弾く）

また、パスワード変更時にも「過去に漏えいしたパスワードを新たに設定させない」チェックを行うケースが増えている。

7.3 パスワードポリシと実効性

従来、「定期的なパスワード変更」が推奨されてきたが、NIST のガイドラインなどでは「定期変更の強制は推奨しない」との方針が示されている。(トレンドマイクロセキュリティブログ)

理由としては、

頻繁な変更を強制すると、ユーザがパターン化した弱いパスワードを選びやすい
メモ書きや再利用など、かえってリスクを高める行動を誘発する

が挙げられる。

実務上は、

強制変更よりも「侵害の兆候があった場合の即時変更」
初期パスワード・リセットコードの扱いの厳格化
パスワードマネージャや MFA の利用促進

を重視する方向にシフトしつつある。

8. まとめ：エンジニアとして押さえるべきポイント

パスワード攻撃は多様化している
- 総当たり攻撃・辞書攻撃・パスワードスプレー攻撃・レインボーテーブル攻撃・フィッシング・リスト型攻撃・クレデンシャルスタッフィングなど、多数の手法が存在する。
ユーザ行動とシステム設計の両方が成功率を左右する
- 短く・使い回されたパスワードは、どの攻撃に対しても弱い。
- 保存方式やレート制限が甘いシステムは、侵害後のオフラインクラックに弱い。
オンライン攻撃にはレート制限・ロックアウト・MFA が有効
- 1 アカウントあたり・IP あたりの試行回数を制御し、異常なパターンを検知する。
DB 侵害後の被害を抑えるには、保存方式が決定的に重要
- ソルト付き・ストレッチング可能なハッシュ（bcrypt、Argon2 等）を用い、平文保存や高速ハッシュ単体は避ける。
クレデンシャルスタッフィングには「使い回さない」ことが最大の防御
- サービス側は、ボット／WAF・漏えいパスワードチェック・MFA で対策。
- ユーザ側は、パスワードマネージャでサービスごとに異なるパスワードを管理。
パスワードポリシは「長さ＋使い回し禁止＋ MFA 優先」にシフト
- 記号の強制や短い有効期限より、長く覚えやすいパスフレーズと MFA を優先する方向にガイドラインが変化しつつある。

これらを踏まえ、システム設計・コード実装・運用ポリシ・ユーザ教育を組み合わせることが、現実的に「攻撃に強い認証」を構築する鍵になる。
個別システムに適したパラメータ（ハッシュアルゴリズム・コスト設定・レート制限値など）については、最新のガイドラインと専門家の知見を参照しながら決定することが望ましい。

A. 参考サイト

「インターネットサービスへの不正ログインによる被害が増加中」(IPA)
「SNS やショッピングサイトの不正ログインに関する相談が増加中」(INTERNET Watch)
「パスワード取得攻撃とその対策について解説」(でんこ社 Note)
「パスワードクラックを整理してみよう！（辞書攻撃、ブルートフォース攻撃、レインボー攻撃）」(IT の学び)
「パスワードスプレー攻撃とは」(SOMPO CYBER SECURITY)
「クレデンシャルスタッフィング攻撃 (Credential Stuffing)」(NEC ソリューションイノベータ)
「結局、パスワードの定期的な変更は必要なのか？～ NIST のガイドライン草案から考える～」(トレンドマイクロセキュリティブログ)