システム会社に会員制サイトを作ってもらって、データベースを見ていたらパスワードが生で表示されていました。それを見て安全性の面で大丈夫かなと感じています。


システムはPHP + Mysqlです。
環境はSSL通信で検索は引っかからないようにしております。
ただし、httpからhttpsへの強制接続切り替え機能はないのでhttp通信も可能です。

サイト自体は検索に引っかからず、存在もユーザー以外には知られないなら大丈夫かなと思いましたが、結構な個人情報を含む内容のデータなので気になっています。

データベースにはユーザー(3000名ほど)とその管理者(50名ほど)、更にその上の総管理者(3名)という3者全てのIDとパスが生で保存されています。

エンジニアの皆さんから見てこの状態って危険でしょうか?
また、これを解消するにはどうするのがよいでしょうか?

システム会社にこのことを訴えるのか、それとも、そもそもそんなことをする会社に訴えかけても無駄だから新しいところに声をかけるべきなのか、そういったアドバイスを頂ければと思います。

回答の条件
  • 1人1回まで
  • 13歳以上
  • 登録:2015/05/06 23:34:16
  • 終了:2015/05/07 18:45:36

ベストアンサー

id:fatena No.4

suinger回答回数126ベストアンサー獲得回数262015/05/07 03:46:41

ポイント67pt

危険です。
パスワードはハッシュ化(暗号化技術利用)をするのが一般的で、実施すべきです。
現行の対応会社に対応依頼を出すとよいです。必須対応となるべき項目です。
対応工数は重くないです。

PHPの公式マニュアルでも提示されているので、以下ご一読ください。
http://php.net/manual/ja/faq.passwords.php
以下一部抜粋です。
====
【なぜ、アプリケーションのユーザーが登録したパスワードをハッシュしなければならないのですか?】
パスワードのハッシュは、最も基本的なセキュリティ要件のひとつです。 ユーザーからパスワードを受け取るアプリケーションを設計するときには必ず考慮しなければなりません。 ハッシュしなければ、パスワードを格納したデータベースが攻撃を受けたときにパスワードを盗まれてしまいます。 それは即時にアプリケーションが乗っ取られることにつながるし、 もしそのユーザーが他のサービスでも同じアカウント・同じパスワードを使っていればさらに被害が大きくなります。

ユーザーのパスワードにハッシュアルゴリズムを適用してからデータベースに格納しておくと、 攻撃者が元のパスワードを知ることが難しくなります。 とはいえ、パスワードのハッシュ結果との比較は可能です。

しかし、ここで注意すべき点は、パスワードのハッシュ処理はあくまでもデータベースへの不正アクセスからの保護にすぎず、 アプリケーション自体に不正なコードを注入される攻撃からは守れないということです。
====

なお、今回は新会社での対応ではなく、現行の会社に依頼するのが良いと思います。
対応会社を変える場合、新会社担当にて現状のシステム解析から入ることになるので時間とお金が大きくかかる為です。

他1件のコメントを見る
id:fatena

なるほど。
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:50
id:Greenisland

ありがとうございます。非常に参考になります。
システム会社には耳の痛い記事かもしれませんが、このページを見せるのが手っ取り早く、彼らにも危機意識を持ってもらえるのかなと思います。

2015/05/07 19:17:25

その他の回答(3件)

id:alfa-gadget No.1

alfa-gadget回答回数254ベストアンサー獲得回数502015/05/06 23:59:41

ポイント25pt

OS やミドルウェアのセキュリティーホールもあるわけですから、パスワードを生で保存するなど今どきでは考えられません。
瑕疵として請負会社に修正を請求すべきです。

最近ではSQLインジェクションの可能性があるシステムを納入した開発会社に瑕疵を認める判決がありました。
http://www.softic.or.jp/semi/2014/5_141113/op.pdf

id:Greenisland

こういった判例もあるんですね、参考になります。

2015/05/07 16:36:46
id:iwaim No.2

iwaim回答回数215ベストアンサー獲得回数192015/05/07 00:11:50

ポイント25pt

内部に悪人がいなくて、漏洩しなければ問題とはならない気もします。ただし、内部の人や外部の人の手で漏洩してしまった場合は、「パスワードが平文で保存されていた」という点で最低限のこともやっていないと責められることになるでしょうね。(漏洩した時点でダメというのは当然ですけど)

どのように修正するにせよ、まずはそのシステム会社に連絡することからはじめた方がよいと思います。考えなしに平文で保存しちゃうようなところは他にも問題がありそうで怖いですけど、もしかしたら「ユーザーがパスワードを問い合わせてきたときには現在のパスワードを知らせる」というような要件があって、仕方無くやっているかもしれないし。

id:Greenisland

やはり内部のユーザーによる漏出も考えられますよね。
パスワード暗号化は最低限の事であるという認識は参考になります。

2015/05/07 16:37:46
id:e_p_i No.3

e_p_i回答回数101ベストアンサー獲得回数112015/05/07 00:27:42

ポイント25pt

使用フレームワークでサポートしてるなら、もしもの時のSQLインジェクション対策にソルト付きで暗号化しておくのが基本かと。「絶対にSQLインジェクションは起きない」という自身があるなら暗号化しなくてもいいですが。
接続はhttpsにすべきです。ユーザ情報が関わる通信は全て。リダイレクトさせる様に言った方が良いかと。
webサイトはドメイン取得をしていなくても一日数十件から数百件の機械的なアタックと思しきアクセスがあるので、注意はしておきましょう。経験上アタックはMySQLAdmin狙いの物が多いのでMySQLAdminは使わないのが基本です。
それ以上は事情が分からないので言いませんが、会員制サイトならhttpsにしておくのが良いかと。

