LAMPを使用したログインシステムの暗号化について

LAMPを使用したログインシステムの暗号化についてご教授ください。

アマゾンのような会員制ネットショップの開発を考えております。
DB（MYSQL5）へ会員情報を保存し、会員がログインできる仕様予定です。

要件
****************************
．MYSQLへ保存する会員情報は「会員番号以外」の全フィールドをBlowfish方式,salt使用で暗号化して保存したい
（安全であれば暗号化方式にはこだわりません。）
　目的：万が一会員情報データが流出した場合の被害を軽減したい

・会員テーブルのフィールド構成は5列
　「会員番号、ログインパスワード、クレジットカード番号、住所、電話番号」

質問
***************************
会員(仮に鈴木さん)は前月にログインパスワード「1234」で会員登録しました。

鈴木さんがログインパスワード「1234」を忘れた場合の手順は以下の手順で新パスワードに変更します。

(処理１)
システム側が仮パスワード「tmp0000」を作成し、会員テーブル内の鈴木さんのログインパスワードを「tmp0000」で上書きします。

(処理２)
鈴木さんへ仮パスワード「tmp0000」をメールで送信

(処理３)
鈴木さんが「tmp0000」でログインして会員テーブル内の鈴木さんのログインパスワードを新パスワード[new1111]で上書きします。


この場合、会員テーブル内の鈴木さんレコードのログインパスワード以外の列(クレジットカード番号、住所、電話番号)
は「1234」で暗号化されたままです。

【質問１】
処理１と処理３のタイミングでパスワード以外のフィールドは一旦復号化して再度暗号化、保存の手順が必要と思うのですが、元の復号キーが不明でも可能でしょうか？
復号しないと鈴木さんは住所、電話番号等の再入力が必要になってしまうと思いますので・・・

【質問２】
質問１の回答が可能な場合、どのような処理が必要でしょうか？

【質問３】
質問１の回答が不可能な場合、データが流出した場合の被害を軽減する代替え案は何かありますでしょうか？
住所、電話番号等は平文で保存すれば問題ないのかもしれませんが、リスキーなので躊躇します。
アマゾンや楽天等でパスワードを変更したときも住所等の再入力は必要なかったように記憶しています。

【質問４】
予想でも結構なのですがアマゾンや楽天等は住所などのフィールドは平文で保存しているのでしょうか？

【質問４】
ログインシステム開発時のDB暗号化の実装方法・概念等、のわかる
書籍やWEBページ等ありましたら教えてください。

また、この質問全体をとおして私に諸先輩方からアドバイス等あれば宜しくお願いします。

No.3 回答者： 1minn 回答日時： 2011/06/11 14:48

> 【質問１】

> 処理１と処理３のタイミングでパスワード以外のフィールドは一旦復号化して再度暗号化、保存の手順が必要と思うのですが、元の復号キーが不明でも可能でしょうか？

復号化するのにキーがなけりゃどうしようもないですよね？

私も最近、ECサイトの構築で少し悩みました。
その際に採用した方法としては、質問者さんと同様？に、パスワードは不可逆暗号化でその他の個人情報に係わる部分は可逆暗号化を行いました。

で、可逆暗号化なんですが・・・
複合化するためのキーを暗号化した文字列の中に含めています。
なので標準関数を拡張したプログラムを自作しております。

とはいってもいざ漏えいしてしまったらいずれ解読される時は来るでしょう。
また、DBのデータと共にプログラムのソースコードも盗まれてはどうしようもありません。
それでも平文で登録するよりははるかにマシだという事でこのような方法で行いました。

> 【質問４】
> 予想でも結構なのですがアマゾンや楽天等は住所などのフィールドは平文で保存しているのでしょうか？

ホントにただの予想ですが・・・
さすがに平文って事はないんじゃないですかね？

多くのサイトではパスワードの代替手段で「秘密の質問」などを用意していますよね？
ペットの名前は？　とか。

私が以前に構築したサイトでは「秘密の質問」は実装しませんでした。
クライアントがなにかと面倒くさがる方で、セキュリティに対する認識が低かったので・・・
（いいのかそれで？　って感じですが。）
その変わりと言ってはなんですが、画像認証を用意しました。
総当たりのクラックをかけられるような攻撃には対応できるかなと思ったので。


セキュリティに関して比較的意識が高い銀行などのネットバンキングサイトなどが参考になります。個々のエンドユーザーに対してトークンとよばれる時間ごとに切り替わるキーを発行するものを提供したり、「セキュリティカード」と呼ばれるビンゴカードのようなものを配布して、特定の位置の文字列を入力させる方式をとったりしています。
同じような事が出来る環境はなかなかないかもしれませんが、よいヒントにはなるんじゃないでしょうか？

