暗号化とハッシュ化の使い分け

はじめに

「平文で保存しない」情報がたくさんありますが、暗号化とかハッシュ化とか色々あり、実際プロダクトでどうなってるっけって思ったので整理しようと思います。

なんで平文でDBにデータを持たないのかというとシンプルに

万一DBのデータが漏洩しても、そのまま読める状態を避けるため

です。

個人情報とか（住所・氏名・電話番号・トレードオフあるけどDMなど）って、平文で入ってたら漏れた瞬間にそのまま使えるので、 そこは絶対に避けたい情報です。

一方で、トークンとか認証系の値って少し性質が違っていて、

漏れたら読めるかどうかじゃなくて、「そのまま使えてしまうか」が問題 ですよね。

例えば招待トークンやセッションキーみたいなものは、平文で持っていると、それが漏れた時点で認証が通ってしまう。

なので、

• 個人情報 → 読まれると困る

• トークン → 使われると困る

という違いがあります。

このあたりを整理していくと、「じゃあこれは暗号化？それともハッシュ化？」っていう判断が、ちゃんと理由を持ってできるようになるなと思いました。

この記事では、細かいアルゴリズムの話というよりは、どう使い分けるのかという実務的な視点で整理していきます。

結論

その値、レスポンスとして返す？それとも検証の材料？

• レスポンスで返す／そのまま使う → 暗号化

• 検証の材料として使うだけ → ハッシュ化

かなりシンプルですが、これでほとんどのケースは判断できます。

もう少し正確に言うと厳密には元の値をそのまま使う必要があるか？ですかね。

• 必要がある → 暗号化

• 必要がない（照合だけ） → ハッシュ化

「レスポンスで返すか？」という問いで判断をできるかなと思います。

具体例

実際のコードベースで出てきたケースをもとに見ていきます。

暗号化するケース

・個人情報（住所・氏名）

画面表示や配送処理で使うため、元の値が必要です。

→ ハッシュ化すると復元できない → 暗号化

・銀行口座番号

振込処理でそのまま使います。

→ 復号できないと業務が成立しない → 暗号化

・SNSアクセストークン

APIを叩くときにそのまま使います。

→ ハッシュ化するとAPI呼べない → 暗号化

ハッシュ化するケース

・招待トークン

ユーザーが持っているトークンと一致するかだけ分かればOK。

→ 元の値は不要 → ハッシュ化（例：SHA-256）

DBが漏洩しても平文トークンが漏れないため、安全性が上がります。

・非ログインユーザー用のキー

クライアントが持つ識別子との照合のみ。

→ 一致確認だけで十分 → ハッシュ化

とりあえずハッシュ化は危険

例えばアクセストークンをハッシュ化すると、

• APIが呼べない

• 実質使えないデータになる

こうなると要件を満たせなくなります。

ハッシュ化すれば何でも安全、ではない

例えば、推測可能な値やランダム性が低い値をそのままSHA-256でハッシュ化した場合、レインボーテーブル攻撃によって元の値を逆算される可能性があります。

レインボーテーブルとは、あらかじめ大量の値とそのハッシュ値を対応させたテーブルのことで、ハッシュ値さえ手に入れば元の値を素早く特定できてしまいます。

そのため実務では、招待トークンや識別キーにはUUIDv4など十分なランダム性（128bit以上）を持つ値を使うことで、レインボーテーブル攻撃を現実的に無力化できます。

逆に言えば、ランダム性が十分に確保されていれば、トークンの照合用途においてSHA-256は十分に安全です。

判断に迷ったら

• レスポンスで返す？

• 内部処理でそのまま使う？

• 一致確認だけで足りる？

• 万一漏洩したら何が起きる？

この4つを考えると、どう保存するのが適切か検討すると良さそうです。

まとめ

暗号化とハッシュ化の違いは色々ありますが、 実務での判断はシンプルです。

その値、レスポンスで返す？検証だけ？

この視点を持つと迷わなくなりそうです。

おわりに

今回の整理は、既存の暗号化処理を読んでいて「これ、なんでこの設計なんだろう？」と疑問に思ったのがきっかけでした。

普段実装に追われていて理解追いついてなくても進まざるを得ないので(ほんとに良くないけど切羽詰まっている)GWなのでちょっとタスクを忘れて実装の確認をしております😮‍💨

次はもう少し踏み込んで、

• なぜエンベロープ暗号化を使うのか

• KMSとデータキーの関係

で、何をDBに保存しているのか?あたりも整理してみようと思います。