はじめに

「Basic認証って簡単だし、HTTPSを使えば安全でしょ？」

もしそう思っているなら、今すぐその考えを改めてください。

2025年現在、Basic認証は極めて危険な認証方式として、Microsoft、Google、OWASPなどの主要な技術機関が廃止を推奨しています。

この記事では、最近たぶん、もう忘れてしまったのかもしれない、Basic認証って言葉が久しぶりにでてきてあちらこちら実運用で使われていたので、最新の記事でも書くか！とおもって調査とともに執筆してみました。絵はAIで。

なぜBasic認証が危険なのか、具体例とともに詳しく解説します。

📊 まず現実を見てみよう

業界の動向

Microsoft: 2023年3月、Exchange OnlineでBasic認証を完全廃止
Google: 段階的にBasic認証サポートを終了中
OWASP: Basic認証を非推奨認証方式として分類

🔍 Basic認証とは何か？

Basic認証は、HTTPで定義される最も単純な認証方式です。

仕組み

ユーザーがアクセスを試みる
ブラウザにダイアログが表示
ユーザー名とパスワードを入力
Base64でエンコードして送信
サーバーが認証情報を確認

GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

「あれ？Base64って暗号化じゃないの？」

大きな勘違いです！

Base64は単なるエンコードであり、暗号化ではありません。

# 簡単にデコードできます
echo "dXNlcm5hbWU6cGFzc3dvcmQ=" | base64 -d
# 結果: username:password

⚠️ Basic認証の5つの致命的な問題

1. 🎯 毎回認証情報を送信

Basic認証では、すべてのリクエストで認証情報を送信します。

# 1回目のリクエスト
GET /page1 HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# 2回目のリクエスト  
GET /page2 HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

# 100回目のリクエスト...
GET /page100 HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

つまり、攻撃機会が100倍、1000倍に増加します。

2. 🚪 ログアウト機能がない

Basic認証にはログアウト機能が存在しません。

ブラウザを閉じるまで認証状態が継続
共用PCでの離席時に危険
セッション管理ができない

3. 📱 パケットキャプチャで丸見え

HTTP通信の場合（最悪）

# Wiresharkで簡単に確認可能
GET /admin HTTP/1.1
Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM=

# デコード結果
admin:password123

HTTPS通信でも問題あり

企業プロキシでSSL復号化されている場合
証明書エラーを無視してしまった場合
ブラウザの開発者ツールで確認可能

4. 🎲 ブルートフォース攻撃に脆弱

# 攻撃者のスクリプト例（概念的なもの）
import base64
import requests

passwords = ["password", "123456", "admin", "test"]
for pwd in passwords:
    auth = base64.b64encode(f"admin:{pwd}".encode()).decode()
    response = requests.get("https://target.com/admin", 
                          headers={"Authorization": f"Basic {auth}"})
    if response.status_code == 200:
        print(f"パスワード発見: {pwd}")

5. 🕷️ 中間者攻撃（MITM）に弱い

💥 実際の攻撃シナリオ

シナリオ1: 社内ネットワーク

1. 社内WiFiでBasic認証を使用
2. 悪意のある社員がWiresharkを起動
3. 数分でパスワード一覧を収集
4. 管理者権限で不正アクセス

シナリオ2: 公共WiFi

1. カフェでBasic認証サイトにアクセス
2. 攻撃者が偽アクセスポイントを設置
3. 証明書警告を「OK」してしまう
4. 認証情報が攻撃者に送信される

シナリオ3: 企業環境

1. SSL復号化プロキシを使用している企業
2. プロキシログにBasic認証情報が記録
3. 内部不正によりログファイルにアクセス
4. 大量のアカウント情報が漏洩

🛡️ 現代的な認証方式への移行

OAuth 2.0 / OpenID Connect

# 認証情報ではなく、トークンを送信
GET /api/users HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

メリット:

パスワードを直接送信しない
トークンに有効期限がある
トークンの取り消しが可能
スコープによる権限制御

JWT（JSON Web Token）

{
  "iss": "https://auth.example.com",
  "exp": 1640995200,
  "sub": "user123",
  "scope": ["read", "write"]
}

メリット:

自己完結型トークン
署名による改ざん検出
分散システムに適している

Form認証 + セッション管理

# 最初の認証のみパスワード送信
POST /login HTTP/1.1
Content-Type: application/json
{
  "username": "user",
  "password": "password"
}

# 以降はセッションIDで認証
GET /protected HTTP/1.1
Cookie: session_id=abc123...

メリット:

パスワードは初回のみ送信
ログアウト機能あり
セッション管理可能

📋 移行のためのチェックリスト

🔍 現状調査

Basic認証を使用しているシステムの特定
影響範囲の調査（内部システム、外部API等）
利用ユーザー数の把握

🏗️ 移行計画

認証方式の選択（OAuth 2.0, JWT, Form認証等）
移行スケジュールの策定
テスト環境での検証
ユーザー向け説明資料の作成

🚀 実装・移行

新認証システムの実装
段階的な移行（パイロット → 全面移行）
Basic認証の無効化
セキュリティ監査の実施

🎯 まとめ

Basic認証が危険な理由（再確認）

Base64は暗号化ではない → 簡単にデコード可能
毎回認証情報を送信 → 攻撃機会が無限に増加
ログアウト機能がない → セッション管理不可
パケットキャプチャで丸見え → ネットワーク監視で即座に発見
業界標準から逸脱 → Microsoft、Googleも廃止済み

今すぐやるべきこと

Basic認証の使用状況を調査
移行計画の策定
現代的な認証方式への移行
セキュリティ監査の実施

🔗 参考資料

「セキュリティは一度作ったら終わりではない。常に進化し続けるものです。」

Basic認証を使い続けることは、玄関の鍵を開けっ放しにして外出するようなものです。

今すぐ、現代的で安全な認証方式への移行を検討してください。

あなたのシステムとユーザーを守るために。