パスワードセキュリティの現状（2026年）
2026年現在、パスワードを取り巻く状況は大きく変化しています。パスキー（FIDO2/WebAuthn）が主要なプラットフォームで標準サポートされ、パスワードレス認証が現実的な選択肢になりました。しかし、パスワードが完全に消えるにはまだ時間がかかります。レガシーシステム、B2B連携、特定のユースケースでは依然としてパスワードが必要です。
攻撃側の能力も進化しています。RTX 5090のようなGPUはSHA-256を毎秒数百億回計算でき、クラウドGPUクラスターを使えばさらに桁違いの処理能力が得られます。2024年に公開されたRockYou2024データセットには約100億件のユニークなパスワードが含まれており、辞書攻撃の精度は年々向上しています。
防御の核心は変わっていません。十分なエントロピー（ランダム性）を持つパスワードを生成し、適切なハッシュ関数（遅い関数）で保存し、可能な場合は多要素認証を追加する。このガイドでは、各要素を数学的に理解し、2026年の技術水準に合った実装指針を提供します。
エントロピーとは何か：パスワード強度の数学
エントロピーはパスワードのランダム性をビット単位で測定したものです。計算式は E = log2(C^L) で、Cは使用する文字種の数、Lはパスワードの長さです。例えば、小文字のみ（26文字）で8文字のパスワードは log2(26^8) ≈ 37.6ビットのエントロピーを持ちます。英大文字小文字+数字+記号（95文字）で12文字なら log2(95^12) ≈ 78.8ビットです。
重要な前提条件：この計算はパスワードが完全にランダムに生成される場合のみ有効です。人間が「P@ssw0rd123!」を選んだ場合、理論上は95^12の組み合わせがありますが、実効エントロピーはほぼゼロです（辞書攻撃で瞬時に破られる）。エントロピーは生成方法の予測不能性を測定するもので、結果の見た目の複雑さではありません。
2026年の推奨値：オフライン攻撃に耐えるにはbcrypt（cost 12）と組み合わせて最低64ビット、理想的には80ビット以上のエントロピーが必要です。SHA-256で直接ハッシュする（やってはいけない）場合は128ビット以上必要です。当サイトのpassword-generatorツールは指定されたエントロピーを保証するランダムパスワードを生成します。
パスフレーズのエントロピー：「correct horse battery staple」のような4単語のパスフレーズは、7,776語の辞書（Diceware）から選ぶ場合 log2(7776^4) ≈ 51.7ビットです。6単語で約77.5ビット。パスフレーズは覚えやすいが、ランダムな文字列より長くなるため入力が面倒です。用途に応じて使い分けましょう。
// エントロピーの計算
function calculateEntropy(charset, length) {
return Math.log2(Math.pow(charset, length));
}
// 各パターンのエントロピー
calculateEntropy(26, 8); // 小文字8文字: 37.6ビット（弱い）
calculateEntropy(62, 12); // 英数字12文字: 71.5ビット（良い）
calculateEntropy(95, 16); // 全ASCII記号16文字: 105.1ビット（非常に強い）
calculateEntropy(7776, 4); // Diceware 4単語: 51.7ビット（やや弱い）
calculateEntropy(7776, 6); // Diceware 6単語: 77.5ビット（良い）
// ブルートフォースに必要な時間の推定
function crackTime(entropyBits, hashesPerSecond) {
const combinations = Math.pow(2, entropyBits);
const seconds = combinations / hashesPerSecond / 2; // 平均で半分の試行
return seconds;
}
// bcrypt cost=12: 約4ハッシュ/秒（GPU 1台）
crackTime(64, 4); // 約7300万年
// SHA-256: 約220億ハッシュ/秒（RTX 5090）
crackTime(64, 22e9); // 約13年（不十分！）NISTガイドラインの要点（800-63B）
NIST SP 800-63B（2024年改訂版）は、多くの組織が従来採用してきたパスワードポリシーを根本的に見直しています。主な変更点：複雑性要件（大文字必須、記号必須など）の撤廃を推奨、定期的な変更の強制を非推奨、最低8文字（理想は15文字以上）を要求、最大64文字以上を許容することを義務付け。
複雑性要件を撤廃する理由は実証的です。「大文字1つ、数字1つ、記号1つ」という要件が課されると、ユーザーの大半は「Password1!」「Summer2026!」のようなパターンに落ち着きます。これは形式的には要件を満たしますが、攻撃者のルールベース辞書には真っ先に含まれるパターンです。代わりに長さを優先する方がエントロピーは高くなります。
漏洩パスワードリストとの照合は必須とされています。ユーザーが新しいパスワードを設定する際、Have I Been Pwnedなどの漏洩データベースに存在しないことを確認します。k-anonymityモデルを使えば、パスワード自体をAPIに送信せずに照合できます（SHA-1ハッシュの先頭5文字のみ送信し、候補リストをローカルで照合）。
パスワードの表示オプション、ペースト許可、パスワードマネージャーの互換性確保もNISTの推奨事項です。入力フィールドでのペースト禁止は、パスワードマネージャーの利用を妨げるため、セキュリティを低下させます。ユーザーが強力な一意のパスワードを使うことを促進するあらゆる措置が推奨されます。
パスワードハッシュ：bcrypt vs Argon2id
パスワードの保存にはSHA-256やMD5のような汎用ハッシュ関数を絶対に使わないでください。これらは高速であることが設計目標であり、GPUで毎秒数百億回計算できます。パスワード専用のハッシュ関数は意図的に遅く設計されており、ブルートフォース攻撃のコストを天文学的に引き上げます。
bcrypt（1999年〜）は最も広く使われているパスワードハッシュです。costパラメータ（2のべき乗回数のイテレーション）で計算コストを調整できます。2026年の推奨値はcost=12（1回のハッシュに約250ms）です。利点：実績が長い、あらゆる言語にライブラリがある、理解しやすい。欠点：72バイトの入力制限、メモリハード性が限定的（GPUでの並列攻撃に対してArgon2idほど強くない）。
Argon2id（2015年、Password Hashing Competition優勝）は現時点のベストプラクティスです。CPU時間、メモリ使用量、並列度の3つのパラメータを独立して調整できます。メモリハード性により、GPU/ASIC攻撃に対してbcryptよりも高い耐性を持ちます。2026年の推奨パラメータ：メモリ64 MB以上、イテレーション3回以上、並列度1。OWASPはArgon2idをファーストチョイスとして推奨しています。
移行戦略：既存のbcryptハッシュからArgon2idに移行する場合、ユーザーの次回ログイン時に再ハッシュする方法が一般的です。既存のbcryptハッシュをArgon2idでラップ（Argon2id(bcrypt(password))）する方法もありますが、実装の複雑さが増します。新規プロジェクトなら迷わずArgon2idを選んでください。
// Node.jsでのパスワードハッシュ実装例
// bcrypt（広くサポートされている）
import bcrypt from 'bcrypt';
const saltRounds = 12; // 2026年の推奨値
const hash = await bcrypt.hash(password, saltRounds);
const isValid = await bcrypt.compare(inputPassword, hash);
// Argon2id（推奨）
import argon2 from 'argon2';
const hash = await argon2.hash(password, {
type: argon2.argon2id,
memoryCost: 65536, // 64 MB
timeCost: 3, // イテレーション回数
parallelism: 1, // 並列度
});
const isValid = await argon2.verify(hash, inputPassword);
// ❌ 絶対にやってはいけない例
import crypto from 'crypto';
// SHA-256でパスワードをハッシュしてはいけない
const badHash = crypto.createHash('sha256').update(password).digest('hex');
// saltなしのMD5は論外
const terribleHash = crypto.createHash('md5').update(password).digest('hex');パスワード生成のベストプラクティス
安全なパスワード生成の鉄則は、暗号学的に安全な乱数生成器（CSPRNG）を使うことです。Math.random()は予測可能であり、セキュリティ目的には使えません。ブラウザではcrypto.getRandomValues()、Node.jsではcrypto.randomBytes()を使用してください。
文字種の選択について：全ASCII印字可能文字（95種）を使えば同じ長さで最大エントロピーが得られますが、一部のシステムは特定の記号を受け付けません。実務的には英大文字小文字+数字+限定的な記号（!@#$%^&*）の組み合わせが互換性と強度のバランスが良いです。16文字以上あれば記号なしの英数字（62種）でも十分なエントロピーを達成できます。
パスワードマネージャーとの連携を前提に設計しましょう。ユーザーが覚える必要があるのはマスターパスワード1つだけです。個々のサービスのパスワードは完全にランダムで長い（20文字以上）ものを生成し、マネージャーに保存します。この前提では「覚えやすさ」は設計要件から外れます。
パスフレーズを使う場合はDicewareリスト（7,776語）または同等の単語リストからランダムに選択してください。間違っても自分で文を考えてはいけません。人間が選ぶフレーズは予測可能性が高く、実効エントロピーは計算値よりはるかに低くなります。4語のDicewareフレーズでも、パスワードマネージャーのマスターパスワードには不十分です。最低6語を推奨します。
多要素認証（MFA）の重要性
どれほど強力なパスワードでも、フィッシング、キーロガー、サーバー側の漏洩には無力です。多要素認証は「知っているもの」（パスワード）に加えて「持っているもの」（デバイス）や「本人であること」（生体認証）を要求し、単一の攻撃ベクターでのアカウント侵害を防ぎます。
TOTP（Time-based One-Time Password）はGoogle AuthenticatorやAuthyなどで広く使われています。実装はRFC 6238に基づき、共有シークレットと現在時刻からHMAC-SHA1で6桁のコードを生成します。30秒ごとに新しいコードが生成されるため、傍受されても有効期間が限定的です。ただし、フィッシングサイトがリアルタイムで中継する場合は無効です。
FIDO2/WebAuthn（パスキー）は2026年時点で最もフィッシング耐性が高い認証方式です。公開鍵暗号を使い、認証情報はオリジン（ドメイン）にバインドされるため、フィッシングサイトでは機能しません。Apple、Google、Microsoftのすべてがパスキーのクロスデバイス同期をサポートしています。新規サービスではパスキーの導入を検討してください。
SMS認証は他に選択肢がない場合のフォールバックとしてのみ使ってください。SIMスワップ攻撃、SS7脆弱性、SMSの傍受リスクがあるためです。NISTはSMSをout-of-band認証として「restricted」（制限付き）に分類しています。TOTPまたはFIDO2を優先し、SMSは最後の手段としてください。
パスワードポリシーの実装ガイド
サーバーサイドの実装チェックリスト：1）パスワードの最低長さを12文字（NISTは8文字だが12を推奨）に設定。2）最大長を少なくとも64文字に設定（bcryptの72バイト制限に注意）。3）漏洩パスワードリストとの照合を実装。4）パスワードハッシュにArgon2idまたはbcrypt（cost 12以上）を使用。5）レート制限とアカウントロックアウトを実装。
クライアントサイドでのバリデーション：リアルタイムの強度メーターを表示しますが、ゲーミフィケーションに走らないでください。zxcvbnライブラリ（Dropbox製）はパターンベースの強度推定を行い、辞書攻撃への耐性も評価します。ただし最終的なバリデーションは常にサーバーサイドで行ってください。
アカウントロックアウトとレート制限：5回の失敗で15分のロックアウトは一般的ですが、ユーザーに対するDoS攻撃の手段にもなりえます。代替として、失敗回数に応じて指数関数的に遅延を追加する（1回目は即座、2回目は1秒、3回目は2秒…）アプローチがあります。IPベースのレート制限とアカウントベースのレート制限を組み合わせてください。
パスワードリセットフロー：リセットトークンは最低128ビットのエントロピーを持つランダム値を使い、有効期限は1時間以内に設定。使用済みトークンは即座に無効化。メールアドレスの存在確認を漏らさない（「メールが見つかりませんでした」と表示せず、常に「メールを送信しました」と表示）。これはユーザー列挙攻撃の防止です。
パスキーへの移行と今後の展望
パスキー（Passkeys）はFIDO2/WebAuthnの消費者向けブランディングで、パスワードを完全に置き換えることを目指しています。技術的には公開鍵暗号ペアがデバイスに保存され、認証時に秘密鍵でチャレンジに署名します。フィッシング耐性、サーバー側に共有秘密を保持しない、ユーザーが何も覚える必要がない、という3つの利点があります。
2026年の導入状況：Google、Apple、MicrosoftがOSレベルでパスキーをサポートし、iCloudキーチェーンやGoogleパスワードマネージャーでクロスデバイス同期が可能です。多くのWebサービス（GitHub、Google、PayPalなど）がパスキーログインを提供しています。ただし、すべてのユーザーが対応デバイスを持っているわけではなく、レガシーブラウザのサポートも必要です。
段階的な移行戦略：1）パスキーをオプションの追加認証方法として導入。2）パスキー登録済みユーザーに対してパスキーをデフォルトの認証方法にする。3）新規ユーザーにはパスキーをプライマリ、パスワードをフォールバックとして設定。4）最終的にパスワードレスに移行（パスワードの無効化オプションを提供）。
開発者として今できること：WebAuthn APIの実装を開始し、SimpleWebAuthnのようなライブラリで複雑さを抽象化する。既存のパスワード認証と並行してパスキーを追加する。ユーザーのパスキー登録率を計測し、移行の進捗を追跡する。パスワードが完全に不要になる日はまだ先ですが、その準備を始める時期は今です。