他1件のコメントを見る
id:e_p_i

すいません、恥ずかしながら間違いました。MySQLAdminではなく正にそのphpMyAdminです(mysqladminはmysql本家のツールでした。ボケてました。)。アタック量の半分くらいはphpMyAdmin狙いでした。なので止めるよう言った方がいいと思います。

全てhttps通信にした方が良い理由ですが、もし認証がBASIC認証で行われている場合(これ自体望ましくないのですが)、https通信が切れた部分があるとそのパケットを取得された場合にユーザー名とパスワードが簡単に分かってしまうためです。
BASIC認証されたページにアクセスする場合は都度認証情報を付けたアクセスを行いますが、これがSSLで保護されていない場合、パケットを取得されたら確実にユーザー情報とパスワードが漏れます。(なので認証自体をDigest認証にすべきです)
どうも見た感じ甘い開発が行われている様なので、ここの部分はチェックすべきかと思います。

2015/05/07 18:06:36
id:Greenisland

ありがとうございます。参考にさせて頂きます。

2015/05/07 18:09:55
id:fatena No.4

suinger回答回数126ベストアンサー獲得回数262015/05/07 03:46:41ここでベストアンサー

ポイント67pt

危険です。
パスワードはハッシュ化(暗号化技術利用)をするのが一般的で、実施すべきです。
現行の対応会社に対応依頼を出すとよいです。必須対応となるべき項目です。
対応工数は重くないです。

PHPの公式マニュアルでも提示されているので、以下ご一読ください。
http://php.net/manual/ja/faq.passwords.php
以下一部抜粋です。
====
【なぜ、アプリケーションのユーザーが登録したパスワードをハッシュしなければならないのですか?】
パスワードのハッシュは、最も基本的なセキュリティ要件のひとつです。 ユーザーからパスワードを受け取るアプリケーションを設計するときには必ず考慮しなければなりません。 ハッシュしなければ、パスワードを格納したデータベースが攻撃を受けたときにパスワードを盗まれてしまいます。 それは即時にアプリケーションが乗っ取られることにつながるし、 もしそのユーザーが他のサービスでも同じアカウント・同じパスワードを使っていればさらに被害が大きくなります。

ユーザーのパスワードにハッシュアルゴリズムを適用してからデータベースに格納しておくと、 攻撃者が元のパスワードを知ることが難しくなります。 とはいえ、パスワードのハッシュ結果との比較は可能です。

しかし、ここで注意すべき点は、パスワードのハッシュ処理はあくまでもデータベースへの不正アクセスからの保護にすぎず、 アプリケーション自体に不正なコードを注入される攻撃からは守れないということです。
====

なお、今回は新会社での対応ではなく、現行の会社に依頼するのが良いと思います。
対応会社を変える場合、新会社担当にて現状のシステム解析から入ることになるので時間とお金が大きくかかる為です。

他1件のコメントを見る
id:fatena

なるほど。
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:50
id:Greenisland

ありがとうございます。非常に参考になります。
システム会社には耳の痛い記事かもしれませんが、このページを見せるのが手っ取り早く、彼らにも危機意識を持ってもらえるのかなと思います。

2015/05/07 19:17:25
  • id:TAK_TAK

    それは本当に生のパスワードそのものだったのでしょうか?
    php , mysql ならば、password_hashでハッシュ化した文字列を保存している場合の方が圧倒的に多いと思うのですが

    password みたいな文字列が保存されていたのでしょうか?
    5ehqfKQFfy6UMw4E8ecfic みたいな文字列ではなかったのですか?


  • id:Greenisland
    アンダーソン 2015/05/07 13:58:50
    そうだったらいいのですが、残念ながら生のパスワードです。
    例えば「tak0512」とか「hiroshi1234」とか
    明らかにそれとわかるような文字列ばかりでした。
  • id:iwaim
    念のため書いておきますが、「暗号化」と「ハッシュ」は別の意味になるのでシステム要件の話などをするときは区別した方がよいです。「パスワードは暗号化してデータベースに格納すること」と決まっていたら、通常はハッシュを使うことはありませんし。
  • id:Greenisland
    アンダーソン 2015/05/07 20:27:04
    ご丁寧にありがとうございます。
    正確な意味は理解できておりませんが、別のものとして頭に入れておきます。
  • id:masterkit
    パスワードをhash化しても、SQLぶち込まれてその他見えちゃったとかだと、ログインする必要すらないよね。
    数千件程度のリスト狙いにくるリスク可能性考えたらそこまで気にする案件でもないと思うけど。
    不正アクセスあったらログ見て通報すりゃおkでしょ。
    なんか数千万のユーザー抱えてるシステム並にみなさん高尚な事言ってるけど、発注金額によっちゃ仕方ないレベル。
    難癖つける前にそれなりの金額と事前交渉を用意する方が先なんじゃない?
    生パスワード必須とか最初に言えば済む話、仕様変更するなら金積めよw
  • id:kaidnu2
    DBを見れる力がありながら納入前にどうしてチェックされなかったのでしょうか?受入れ試験には立ち会いましたか?ってことが突っ込まれどころかなと。
    ハッシュはあくまでハッシュであって暗号化されたデータではありません。
    仕事を回すために従来の部品を使い回ししていることは多いので、相手が帰りたいといっても納得できるまで聞くべきでしたね。
    しかし平文はないですね。貴方の上長に報告した上で相手と交渉すべきでしょうね。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません