6-1. 認証・認可・パスワードハッシュ・HTTPS

このセクションで学ぶこと

認証と認可の違い
ログイン後に「誰か」を持ち越す方法
パスワードを平文保存してはいけない理由
パスワードハッシュとソルトの役割
HTTPS が通信で守っているもの
これらを実務でどう組み合わせるか

第2章では、HTTP・Cookie・401 / 403 を「Web の仕組み」として見た。
この章ではそこから一歩進み、なぜ安全に扱わないと危険なのか を理解する。

1. なぜセキュリティを最初に学ぶのか

業務システムでは、次のような情報や操作を扱うことが多い。

顧客情報
注文や支払い
社内資料
管理者だけができる設定変更

つまりシステムには、常に次の問いがある。

1. この人は誰か
2. この操作を許してよいか
3. 途中で盗み見や改ざんをされないか
4. 万一データベースが漏れても被害を広げにくいか

この4つに対応する基本部品が、

認証：この人は誰か
認可：その操作を許してよいか
HTTPS：通信経路を守る
パスワードハッシュ：漏えい時の被害を減らす

である。

たとえば書籍管理アプリを考える。

利用者
  │  ログイン情報を送る
  ▼
サーバー
  │  本人確認をする
  │  権限を確認する
  ▼
データベース

このとき、

認証が弱いと、他人になりすませる
認可が弱いと、一般ユーザーが管理操作できる
HTTPS がないと、通信を盗み見られる
パスワードを平文保存すると、漏えい時に即座に悪用される

という問題が起きうる。

セキュリティは「あとで追加する飾り」ではなく、最初から設計へ入れておくべき前提条件である。

2. 認証と認可は何が違うか

似た言葉に見えるが、役割は違う。

用語	何を確かめるか	典型例
認証（Authentication）	あなたは誰か	ログインしているか
認可（Authorization）	その操作を許してよいか	管理者だけが削除できるか

例で見る

ログイン画面
  ↓
ID / パスワードを確認
  ↓
「Sato さん本人だ」と分かる
  ↓
認証成功

しかし、本人確認ができても、すべての操作を許してよいとは限らない。

Sato さんはログイン済み
  ↓
本の一覧を見る        → 許可
本を削除する          → 管理者なら許可
社員情報を全件取得する → 一般ユーザーなら不許可

`401` と `403`

Web API では、認証と認可の違いがステータスコードにも表れる。

コード	意味	状態
`401 Unauthorized`	認証が必要	まず「誰か」を示してほしい
`403 Forbidden`	認可されない	誰かは分かるが、その操作は許可できない

流れで見るとこうなる。

リクエスト受信
   ↓
認証できるか?
   ├─ できない → 401
   ↓
認可できるか?
   ├─ できない → 403
   ↓
処理を実行

ここで重要なのは、ログイン済み = 何でもできる、ではない という点である。

3. ログイン後はどう状態を持ち越すのか

HTTP は基本的にステートレスであり、1回ごとのリクエストだけでは前回の状態を自動で覚えない。
そのため、ログイン成功後は「この人は認証済みだ」という情報を次のリクエストへ渡す必要がある。

典型的な流れは次のようになる。

ブラウザ
  │  ID / パスワードを HTTPS で送る
  ▼
サーバー
  │  保存済みハッシュと照合する
  ▼
認証成功
  │  セッションIDやトークンを返す
  ▼
以後のリクエストでその情報を送る

よくある持ち越し方法

方式	どう持ち越すか
セッションCookie	ブラウザが Cookie を自動送信し、サーバー側で状態を管理する
トークン	クライアントが `Authorization` ヘッダーなどでトークンを送る

どちらも本質は、毎回パスワードを送り直さずに、認証済みであることを示す仕組み である。

セッションCookieを使う場合、次の属性がよく出てくる。

属性	役割
`Secure`	HTTPS 通信のときだけ送る
`HttpOnly`	ブラウザの JavaScript からアクセスできなくする

つまり、ログイン処理は「認証に成功したら終わり」ではない。
認証済み状態をどう安全に持ち運ぶか まで設計する必要がある。

4. パスワードをそのまま保存してはいけない理由

最も避けるべきなのは、パスワードの平文保存である。

たとえば次のようなテーブルを考える。

users
+----+--------+---------------+
| id | name   | password      |
+----+--------+---------------+
|  1 | Sato   | lesson-pass   |
|  2 | Ito    | abc12345      |
+----+--------+---------------+

この状態でデータベースが漏れると、攻撃者はすぐにそのままログインを試せる。

平文保存が危険な理由は次の通りである。

データベース漏えい時に、即座に中身を読める
運用者や開発者が不用意に閲覧できてしまう
利用者が他サービスで同じパスワードを使っていると、被害が連鎖しやすい

「暗号化しておけばよい」では足りない理由

ここで初学者が混同しやすいのが、暗号化 と ハッシュ の違いである。

方法	元に戻せるか	主な用途
暗号化	鍵があれば戻せる	内容を安全に保管・送信する
ハッシュ	基本的に元へ戻さない前提	一致確認に使う

パスワード保存では、サーバーは「元の文字列を思い出す」必要はない。
必要なのは、入力されたパスワードが正しいものと一致するか を確認することだけである。

