システムはPHP + Mysqlです。
環境はSSL通信で検索は引っかからないようにしております。
ただし、httpからhttpsへの強制接続切り替え機能はないのでhttp通信も可能です。
サイト自体は検索に引っかからず、存在もユーザー以外には知られないなら大丈夫かなと思いましたが、結構な個人情報を含む内容のデータなので気になっています。
データベースにはユーザー(3000名ほど)とその管理者(50名ほど)、更にその上の総管理者(3名)という3者全てのIDとパスが生で保存されています。
エンジニアの皆さんから見てこの状態って危険でしょうか?
また、これを解消するにはどうするのがよいでしょうか?
システム会社にこのことを訴えるのか、それとも、そもそもそんなことをする会社に訴えかけても無駄だから新しいところに声をかけるべきなのか、そういったアドバイスを頂ければと思います。
危険です。
パスワードはハッシュ化(暗号化技術利用)をするのが一般的で、実施すべきです。
現行の対応会社に対応依頼を出すとよいです。必須対応となるべき項目です。
対応工数は重くないです。
PHPの公式マニュアルでも提示されているので、以下ご一読ください。
http://php.net/manual/ja/faq.passwords.php
以下一部抜粋です。
====
【なぜ、アプリケーションのユーザーが登録したパスワードをハッシュしなければならないのですか?】
パスワードのハッシュは、最も基本的なセキュリティ要件のひとつです。 ユーザーからパスワードを受け取るアプリケーションを設計するときには必ず考慮しなければなりません。 ハッシュしなければ、パスワードを格納したデータベースが攻撃を受けたときにパスワードを盗まれてしまいます。 それは即時にアプリケーションが乗っ取られることにつながるし、 もしそのユーザーが他のサービスでも同じアカウント・同じパスワードを使っていればさらに被害が大きくなります。
ユーザーのパスワードにハッシュアルゴリズムを適用してからデータベースに格納しておくと、 攻撃者が元のパスワードを知ることが難しくなります。 とはいえ、パスワードのハッシュ結果との比較は可能です。
しかし、ここで注意すべき点は、パスワードのハッシュ処理はあくまでもデータベースへの不正アクセスからの保護にすぎず、 アプリケーション自体に不正なコードを注入される攻撃からは守れないということです。
====
なお、今回は新会社での対応ではなく、現行の会社に依頼するのが良いと思います。
対応会社を変える場合、新会社担当にて現状のシステム解析から入ることになるので時間とお金が大きくかかる為です。
OS やミドルウェアのセキュリティーホールもあるわけですから、パスワードを生で保存するなど今どきでは考えられません。
瑕疵として請負会社に修正を請求すべきです。
最近ではSQLインジェクションの可能性があるシステムを納入した開発会社に瑕疵を認める判決がありました。
http://www.softic.or.jp/semi/2014/5_141113/op.pdf
こういった判例もあるんですね、参考になります。
内部に悪人がいなくて、漏洩しなければ問題とはならない気もします。ただし、内部の人や外部の人の手で漏洩してしまった場合は、「パスワードが平文で保存されていた」という点で最低限のこともやっていないと責められることになるでしょうね。(漏洩した時点でダメというのは当然ですけど)
どのように修正するにせよ、まずはそのシステム会社に連絡することからはじめた方がよいと思います。考えなしに平文で保存しちゃうようなところは他にも問題がありそうで怖いですけど、もしかしたら「ユーザーがパスワードを問い合わせてきたときには現在のパスワードを知らせる」というような要件があって、仕方無くやっているかもしれないし。
やはり内部のユーザーによる漏出も考えられますよね。
パスワード暗号化は最低限の事であるという認識は参考になります。
使用フレームワークでサポートしてるなら、もしもの時のSQLインジェクション対策にソルト付きで暗号化しておくのが基本かと。「絶対にSQLインジェクションは起きない」という自身があるなら暗号化しなくてもいいですが。
接続はhttpsにすべきです。ユーザ情報が関わる通信は全て。リダイレクトさせる様に言った方が良いかと。
webサイトはドメイン取得をしていなくても一日数十件から数百件の機械的なアタックと思しきアクセスがあるので、注意はしておきましょう。経験上アタックはMySQLAdmin狙いの物が多いのでMySQLAdminは使わないのが基本です。
それ以上は事情が分からないので言いませんが、会員制サイトならhttpsにしておくのが良いかと。
すいません、恥ずかしながら間違いました。MySQLAdminではなく正にそのphpMyAdminです(mysqladminはmysql本家のツールでした。ボケてました。)。アタック量の半分くらいはphpMyAdmin狙いでした。なので止めるよう言った方がいいと思います。
全てhttps通信にした方が良い理由ですが、もし認証がBASIC認証で行われている場合(これ自体望ましくないのですが)、https通信が切れた部分があるとそのパケットを取得された場合にユーザー名とパスワードが簡単に分かってしまうためです。
BASIC認証されたページにアクセスする場合は都度認証情報を付けたアクセスを行いますが、これがSSLで保護されていない場合、パケットを取得されたら確実にユーザー情報とパスワードが漏れます。(なので認証自体をDigest認証にすべきです)
どうも見た感じ甘い開発が行われている様なので、ここの部分はチェックすべきかと思います。
ありがとうございます。参考にさせて頂きます。
危険です。
パスワードはハッシュ化(暗号化技術利用)をするのが一般的で、実施すべきです。
現行の対応会社に対応依頼を出すとよいです。必須対応となるべき項目です。
対応工数は重くないです。
PHPの公式マニュアルでも提示されているので、以下ご一読ください。
http://php.net/manual/ja/faq.passwords.php
以下一部抜粋です。
====
【なぜ、アプリケーションのユーザーが登録したパスワードをハッシュしなければならないのですか?】
パスワードのハッシュは、最も基本的なセキュリティ要件のひとつです。 ユーザーからパスワードを受け取るアプリケーションを設計するときには必ず考慮しなければなりません。 ハッシュしなければ、パスワードを格納したデータベースが攻撃を受けたときにパスワードを盗まれてしまいます。 それは即時にアプリケーションが乗っ取られることにつながるし、 もしそのユーザーが他のサービスでも同じアカウント・同じパスワードを使っていればさらに被害が大きくなります。
ユーザーのパスワードにハッシュアルゴリズムを適用してからデータベースに格納しておくと、 攻撃者が元のパスワードを知ることが難しくなります。 とはいえ、パスワードのハッシュ結果との比較は可能です。
しかし、ここで注意すべき点は、パスワードのハッシュ処理はあくまでもデータベースへの不正アクセスからの保護にすぎず、 アプリケーション自体に不正なコードを注入される攻撃からは守れないということです。
====
なお、今回は新会社での対応ではなく、現行の会社に依頼するのが良いと思います。
対応会社を変える場合、新会社担当にて現状のシステム解析から入ることになるので時間とお金が大きくかかる為です。
なるほど。
PHP5.2ですと、独自で作る方法もありますがphpassを組込むのが早いです。
phpassは小さいライブラリですが強固なパスワードハッシュを簡単に生成してくれます。
▼phpass紹介記事
http://gihyo.jp/dev/serial/01/php-security/0040
▼phpass本家ホームページ
http://www.openwall.com/phpass/
ありがとうございます。非常に参考になります。
システム会社には耳の痛い記事かもしれませんが、このページを見せるのが手っ取り早く、彼らにも危機意識を持ってもらえるのかなと思います。
なるほど。
2015/05/07 19:09:50PHP5.2ですと、独自で作る方法もありますがphpassを組込むのが早いです。
phpassは小さいライブラリですが強固なパスワードハッシュを簡単に生成してくれます。
▼phpass紹介記事
http://gihyo.jp/dev/serial/01/php-security/0040
▼phpass本家ホームページ
http://www.openwall.com/phpass/
ありがとうございます。非常に参考になります。
2015/05/07 19:17:25システム会社には耳の痛い記事かもしれませんが、このページを見せるのが手っ取り早く、彼らにも危機意識を持ってもらえるのかなと思います。