> 【質問４】
> ログインシステム開発時のDB暗号化の実装方法・概念等、のわかる書籍やWEBページ等ありましたら教えてください。

とりあえず実装方法そのものがわかっちゃうといけないので考え方や意識を高めるようなものはあるかと思いますが、実装の参考になるものっていうのはあまり見たことがありません。

セキュリティが堅牢になればなるほど、面倒くさい操作や処理をエンドユーザーに求める事になってしまいますので、その妥協点を見つける事から始めてみては？

長々とあまり参考にならない回答ですみません。

No.2 回答者： NARH 回答日時： 2011/06/09 07:02

要件に対して疑問があります。

・DB項目の暗号化について
　万が一漏れたときの対応とのことですが、暗号化していることで漏れてしまっても安全と考えますか？

　データを入手した場合は、じっくりと時間をかけて解析することが可能になります。
　数件のデータをピックアップし、総当りするかけるわけですが、手元にデータがあるわけですから、
　後は諦めるまで続けるかどうかになるので、僕は安全とは考えません。ですから、この要件には、
　積極的なモチベーションはないなと判断します。
　＃データを盗む人は、今構築中のサービスでなりすましたいわけではないでしょ？
　＃名簿を売ったり、別のサービスで換金したいだけかと思います。

・DB項目について、
　クレジットカードを積極的に持つ必要がありますか？

　決済代行会社がクレジットカードを保持してくれるサービスがあります。
　継続課金なども対応できますので、自分で保持することはサービス、ユーザ共にリスクでしか無いので、
　なるべく保持しない方向で検討します。

次にパスワード変更に関してですが、メールの到達性は必ずしも担保されていません。
また、いたずらで第三者がパスワード変更ボタンを押した場合、例にある鈴木さんは、
ログインできなくなってしまいませんか？

ですから、いきなりパスワードを変更してしまうということは、あまりやったことはありません。
それでも行う場合には、別途本人確認が必要になります。２重に本人確認がおきてきるので、
無駄じゃないかなと検討すると思います。


・システムデザイン、DBデザイン、ネットワークとして、漏れないように設計する。（権限とか到達性とか）
・個人情報は極力必要なものだけにする。
・セキュリティ試験を十分行う
・リリースプランにセキュリティ試験も当然組み込む
・ログの設計を見直す
・サービス監視とセキュリティ監視は分けて考える

こうして見てみると、セキュリティに関してはアプリケーション作成時よりも運用側で担保している部分が多いと思いませんか？

たとえですが、「お札を貼ったから、見張りはいらないというセキュリティは無い」ということなんじゃないかと思います。

お札に万能を求めていると、危ないなぁと感じてしまいます。

この回答へのお礼

ご回答ありがとうございます。

>DB項目について、
　クレジットカードを積極的に持つ必要がありますか？

会員制のログインシステムを実装する目的が
・自サイトへ2回以降訪問してくれる常連顧客の入力項目数を削減し受発注を簡易にすることで、顧客の入力作業におけるストレスを軽減する。
・会員制を導入することで顧客の囲いこみを狙う

といったものです。

>決済代行会社がクレジットカードを保持してくれるサービスがあります。
プロジェクト立ち上げ時に検討しましたが、目的の要件を満たさないので見送りました。


>手元にデータがあるわけですから、　後は諦めるまで続けるかどうかになるので、僕は安全とは考えません。

blowfishでsaltを使用したデータを現実的な時間にクラックできるとは私は思えないですが、今回の質問とは話がずれてしまいますので参考までさせていただきます。

その他いろいろとアドバイスいただきまして誠にありがとうございます。

私の質問が多すぎてわかりにくかったので申し訳ないですが
、この質問で私が一番必要としている箇所は

■処理１と処理３のタイミングでパスワード以外のフィールドは一旦復号化して再度暗号化、保存の手順が必要と思うのですが、元の復号キーが不明でも可能でしょうか？
■不可能なら他のサイト運営者はどうしているのでしょうか？平文で保存しているのでしょうか？

この点をご回答いただければ助かります。

お礼日時：2011/06/09 09:01

No.1 回答者： bakayarou_ 回答日時： 2011/06/08 19:34

まず質問者は暗号化をどこでやるかを決めよう。

PHP側でやるのかMySQLの関数を利用するのか。
そういうのを決めて初めて処理の流れを決めることができる。

それとパスワードは暗号化するのには可逆暗号化ではなくて不可逆暗号化を利用しましょう。

この回答へのお礼

ご回答ありがとうございます。

>PHP側でやるのかMySQLの関数を利用するのか。

PHP側でやる予定です。

>それとパスワードは暗号化するのには可逆暗号化ではなくて不可逆暗号化を利用しましょう

もちろんその予定でした。

お礼日時：2011/06/09 08:38