昨今企業の情報漏洩なんてものがよくありますね。
企業から出される謝罪文を見ていると、
～パスワードは漏れていません。
～クレジットカード情報は保有していません。
こんな文章をよくみませんか？
今回は情報漏洩の時パスワードやクレジットカード情報が漏れない仕組みのお話。
パスワードの登録と利用の流れ
ざっくりとパスワード登録の流れとログイン時は以下のような流れになります。
【登録時】
パスワード作成 → HTTPSで送信 → サーバーがソルトを新しく生成し、ペッパーと一緒に混ぜる → ハッシュ化 → ハッシュ値とソルトをDBに保存
【ログイン時】
パスワード入力 → HTTPSで送信 → サーバーがDBから保存済みのソルトを読み出し、ペッパーと一緒に混ぜる → 登録時と同じ方法でハッシュ化 → DBのハッシュ値と比較 → 一致すれば認証OK※一般的な例です。ペッパーは採用していないサービスもあります。
これだけ読んでも、そうなんだ、ふーん程度の感想になるかと思います。
カレー作りに例えるなら
① カレーを作るためのレシピ
（パスワード：任意の文字列をユーザーが決める）
例：にんじん、じゃがいも、たまねぎ、とりにく
好きなの4文字 “abcd” 、 “efgh” 、 “wasd” だと思ってもらえれば結構です。
② 秘伝のカレールーを用意
（ペッパー：別の安全な場所（金庫）に保管・全員共通・秘密）
③ 隠し味を用意
（ソルト：ユーザーごとに毎回ランダムに生成した値・ラベルとして保存・秘密ではない）
ペッパーはDBとは別の場所に保管している共通の調味料。今回はカレールーとしています。
ソルトはサーバー君が勝手に決める隠し味です。
④ 調理工程（ハッシュ化）
・にんじん、じゃがいもは乱切り
・たまねぎは薄切り
・先にたまねぎを炒めます
・水には少し出汁を加えます
・煮込む時間は…etc
完成したカレーから、元のレシピ（パスワード）を逆算することは誰にもできません。
⑤ 完成したカレーをサーバーに食わせて保存します。
（ハッシュ化済のパスワードとソルトをDBに保存）
⑥ 次回以降のログインは、保存されたラベル（ソルト）を読んで同じ工程で作り直します。
作りなおしたカレーを、保存済みのカレーと見比べる（一致すれば認証OK）
当然ながらカレーが合致しない場合はログインエラーになります。
情報漏洩した場合、完成したカレーを世界に向けてぶちまけたような状態です。
攻撃者（悪意ある第三者）は、ぶちまけられたカレーを見て、「よくあるレシピ候補を、ラベル（ソルト）の隠し味を使って同じ工程で作り、味が一致するか」を片っ端から試します。
ただし、秘伝のカレールー（ペッパー）は金庫の中なので、手元で同じ味を再現できません。
また、調理工程が長いほど、1回試すのに時間がかかります。
にんじん、じゃがいもだけの単純なレシピ（弱いパスワード）は当てられやすく、
複雑で長いレシピ（強いパスワード）ほど、当てるのが難しくなります。
カード情報については？
カード情報は保有していない（非保持化）企業が多いため、漏れようがないケースもあります。
近年の安全なWebサービスの多くは、自社のデータベースやサーバーにクレジットカード番号を直接保存しません。
その代わりに、セキュリティ基準を厳格にクリアした専門の決済代行会社（PSP）のシステムに直接クレジットカード情報を入力・送信する仕組み（トークン決済など）をとっています。
＜一般的な非保持化の仕組みを示した図＞
よくある、情報漏洩は赤枠部分が該当します。
ユーザーは”加盟店”に注文をしますが、決済を行うのは”決済代行会社”になります。
ここにカード番号が送られます。
余談ですが、一般的なECサイトではカードの下4桁が表示されていることがありますが、
表示用に保存されているのは、ブランドと下4桁などだけで、番号の全体は保存されていません。
最後に…
パスワード情報が復元できないんだー。
だったら安心！…とはならず。
他のサービスと同じパスワードを使い回していると、別ルートで侵入される（パスワードリスト攻撃）リスクがあるため、使い回しを避けてパスワード管理ソフトを利用し機械的に管理する。
二要素認証やパスキーを設定しおくのがいいのかなー…と思います。
