6-1. 演習問題

問題1：選択問題

1-1. 認証の説明として最も適切なのはどれか。

A. あなたが誰かを確認すること
B. データベースの容量を増やすこと
C. 画像を圧縮すること

解答と解説

正解：A. あなたが誰かを確認すること

A が正しい。認証は「本人確認」であり、ログインしているか、資格情報が正しいかを確認する。
B は誤り。容量増加はインフラや運用の話である。
C は誤り。画像圧縮はメディア処理であり、認証とは無関係である。

認証は、セキュリティの入口で「誰として扱うか」を決める処理である。

1-2. 認可の説明として最も適切なのはどれか。

A. その操作を許してよいか判断すること
B. パスワードを自動生成すること
C. 画面の色を変更すること

解答と解説

正解：A. その操作を許してよいか判断すること

A が正しい。認可は、ログイン後にその操作を許可するかを判断する。
B は誤り。パスワード生成は認可ではない。
C は誤り。画面デザインの変更とは無関係である。

たとえば「削除ボタンを押せるのは管理者だけ」のような判断が認可である。

1-3. 一般ユーザーがログイン済みだが、管理者専用の削除APIを呼び出した。このとき最も適切なのはどれか。

A. 200 OK
B. 401 Unauthorized
C. 403 Forbidden

解答と解説

正解：C. 403 Forbidden

C が正しい。本人は分かっているが、その操作を許していない状態なので 403 が適切である。
A の 200 OK は成功なので不適切である。
B の 401 Unauthorized は「まず認証してほしい」状態であり、今回はログイン済みなのでずれる。

401 は認証不足、403 は権限不足という整理が重要である。

1-4. パスワードを平文で保存してはいけない主な理由として最も適切なのはどれか。

A. データベース漏えい時に、そのまま読まれて悪用されやすいから
B. SQL の速度が必ず 100 倍遅くなるから
C. HTTPS が使えなくなるから

解答と解説

正解：A. データベース漏えい時に、そのまま読まれて悪用されやすいから

A が正しい。平文保存では、漏えいした瞬間に利用者のパスワードがそのまま見えてしまう。
B は誤り。性能の話ではなく、主問題は漏えい時の被害である。
C は誤り。HTTPS は通信経路の話であり、保存形式とは別である。

平文保存の危険性は、「漏れたら即座に使える情報」になってしまう点にある。

1-5. ソルトの主な役割として最も適切なのはどれか。

A. 同じパスワードでもユーザーごとに異なるハッシュになりやすくすること
B. どんなユーザーにも管理者権限を与えること
C. ブラウザのキャッシュを削除すること

解答と解説

正解：A. 同じパスワードでもユーザーごとに異なるハッシュになりやすくすること

A が正しい。ソルトを加えると、同じ平文パスワードでもユーザーごとに異なる結果を作りやすくなる。
B は誤り。権限は role やポリシーの話であり、ソルトとは関係ない。
C は誤り。キャッシュ削除はブラウザの動作であり、ソルトの役割ではない。

ソルトは「ハッシュを個別化する」ための工夫であり、同一パスワードの見分けを難しくする。

1-6. HTTPS の役割として最も適切なのはどれか。

A. 通信中の盗み見や改ざんをされにくくすること
B. すべてのユーザーへ自動で権限を付与すること
C. パスワードを平文保存しても安全にすること

解答と解説

正解：A. 通信中の盗み見や改ざんをされにくくすること

A が正しい。HTTPS は通信経路を保護し、ログイン情報やCookieの盗み見・改ざんをされにくくする。
B は誤り。権限付与は認可の仕事であり、HTTPS の仕事ではない。
C は誤り。平文保存の危険はデータベース漏えい時に残るため、HTTPS だけでは解決しない。

HTTPS は重要だが、「通信の安全」を担当する部品であって、保存方式や権限設計の代わりにはならない。

問題2：穴埋め問題

次の文章の空欄を埋めてください。

「あなたは誰か」を確認することを （　　　） という。
「その操作を許してよいか」を判断することを （　　　） という。
パスワード保存では、平文の代わりに （　　　） を保存する。
パスワードへ追加するランダムな付加データを （　　　） という。
通信経路を保護する仕組みを （　　　） という。
ログイン済みだが権限不足で拒否される代表的なステータスコードは （　　　） である。

解答欄

解答と解説

認証

「あなたは誰か」を確認する処理である。ログインが代表例である。
認可

本人確認のあとに、「その操作を許してよいか」を判断する処理である。
ハッシュ

パスワード平文の代わりに保存する比較用の値である。元の文字列をそのまま保持しないことが重要である。
ソルト

パスワードへ追加するランダムな付加データである。同じパスワードでも異なるハッシュにしやすい。
HTTPS

HTTP を TLS で保護した通信である。通信経路の盗み見や改ざんを防ぎやすくする。
403

ログインは済んでいるが権限不足で拒否されるときの代表的なステータスコードである。

問題3：記述問題

3-1. 認証と認可の違いを、書籍管理アプリの例を使って説明してください。

解答欄

解答と解説

認証は「その人が誰か」を確認することであり、たとえばログイン画面で ID / パスワードを確認する処理が該当する。一方、認可は「その人にその操作を許すか」を判断することであり、書籍管理アプリで本の削除を管理者だけに許す判断が該当する。つまり、ログイン成功は入口の確認であり、その後の各操作では別途権限確認が必要になる。

3-2. パスワードを平文保存した場合、どのような被害につながりやすいか説明してください。

解答欄

解答と解説

