認証の土台、パスワードの守り方へ
Q-01では、認証つまり誰であるかの確認と、認可つまり何をしてよいかの判断を分けて考えました。今回はその認証の一番の土台、パスワードそのものの守り方に入ります。ログイン機能を作るとき、多くの人が見落とすのが、パスワードをどんな形で保存するかという点です。ここを誤ると、認証の入口が丸ごと危険になります。
このスライドのポイント
- Q-01: 認証（誰であるか）と認可（何をしてよいか）を区別した
- 今回はその認証の一番の土台、パスワードそのものの守り方
- ログイン機能で見落とされがちなのが「パスワードをどんな形で保存するか」
- ここを誤ると、認証の入口が丸ごと危険になる
平文とハッシュの定義
まず平文とは、入力されたそのままの文字列のことです。ハッシュとは、入力を固定長の別の値へ一方向に変換したものを指します。同じ入力からは必ず同じハッシュが得られますが、ハッシュから元の文字列を復元することはできません。パスワードはこのハッシュだけを保存し、平文は残しません。ログイン時は、入力を同じ変換にかけ、保存済みのハッシュと一致するかで照合します。パスワード用には計算コストをわざと高くした専用方式を使いますが、方式名の暗記は不要で、「パスワード専用のハッシュを使う」が判断基準です。
このスライドのポイント
- 平文＝入力されたそのままの文字列
- ハッシュ＝入力を固定長の別の値へ「一方向」に変換したもの
- 同じ入力→必ず同じハッシュ／ハッシュ→元の文字列は復元できない
- 保存するのはハッシュのみ。平文は残さない
- 照合＝ログイン時の入力を同じ変換にかけ、保存済みハッシュと比較
- パスワード用は計算コストを意図的に上げた専用方式（方式名の暗記は不要。判断基準は「パスワード専用のハッシュを使う」）
なぜ「戻せない形」で保存するのか
この仕組みを知らないと、AIに「ログイン機能を作って」と頼んで平文保存のコードが返っても、危険だと見抜けません。もしデータベースが漏えいすれば、保存が平文のままでは全利用者のパスワードがそのまま流出します。多くの人が同じパスワードを他のサービスでも使い回しているため、被害は自分のアプリの外にまで広がります。ハッシュで保存していれば、漏れても元の文字列はそこには存在しません。
このスライドのポイント
- 知らないと: AIに「ログイン機能を作って」と頼み、平文保存のコードが返っても見抜けない
- データベースが漏えいしたとき、平文なら全利用者のパスワードがそのまま流出
- 多くの人がパスワードを他サービスで使い回すため、被害は自分のアプリの外へ広がる
- ハッシュ保存なら、漏れても元の文字列はそこに存在しない
一方向変換の構造
保存の流れは一方向です。登録時は、利用者が入力したパスワードをハッシュに変換し、そのハッシュだけをデータベースへ保存します。ログイン時は、入力を同じ変換にかけて、保存済みのハッシュと比較します。図で大事なのは、ハッシュから元のパスワードへ戻る逆向きの矢印には×が付く、という点です。照合はできても復元はできない。この非対称こそが安全の核心です。
このスライドのポイント
- 保存の流れは一方向
- 登録時: パスワード → ハッシュに変換 → ハッシュだけをDBへ保存
- ログイン時: 入力 → 同じ変換 → 保存済みハッシュと比較
- 図の核心: ハッシュ→元のパスワードへ戻る逆向き矢印には×
- 照合はできても復元はできない、という非対称が安全の核心
「パスワードを教えて」に答えられないのが正しい
身近な例で確かめます。「パスワードを忘れたので教えてください」と問い合わせたとき、運営が元のパスワードを答えられないのが、実は正しい設計です。ハッシュしか持っていないので、復元して教えることができないからです。だから正しいサービスは、パスワードを教える代わりに再設定用のリンクを送ります。逆に、もし元のパスワードをそのまま教えてくれるサービスがあれば、平文で保存している疑いがあり、危険だと判断できます。
このスライドのポイント
- 「パスワードを忘れたので教えて」に運営が元のパスワードを答えられないのが正しい設計
- 理由: ハッシュしか持っていないので復元して教えられない
- だから正しいサービスは、教える代わりに再設定用リンクを送る
- 逆に、元のパスワードを教えてくれるサービスは平文保存の疑い＝危険
技術サンプル: 登録と照合の2フロー
サンプルは、登録と照合の2つのフローを並べた図です。登録では、ダミーのパスワード「aki2026!」をハッシュに変換し、「f3a9…」というダミー表記の値だけを保存します。照合では、ログイン時の入力を同じ変換にかけ、保存済みの「f3a9…」と一致するかを見ます。読み方の要点は、データベースの中に元の文字列「aki2026!」がどこにも存在しないこと、だから万一漏れても即座には使えないことです。そして最大の注意点は、こうした認証の仕組みは自作せず、実績のある仕組みに任せるのが定石だという点です。
ハッシュと暗号化を混同しない
混同しやすいのが、ハッシュと暗号化の違いです。ハッシュは一方向で、元に戻せません。一方、暗号化は鍵があれば元に戻せる、双方向の変換です。パスワードの保存に暗号化を使うのは不適切です。なぜなら、暗号を解くための鍵も一緒に漏れれば、全パスワードが元通りに復元されてしまうからです。パスワードは戻せてはいけない情報なので、戻せないハッシュが正解になります。
バイブコーディングでの確認点
バイブコーディングでの確認点です。まず、ログイン機能は自作せず、実績のあるBaaSやライブラリに任せるよう、最初からAIに指定します。これは、既製の仕組みに任せるという判断を、最も重要な場面に当てはめたものです。そのうえで、生成されたコードには「このコードはパスワードをどの形式で保存していますか。平文やただの暗号化になっていませんか」と確認します。ここまで学んだ上で、あえて作らないと判断できることが、本当の理解です。
このスライドのポイント
- ログイン機能は自作せず、実績あるBaaSやライブラリに任せるよう最初からAIに指定する
- これは「既製の仕組みに任せる」判断を、最も重要な場面に当てはめたもの
- 生成コードには「パスワードをどの形式で保存しているか。平文やただの暗号化になっていないか」を確認
- ここまで学んだ上で、あえて「作らない」と判断できることが本当の理解
まとめと次回
最後に一問一答です。パスワードを保存する正しい形式は何でしょうか。（間）答えは、ハッシュです。一方向に変換した値だけを保存し、平文や暗号化は使いません。30秒のまとめとして、照合はできるが復元はできない形で保存すること、そして認証は自作せず実績ある仕組みに任せること、この2つを覚えてください。次回は、ログインした状態をどう続かせるか、その仕組みへ進みます。関連資料は「AIアプリのセキュリティ超入門」と「セキュリティ用語50」です。
このスライドのポイント
- 一問一答:「パスワードを保存する正しい形式は？」→ ハッシュ（一方向変換。平文・暗号化は不可）
- 30秒まとめ: ①照合はできるが復元はできない形で保存する ②認証は自作せず実績ある仕組みに任せる
- 次回 Q-03: ログインした状態を続かせる仕組みへ
- 関連資料: 「AIアプリのセキュリティ超入門」「セキュリティ用語50」
