Q&A
画面の表示が絶対に発生しないのでしょうか
ユーザーへのメール通知もないとか
極論言ってしまうと名前や電話番号も暗号文にしないといけなくなりませんか？
LaravelをComposerを使いインストールしました。
その後、ここを参考にして、ログイン機能をつけました。
現状、新規登録やログインは問題なく行われており、パスワードもハッシュとソルトがされています。
しかし、メールアドレスは平文で保存されています。
メールアドレスも流失したはいけない時代。
現場ではどのような対策をされているか伺いたいです。
自分が調べた限りでは、暗号化とハッシュ化の2種類を作り、
ログイン時にハッシュ化。
パスワードリセット等に暗号化を使うという方式でした。
言っている意味が少々わかりません。
> 画面の表示が絶対に発生しないのでしょうか
だから、暗号化とハッシュ化の2通りでの保存を行うんです。
> 極論言ってしまうと名前や電話番号も暗号文にしないといけなくなりませんか？
暗号化しませんか？個人情報かそれに類するものじゃないですか
「調べた限りでは」と言っているだけなので実際にやってみたかどうか伝わりません。方針決めの段階なのであれば「だから、暗号化とハッシュ化の2通りでの保存を行うんです。」という確定的なコメントにならないと思います。
あと「現場でどうか」という聞かれ方をされていますが、現場のやり方は外には出ませんのでこういう求め方をしても誰も答えないと思います。
それこそセキュリティに関わります。
自身が信じた方法でやってみて運用してみてどうか、そこで問題があった場合に質問すべき内容です。
ということは、セキュリティー的に問題のあるWEBアプリケーションでも問題発覚後に対処すれば良いということですか？
「暗号化とハッシュ化の2通り」にどこにどのような問題があると載ってましたか？何を懸念されているのか私には分かりません。
そこまで気にするのであれば個人ではなく業者に依頼されてはどうでしょうか。
これが最適解なのかを伺いたいだけです。
この手の話に最適解はありません。
今日の最適解は明日の最適解ではないからです。
回答3件
0
これが最適解なのか
というのはどのようなアプリケーションにも存在しません。
そのアプリケーションの要件と
どのような漏えい経路が想定されるのかと
全て洗い出したうえで対応すべきだからです。
だから「とりあえず暗号化しておけば良い」というだけで導入するのは逆にコストだけが重なって大して効果が見込めなくなることもあります。
攻撃手法を把握しておかなければ守れませんしね。
むしろ「ユーザー側のミス以外で漏えいしにくい仕組み」を導入する方が先決では？
投稿2019/12/31 04:50
編集2019/12/31 04:54総合スコア80850
> むしろ「ユーザー側のミス以外で漏えいしない仕組み」を導入する方が先決では？
具体的にはどのようなものでしょうか？
アプリケーションの要件次第です。
なので、何もアプリケーションの要件が提示されてない段階では誰も答えられません。
絶対はないので、まず「どういうアプリケーションなのか」から「どういう攻撃方法がある」で、「その攻撃手法はこのアプリケーションでは有効なのか、起きえるのか」を検討するところからです。
現状では、Laravelを用いたCMSサイトを構築中です。
サーバーはLAMPを予定しています。
メールアドレスの暗号化の意図としてはMySQLの盗聴を想定しています。
TDEも検討しましたが、情報が少なく、断念した次第です。
SQLインジェクションの脆弱性は、現状問題ないと考えています。
>Laravael
>盗聴
落ち着いてください
修正しました
そもそも「MySQLの盗聴」された時点でコードももれてるから暗号化されてても複合化手段もわかるよな
asahina1979さん、
コードが漏れているとは限らないのでは？
もう１つ書いてますが、「盗聴」ってなんでしょう。
どこかで会話に出るようなことがあるんでしょうか。私にはその状況は想像できませんけど・・・
例え「漏えい」だったとしても、SQLインジェクション対策ができているのなら
暗号化してまで守る意味はないと思うのですけど。
そこまでして必要な「要件」って何ですか？次の質問でも問われていますね。
暗号化して、
ユーザーが使いにくい、開発側が保守しにくい、運営が運用しにくいアプリケーション
になってしまっては本末転倒になるかと思います。
結局は要件次第ですよ。
asahina1979さん
この「盗聴」が意味するところが私も分かってません。
システムにおいて「盗聴」って表現する場面ってもはやシステムの問題じゃないですし。
質問者さんの脳内では「盗聴 = 不正アクセス」な気がしなくもないですけど、
少なくとも「盗聴≠不正アクセス」ですからね。
1. ネットワーク通信のバイナリをみる（ ex. wireshark )
2. ネットワーク通信の電圧差をみる（ バイナリ解析が可能 ）
あたりが盗聴に当てはまるはずだが
ほぼデータセンター作業者じゃないと不可能なので
コードが取得可能
ヒューマンエラーですね。
内部体制の強化とルールの策定と徹底が先。
asahina1979さん、
失礼しました。本当の意味での「盗聴」について述べていらしたのですね。
asuchi0819さん
そういうことです。正しく言葉を使ってるかどうかは他者には分からないので
書かれた意味をそのものでいくしかないのです。エスパーするのもそれなりに労力が高いので。
プログラミングに限らず言葉を正しく使わないとコミュニケーション成り立たないのはどこでもあるので
そこを正確に表現しない人相手に深読みする必要はないと思います。
0
メールアドレスは、復号する必要があれば暗号化、必要なければハッシュが望ましいでしょう。
そのほかの対策としては考えられるのは
・通信を暗号化（DB、Web、など）
・ストレージを暗号化
・画面に出力する際はマスクする
・ログファイルにメールアドレスを出力しない
こんな所じゃないですかね。
完璧なセキュリティは存在しませんので、メールアドレスをどんな目的で使用するか、どのような攻撃に備えるか、をひとつずつ 考えていくことで、 十分なセキュリティを確保するように 検討してみてください。
投稿2019/12/31 09:57
総合スコア1379
0
以下の回答はエスパーです。
ようわからんけど、普通に暗号化すればいいのでは？
こちらのサイトの情報も1年以上前のものですがLaravel6.xでも有効です。
やりってることを雑破に説明すると、DBを保存する前と後に暗号化しますよーって感じです。
https://readouble.com/laravel/6.x/ja/encryption.html（公式ドキュメントの日本語訳）
投稿2019/12/31 07:10
編集2020/01/01 08:56総合スコア10429
>公式ではないので注意
公式ドキュメントを構成や項目含めて忠実に日本語訳されてるので「公式日本語ドキュメント」として紹介しても差し支えないと思います。
修正しました。
https://github.com/laravel-ja/ja-docs-6.x
> 公式ドキュメントは英語のみです。そのため、日本語翻訳を「公式」と呼ばないでください。
って書いてあるので、公式と呼ぶのは不適切です。
ドキュメントちゃんと読んでください
それは失礼しました。
あなたの回答
tips
プレビュー
