はじめに
Laravelで、ユーザーのIDを生データでブラウザに不必要に表示してしまうのはいかがなものかと思い、Hashをすべきかencryptすべきか悩んで色々調べていた。
その時に自分の知識が浅はかすぎたことを痛感した、、、
Laravelでは「暗号化」の方法としてCryptファサードによるencryptStringやヘルパメソッドであるencryptが、「ハッシュ」の方法としてHashファサードによるmakeメソッドがあるのは知っていたけど、どのように使い分けるか知らなかったのでメモ。
暗号化とハッシュの違い
上記のドキュメントに合わせてコチラを参考にしました。
恥ずかしい話、ここを知らなかったです。。。
（生の文字列が小難しい文字列に変換されるので暗号化の手段の１つがハッシュ、と勘違いしていました。。。）
暗号化とハッシュの違いは色々ありますが大きな違いは「その処理の目的」と「性質」かなと思います。
ハッシュ
目的：不可逆なデータに置換え。開発者すら復元は不可なデータにする。
性質：不可逆。元のデータに戻せない
暗号化
目的：データの秘匿。
性質：元データに復元可能
具体的な使い分け
では、具体的にどう使い分けるか、例を挙げて考えてみた。
今回は「DBに保存するにはハッシュ？暗号化？」を考える
※注意
- あくまで個人的に「どうするべきだろう？」とフラットに仮説を立てているだけであり、実際は先輩に聞きつつデータをどのように扱うべきか相談するかなと思います。
- 自分はセキュリティについてはぺーぺー中のペーペーです。他にもいろんな方法があるかもですが、ここでは 「暗号化」、「ハッシュ」の違いを整理にするために書き留めているに過ぎない という点はご留意ください。
メールアドレス
- ユーザーへのメール送信ができなくなるので、ハッシュは使えない
- しかし、個人情報保護の観点から秘匿にすべきなので「暗号化」する
パスワード
-
特に漏らしてはいけない情報で、これはアプリケーション内で使うことはないため「ハッシュ化」で問題ない
-
※余談だが、サイトで「パスワードを忘れた方へ」で再パスワードを作成するのはこの不可逆性なのかと納得
住所
- アプリケーションの提供者、運営者側からのはがきや商品の郵送時に必要であるため、ハッシュ化できない。
- 個人情報保護の観点からも「暗号化」が適していると思われる。
電話番号
- コチラもアプリケーション提供者、運営者からの最終連絡手段として元データは必要のためハッシュ化できない
- 個人情報保護の観点からも「暗号化」が適していると思われる。
パッと思いつくのがこれくらいですが、基本は「暗号化」、パスワードについては「ハッシュ」なのかな、なんて思いました。不可逆という性質にすべきか否かが判断分かれるところかも。
おわりに
- 今回改めてハッシュと暗号化の違い、その使い分けを考えてみた
- 調べていると、開発者としては結構当たり前の知識かと思うので今更ながら学びました。。。
- こういう知識をインプットしたうえでこういうニュースを見ると怖いなあ、、、って思うと同時に、「なんでそんなリスクを負うんだろう？」とギモンに思います。結構最近のニュースだし…
- 恐らくセキュリティに疎い、権力のある関係者の強い要望でユーザーの利便性を重視すべくこうなったのでしょう。。。
- ちなみに結局、冒頭のIDのハッシュ化及び暗号化の必要はない設計になりました笑
最後までお読みいただきありがとうございました！