会社がパスワードを暗号化しない場合の対処方法

バックグラウンド

会社がサーバーを保守するのを手伝う契約をしています。私はいくつかのマイナーなPHPプロジェクトに取り組んでいますが、パフォーマンスの問題を調べ、最近ではハッカーのログをスキャンしています。

これらの人々はしばらくの間サーバーを実行しており、その最後の部分にレガシーアプリケーションと呼ぶものがあります。マジッククオート、グローバル変数（で$id上書き可能$_GET['id']）を使用し、.htaccessを唯一のセキュリティとして使用する場合があります。セキュリティとプログラミングの悪夢。

私たちは過去に、主にSQLインジェクションでハッキングされました。SQLインジェクションはSLEEP(99999999)コマンドを実行し、DOS攻撃として機能します。幸いなことに、彼らは「小さなボビーテーブル」を実行しませんでした。

XKCD：http ://xkcd.com/327/

そのため、脆弱なSQLステートメントをmysql_query()（mysqliではなく）PDOトランザクションに書き直しました。私はまたのためのクエリを分析していますSLEEPとUNION、我々が使用しないが、注射は持っています。ここまでは順調ですね。

最新号

最近、電子メールアドレスがスパマーによって作成されたと思われるものに変更されるなど、ユーザーのDBのレコードが変更されていると言われています。

彼らの列には列がないことに気づいたlast_modifiedので、誰が言うまでもなく、いつ変更されたかさえ知ることができませんでした。私はそのコラムを追加しましたが、それはかろうじて最初のステップです。

このテーブルを見ると、パスワードがソルト化されておらず、ハッシュ化されておらず、プレーンテキストとして保存されていることがわかりました。

クライアント通信

請負業者として、狂人のように腕を振り回すことなく、状況全体についてどのようにアプローチできますか？何かアドバイス？私は穏やかなアプローチを考えていました、

    問題＃1
        あらすじ
        これが問題である理由
        これが修正されない場合に何が起こるか
        修正案

    問題＃2
        あらすじ
        これが問題である理由
        これが修正されない場合に何が起こるか
        修正案
        

あなたが提案する穏やかなアプローチが最善でしょう。このデータが公開されると、ほとんどのユーザーはパスワードの再利用による個人情報の盗難に対して脆弱になることを指摘します。これは、これがTargetに影響を与えたのと同じ問題であることを指摘するのに非常に良い時間です（会社がTargetでないと仮定して）。そして、あなたのマネージャーはこれを変えることにかなり敏感であるべきです。

データの合法性に関しては、ユーザー名/パスワードがCCデータ、個人情報などと同じであるとは考えていません。ユーザーのために持っている情報によって異なりますが。私は弁護士ではありません。これらの側面はあなたの啓示で最もよく持ち出され、合法性を決定するためにあなたの会社の法務部に持ち込まれるべきです。

https://en.wikipedia.org/wiki/Information_privacy_law

そして、あなたもあなたを助けるためにこのXKCDを持っています：

それは本当にあなたがこれにアプローチしようとしている聴衆に依存します。私はあなたが述べているように深刻なセキュリティ問題を抱えている会社で働いていますが、彼らが私にそれを示すまでそれを聞くことを拒否しました。

実行可能な場合、1つのアプローチは、これらのハックですでに発生している可能性のあることを箇条書きとして、基本的にあなたがやろうとしていることをまとめることです。聴衆が技術的でない場合、おそらくこれらの妥協がもたらすビジネスコストを指摘する必要があります。アカウントがハッキングされると、システムの信頼性が低下し、製品の顧客価値が低下します。ユーザーのプレーンテキストパスワードと電子メールアドレスを使用したシステムの侵害は言うまでもなく、深刻な波及効果を引き起こす可能性があります。

可能な場合、次にすべきことはそれを証明することです。このシステムをテスト環境で立ち上げることができる場合は、実行してください。次に、それらの前で、アプリケーションのクライアント側からシステムに与える影響の種類を示します。技術者でも、これは私にとってかなり説得力があることが証明されています（ただし、彼らはまだ私の場合は通常行動しませんでした）。

もちろん、あなたが言ったように、どのような対策を講じるべきかを説明し、それを達成するための努力を見積もる必要があります。いくつかの場所は単にとにかく気にしませんが、それは彼らがコストを正当化するのに役立ちます。少なくともあなたは意識をクリアし、あなたが試したことを知って前進することができます。

サーバーのメンテナンスを契約していると言う場合、この契約には、オペレーティングシステム、アプリケーションソフトウェア、およびすべてのデータの整合性、セキュリティ、可用性の確保などのジョブ記述タスクを必ず含める必要があります。サーバーが安全であることを確認するために契約が期待している（そしてあなたに責任を負わせる）漠然としたヒントさえあれば、ビジネスケースをまとめる時間を無駄にせず、問題が修正されたことを確認するのに良い仕事をしますコード変更のバージョン履歴を保持する前後のバックアップ）。

このような変化が朝の仕事以上にかかるとは思わないでしょうし、あなたが何に時間を費やしてきたのかと聞かれたら、あなたの行動を説明し正当化するために日記をつけることができます。契約の範囲内で作業している場合は、ここで問題は発生しません。意思決定者の前ですべてのセキュリティを狂わせることはパニックを引き起こしたり、最悪の場合、それらの問題を気にしないと言う機会を作成するので、それを修正しないでください。違反！おそらくこれは常に最もビジネスに優しいアプローチではないかもしれませんが、私の職業倫理は、私がこれまで気づいたことに責任を負ったどのシステムにも暗号化されていないパスワードを残してはいけません。

個人的な経験から、新しい雇用主やクライアントのために働き始めるたびに見つける傾向があり、シナリオや期待を前もって議論することで、あなたの側に多くのストレスを節約できます。毎回あなたに会わずに、この作業を完了して、違反/インシデントの疑いがある場合にのみ通知するようにしますか？彼らはほとんど常にこれに賛成だと思うでしょう。なぜなら彼らの観点からは、彼らはセキュリティやコンピューターのことを心配することに興味がないからです-だから彼らはあなたを雇ったのです！おそらく、これはあなたが期待していた方法で質問に答えていないかもしれませんが、私はそれが思考の糧を与えることを望みます。どうぞよろしくお願いします。問題が修正されることを願っています。

顧客の電子メールアドレスの変更が既に行われていて、それが問題と見なされている場合は、パスワードを変更する機能も問題です。

これで、将来これが発生しないようにDBを十分に保護した場合、誰でもユーザーのパスワードを編集できる可能性が同様に修正され、誰かがすぐにパスワードを読むことができるかどうかを考慮するだけで済みます。

もちろん、もし可能であれば、または（万が一）DBを完全に保護していない場合は、パスワードを確実に暗号化する必要があります。「メールアドレスが更新された」という問題と同じコンテキストに置いてください。これにアプリケーションの変更が必要かどうか、およびそれが「難しすぎる」問題であるかどうかは、彼らと共に提起する必要がある別の問題です。コードを見て、修正を提案する前に、コードの変更にかかる費用を確認してください。