最近パスワードを平文で保存・記録してしまっている事件が発生しているので何故、平文保存・記録をしてしまっているのかをまとめ。
ちなみに「平文（ひらぶん）」と読みます。
パスワードの平文保存・記録事件
最近発生したパスワードの平文保存・記録事件の2件です。
宅ふぁいる便とFacebookです。
事件の詳細については、リンク先を見てください。
平文って何が問題？
パスワードが盗まれてしまった場合、暗号化されていた場合に復号化（暗号解除）するまで時間がかかります。
これにより最悪、パスワードが盗まれても盗まれたデータを使ってログインや他のサイトでログインを試されるまで時間が必要になります。
その間に不正アクセスに気づいた企業は「顧客に不正アクセスの事実の公表・対策とパスワードの変更の依頼」が出来るわけです。
ですが平文で登録されていた場合、NoTimeで不正アクセスし放題となってしまいます。
平文で保存・記録された理由を考える
今回の事件では特に平文で登録・保存されていた経緯については書かれてはいません。
ですが宅ふぁいる便については平文でDBに保存、Facebookについてはログに記録されていたようです。
平分で保存・記録された理由を考えてみました。
DBに平文が登録された理由
DBに平分で登録されていた宅ふぁいる便は1999年06月に誕生したサービスとのこと。
20年近く前からあるサービスですね。
そんな昔からあるサービスなのでおそらく当時「セキュリティの知見がなかった」と考えられます。
今では多くのWeb開発の本や、知識が多く、セキュリティのことも載っていますけど当時の開発の常識にはなかった可能性があります。
平文から暗号化する際の手間を考えて必要なセキュリティ対策を削っていた可能性もあります。
宅ふぁいる便と同様のサービスのオフィス宅ふぁいる便に関しては十分なセキュリティ対策を講じているとあります。
安全なファイル転送|大容量ファイル転送サービス オフィス宅ふぁいる便 | 株式会社オージス総研
宅ふぁいる便は無料、オフィス宅ふぁいる便は有料なので掛けられている工数・予算・環境が別物だったので宅ふぁいる便のセキュリティ対策・チェックが十分ではなかったと思われます。
実話ですが、「パスワードがわからないって問い合わせの時の確認やパスワード変更を直接DBいじって変えたいから暗号化しないで」って言われたことがあります。
パスワードリマインダや変更機能を入れましょうって提案しましたが「工数と予算の関係でやらない」って言われました。
こちらは社内システムで外部接続がないサービスだったため、顧客に再確認して暗号化なしで了承を頂きました。
ログに平文が登録された理由
Facebookの事件ではログに記録されていたとのこと。
パスワードが平文で保存されたログということなので、おそらく通信のログを全て出力していたのではと考えれます。
ログはデバッグの時に主に使いますが、設定でパスワードを含む全ての通信のログを出力していたのが原因だと思われます。
こちらも実話ですが「デバックの時にPOSTやGETのパラメータを知りたいから全ての通信のログを出力する」という機能がありました。
これにより、ログイン時に送信される際のパスワード等の本来保存しては行けないパラメータも保存してしまったのです。
リリース前に気づいて対処されましたが、これでリリースされてしまうとFacebookのように平文でログが出力されていました。
まとめ
パスワードの暗号化は初歩のセキュリティなので皆さん絶対にしましょう！
上記の話は僕の体験ですが、今回の事件と同様のことが発生していた可能性があります。
DBへのパスワードの平文登録は気づきやすいと思いますが、ログの出力に関しては確認が必要なので絶対見てください。
もしデバックのため「パラメータを全て保存する」なんていう機能を作ったら、パスワードやクレジットカード情報などの重要情報が保存されていないことを確認してください！
0 件のコメント :
コメントを投稿