パスワードはどう守られているのか

🎬 アニメーション『ログインの裏側』の ② のところです！

入力したパスワードは、次の形でサイトへ届きます:

1. フォームの内容は HTTPSのPOSTリクエスト※1 のボディに載る（URLには載せない——履歴やログに残るため）
2. 通信全体が TLS※2 で暗号化されるので、パスワード自体はこの区間では生のまま
3. つまり「経路の守りはTLS任せ、保存の守りはハッシュ任せ」という分業になっている

登場人物メモ（※の説明）:

• ※1 POSTリクエスト — 送信内容を本文（ボディ）に載せるHTTPの依頼形式。URLに載るGETと違い、記録に残りにくい
• ※2 TLS — 通信の暗号化層。『URLを打ってから表示されるまで』の②で出てきた、あの鍵マークの正体

⚠️ イレギュラー（うまくいかないとき）:

• HTTPのままのサイト — 経路の守りがないので、パスワードが平文で流れる。ブラウザが「保護されていない通信」と警告するのはこれ
• フィッシング — 経路も保存も完璧でも、届け先が偽物なら全て無意味。技術の外側にある最大の穴

🎬 アニメーション『ログインの裏側』の ③ のところです！

「すりつぶし」の正式名は暗号学的ハッシュ関数です。ただし、どのハッシュ関数でもいいわけではありません:

1. 届いたパスワードに、まずソルト※1 という利用者ごとのランダムな値を混ぜる
2. 混ぜたものをパスワード専用のハッシュ関数※2（bcrypt / scrypt / Argon2）にかける
3. 出てきたハッシュ値とソルトをセットでDBに保存する（ソルトは隠さなくてよい）

なぜ普通のハッシュ（SHA-256など）ではだめなのか——速すぎるからです。速いハッシュはGPUで秒間数十億回試せます。パスワード用の関数は、わざと遅く設計されていて（さらに scrypt / Argon2 はメモリも大量に要求する＝メモリハード※3）、総当たりの効率を殺します。

登場人物メモ（※の説明）:

• ※1 ソルト — 利用者ごとに違うランダム値。同じパスワードでも違うハッシュになるので、「よくあるパスワード→ハッシュ」の事前計算表（レインボーテーブル）が無力化する
• ※2 bcrypt / scrypt / Argon2 — パスワード保存専用のハッシュ関数ファミリー。計算コストをパラメータで引き上げられる。このアプリも scrypt を使っている
• ※3 メモリハード — 計算に大量のメモリを要求する性質。GPUの並列攻撃はメモリがボトルネックになり失速する（scrypt/Argon2が該当。bcryptはメモリハードではなくCPUコスト型）

⚠️ イレギュラー（ここが甘いと事故になる）:

• ソルトなしの高速ハッシュ（MD5等）で保存 — 過去の大規模流出事件の定番パターン。レインボーテーブルで一瞬で大半が割れる
• 「パスワードを忘れた」で元のパスワードが届く — ハッシュ保存ならあり得ない挙動。平文保存の動かぬ証拠

🎬 アニメーション『ログインの裏側』の ④〜⑤ のところです！

照合そのものは「ソルトを付けてハッシュ化→保存値と比較」だけですが、実戦はここが攻防の最前線です:

1. 攻撃側の第一手は総当たり——対策は試行回数制限（レートリミット）とアカウントロック
2. 第二手がクレデンシャルスタッフィング※1——他所で漏れたID・パスワードのセットを機械的に試す。複雑なパスワードでも使い回していれば無力
3. 守り側は失敗応答を「IDかパスワードが違います」に統一して、IDの存在を教えない（ユーザー列挙防止）

登場人物メモ（※の説明）:

• ※1 クレデンシャルスタッフィング — 漏えいした認証情報リストの流し込み攻撃。成功率は数%でも、リストが数億件あるので成立してしまう

⚠️ イレギュラー（攻防の細部）:

• ロックの悪用 — わざと他人のIDで失敗を繰り返し、ロックさせる嫌がらせ（DoS）もある。だからロックは時限式にするなど設計に工夫がいる
• 応答時間の差 — 「IDが存在する場合だけ処理が遅い」といった挙動の差からIDの存在が漏れることもある

🎬 アニメーション『ログインの裏側』の ⑥ のところです！

「しばらく有効な会員証」の正式名はセッション※1 です:

1. サーバはランダムで推測不能なセッションIDを発行し、DB側に「誰のものか」を記録する
2. ブラウザにはCookie※2 として渡す。以降のリクエストに自動で添付される
3. Cookieには HttpOnly / Secure※3 という守りの属性を付ける
4. ログアウトや「全端末からサインアウト」は、DB側のセッションを消すことで即時に効く

さらに上の守りが2要素認証（2FA）※4——パスワード（知識）に加えて、スマホ（所持）などの2つ目を要求します。パスワードが漏れた後の最後の砦です。

登場人物メモ（※の説明）:

• ※1 セッション — ログイン状態の実体。IDの当てずっぽうが効かないよう、十分長いランダム値にする
• ※2 Cookie — ブラウザがサイトごとに保管し、自動で送り返す小さなメモ。会員証の入れ物
• ※3 HttpOnly / Secure — 「ページ内のプログラム(JS)から読めない」「暗号化経路でしか送らない」の2属性。会員証の盗難対策
• ※4 2要素認証（2FA） — 知識（パスワード）+ 所持（スマホ・鍵）など、性質の違う証明を重ねる方式

⚠️ イレギュラー（会員証が狙われるとき）:

• セッションハイジャック — 会員証そのものを盗めばパスワード不要でなりすませる。HttpOnly・Secure・短い有効期限はこのための守り
• 公共PCでのログアウト忘れ — 会員証を置きっぱなしにするのと同じ。「全端末からサインアウト」機能はこの回収に使う

まとめ——守りは4層です: 経路（TLS）/ 保存（ソルト+遅いハッシュ）/ 照合（回数制限と列挙防止）/ 会員証（セッション属性と2FA）。流出ニュースを見たら「どの層が破られたのか」を考える。それがこのユニットの読み方です。