そのためパスワードは「読める形で持つ」のではなく、照合だけできる形で持つ べきである。

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

ハッシュとは何か

ハッシュは、入力データから一定の規則で別の値を作る処理である。

password
  ↓
ハッシュ関数
  ↓
f3ab... のような値

ここで重要なのは、同じ入力なら必ず同じ結果になるが、結果から元の入力を直接取り戻す前提ではない ことだ。

ログイン時は次のように照合する。

登録時
入力パスワード
   ↓
ハッシュ化
   ↓
ハッシュ値を保存

ログイン時
入力されたパスワード
   ↓
同じ手順でハッシュ化
   ↓
保存済みハッシュと比較

つまりサーバーは、平文パスワードを覚えるのではなく、比較用の値 を保存する。

ソルトとは何か

ソルトは、パスワードへ追加するランダムな付加データである。

password + salt
      ↓
   ハッシュ化
      ↓
保存する値

ソルトが重要なのは、同じパスワードでもユーザーごとに違う結果を作りやすくなるからである。

Sato:  lesson-pass + salt-A → hash-X
Ito:   lesson-pass + salt-B → hash-Y

これにより、

同じパスワードを使っている利用者を見抜かれにくくなる
事前計算された攻撃用データを使い回されにくくなる

という効果がある。

実務では遅いハッシュを使う

ここでさらに重要なのは、パスワード保存には一般的な高速ハッシュをそのまま使わない ことである。
実務では、総当たり攻撃を遅くするために bcrypt、scrypt、Argon2 のようなパスワード専用の遅いアルゴリズムを使う。

つまり実務の考え方は、

平文保存しない
   ↓
ソルト付きでハッシュする
   ↓
パスワード専用の遅いアルゴリズムを使う

である。

6. HTTPS は何を守るのか

HTTPS は、HTTP を TLS で保護した通信 である。
第2章では「安全に包んだ HTTP」として見たが、ここでは何が守られるのかをもう少し具体的に見る。

ブラウザ == TLSで保護された経路 == サーバー

HTTPS が主に守るのは次の3つである。

守るもの	何を意味するか
秘密性	途中で内容を盗み見られにくい
完全性	途中で内容を書き換えられにくい
接続先の確認	本当にそのサーバーへ接続しているか確かめやすい

HTTPS がないと何が危険か

利用者 ──(平文のHTTP)── 攻撃者も見える ── サーバー

この状態では、

ログインIDやパスワード
セッションCookie
返ってくる HTML / JavaScript

などが盗み見や改ざんの対象になりうる。

特にログイン情報やセッションCookieが取られると、本人になりすまされる危険がある。

ただし HTTPS だけでは足りない

HTTPS は通信経路を守るが、

弱いパスワード
平文保存された認証情報
間違った認可設定

までは解決しない。

つまり HTTPS は重要だが、認証・認可・安全な保存方式とセットで考える必要がある。

7. 実務でどう組み合わさるか

これまでの要素を、1つの流れとして並べると次のようになる。

1. 利用者がログイン画面へ入力
2. ブラウザが HTTPS で送信
3. サーバーが保存済みハッシュと照合
4. 成功したらセッションIDやトークンを返す
5. 以後の各リクエストで認証状態を確認
6. 操作ごとに認可を確認
7. 許可なら処理、不可なら 401 / 403

書籍管理アプリの例だと、こう考えられる。

操作	認証	認可
本の一覧を見る	必要	一般ユーザーでも可
本を追加する	必要	編集権限が必要
本を削除する	必要	管理者だけ可

ここで大切なのは、認証は入口の確認、認可は各操作ごとの確認 だということだ。
一度ログインしたあとも、操作ごとに権限判断は続く。

8. 初学者が混同しやすい点

ログインできた = 何でもできる、ではない

ログイン成功は本人確認が通っただけである。
その後の削除・閲覧・管理画面アクセスは、別途認可が必要になる。

ハッシュ = 暗号化、ではない

暗号化は「戻す」ことを前提にする。
ハッシュは「戻さず、一致確認に使う」ことを前提にする。

HTTPS があれば保存方法は何でもよい、ではない

HTTPS は通信中を守るが、データベースに平文保存していたら漏えい時に防げない。
通信の安全 と 保存の安全 は別々に考える必要がある。

まとめ

キーワード	説明
認証	あなたは誰かを確かめること
認可	その操作を許してよいか判断すること
`401`	認証が必要、または不足している状態
`403`	認証済みだが権限が足りない状態
パスワードハッシュ	平文の代わりに照合用の値を保存する考え方
ソルト	パスワードへ追加してハッシュを個別化する付加データ
`bcrypt` / `scrypt` / `Argon2`	実務で使う代表的なパスワードハッシュ手法
HTTPS	通信経路を盗み見・改ざんされにくくする仕組み
`Secure` / `HttpOnly`	Cookie をより安全に扱うための代表的な属性

次のステップ

演習問題に取り組んで、認証・認可・ハッシュ・HTTPS の関係を自分の言葉で説明できるようになろう。

理解できたら、次は 6-2. OWASP Top 10 で代表的な脆弱性の種類を学ぼう。