平文保存では、データベースが漏えいした瞬間にパスワードがそのまま読めてしまう。その結果、攻撃者はそのままログインを試せるし、利用者が他サービスで同じパスワードを使っていると被害が連鎖しやすい。そのため、パスワードは読める形で持たず、比較用のハッシュを保存する必要がある。

3-3. ハッシュだけでなくソルトも必要になる理由を説明してください。

解答欄

解答と解説

ハッシュだけだと、同じパスワードを使うユーザーは同じハッシュになりやすい。ソルトを加えると、同じ平文でもユーザーごとに異なる結果になりやすくなり、同一パスワード利用の見分けや事前計算攻撃をしにくくできる。つまりソルトは、ハッシュをより安全に使うための個別化情報である。

3-4. HTTPS が重要でも、それだけでセキュリティが十分ではない理由を説明してください。

解答欄

解答と解説

HTTPS は通信中の盗み見や改ざんを防ぎやすくするが、データベースに平文保存されたパスワードや、間違った権限設定までは直してくれない。たとえば HTTPS を使っていても、一般ユーザーが管理者APIを呼べる設計なら危険は残る。そのため、通信の安全、保存の安全、認証、認可をそれぞれ分けて設計する必要がある。

問題4：ハンズオン

authenticate と canDeleteBook のTODOを実装し、認証・認可の動きを確認せよ。

このサンプルでは学習用に SHA-256 を使っている。実務のパスワード保存では bcrypt・scrypt・Argon2 を使う前提で読むこと。

取り組む内容

authenticate で入力パスワードを user.salt で再ハッシュし、user.passwordHash と比較して true/false を返す
canDeleteBook で user.role === "admin" のときだけ true を返す
実行し、ログインの成否・削除権限の結果が期待通りになることを確認する

実行プレイグラウンド

編集内容は自動保存されます / Ctrl+Enter でも実行できます

const encoder = new TextEncoder();

// 学習用に SHA-256 を使う。実務では bcrypt / scrypt / Argon2 を使う。
async function sha256Hex(text) {
const digest = await crypto.subtle.digest("SHA-256", encoder.encode(text));
return Array.from(new Uint8Array(digest))
  .map((byte) => byte.toString(16).padStart(2, "0"))
  .join("");
}

async function hashPassword(rawPassword, salt) {
return sha256Hex(`${salt}:${rawPassword}`);
}

async function createUser(userId, rawPassword, role, salt) {
return { userId, role, salt, passwordHash: await hashPassword(rawPassword, salt) };
}

// TODO: rawPassword を user.salt で hashPassword し、user.passwordHash と比較して true/false を返す
async function authenticate(user, rawPassword) {
return false;
}

// TODO: user.role が "admin" のときだけ true を返す
function canDeleteBook(user) {
return false;
}

(async () => {
const admin = await createUser("sato", "lesson-pass", "admin", "salt-2026");
const reader = await createUser("ito", "lesson-pass", "reader", "salt-2027");

console.log("stored fields", Object.keys(admin).join(", "));
console.log("raw password stored?", "rawPassword" in admin);
console.log("same raw password, same hash?", admin.passwordHash === reader.passwordHash);

const adminLogin = await authenticate(admin, "lesson-pass");
console.log("admin login", adminLogin);
console.log("admin delete allowed", adminLogin && canDeleteBook(admin));

const readerLogin = await authenticate(reader, "lesson-pass");
console.log("reader login", readerLogin);
console.log("reader delete allowed", readerLogin && canDeleteBook(reader));

const wrongLogin = await authenticate(admin, "wrong-pass");
console.log("wrong password login", wrongLogin);
})();

出力

「実行」を押すと、ここに結果が表示されます。

確認したいポイント

admin と reader が同じ平文パスワードでも same raw password, same hash? が false になる理由（ソルトの役割）
reader はログインできても削除権限が false になる理由（認証と認可の違い）
reader の salt を "salt-2026" に変えると same raw password, same hash? が true になることを確認する

解答と解説

② そのまま実行したときの見方

stored fields userId, role, salt, passwordHash
raw password stored? false
same raw password, same hash? false
admin login true
admin delete allowed true
reader login true
reader delete allowed false
wrong password login false

stored fields に rawPassword がなく、代わりに passwordHash があることから、平文ではなく比較用の値を保持していると分かる。 same raw password, same hash? false は、同じ平文でもソルトが違えば結果が変わることを示す。 reader login true なのに reader delete allowed false なのは、認証成功と認可成功が別だからである。 wrong password login false から、入力値を再ハッシュして比較していることも読み取れる。

③ role を "admin" に変えたとき

reader login true
reader delete allowed true

ここで変わっているのはログイン成否ではなく、削除権限の判定である。つまりコードは「本人確認」と「操作許可」を別々に見ている。これが認証と認可の違いである。

④ ソルトを salt-2026 に変えたとき

same raw password, same hash? true

admin と reader が同じ平文パスワード、同じソルトを持つと、ハッシュ結果も一致する。そのため実務では、ユーザーごとにランダムで異なるソルトを使う必要がある。この問題は、同じパスワード利用者を見抜かれにくくするためにも重要である。

コードの流れを図で見る

createUser
  ↓
salt + password をハッシュ
  ↓
passwordHash を保存
  ↓
authenticate
  ↓
入力された password を同じ salt で再ハッシュ
  ↓
一致したら login true
  ↓
canDeleteBook で role を確認

この小さなコードの中に、「保存」「認証」「認可」「ソルトの効果」がすべて入っている。

学習用コードでは SHA-256 を使ったが、実務のパスワード保存では高速すぎるため、そのままでは不十分である。実際には bcrypt、scrypt、Argon2 のように、総当たり攻撃を遅くできる専用アルゴリズムを使う。