会社がパスワードを暗号化していない場合の対処
背景
私は、会社がサーバーを保守するのを手伝うことを請け負っています。私はいくつかのマイナーなPHP=プロジェクトに取り組んでいますが、パフォーマンスの問題も調べています。最近では、ハッカーのログをスキャンしています。
これらの人たちは、しばらくの間サーバーを実行しており、私が最後の足でレガシーアプリケーションと呼んでいるものを持っています。マジッククオート、グローバル変数（_$id_を_$_GET['id']_で上書きできるようにする）、場合によっては.htaccessを唯一のセキュリティとして使用し、名前を付けます。セキュリティとプログラミングの悪夢。
私たちは過去にハッキングされており、そのほとんどはSQLインジェクションでした。これはSLEEP(99999999)コマンドを実行し、DOS攻撃として機能します。幸いなことに、彼らは「小さなボビーテーブル」を実行しませんでした、
XKCD： http://xkcd.com/327/
そこで、脆弱なSQLステートメントをmysql_query()（mysqliではない）からPDOトランザクションに書き換えました。 SLEEPとUNIONのクエリも分析しています。これらは使用していませんが、インジェクションにはあります。ここまでは順調ですね。
最新の問題
最近、ユーザーの電子メールアドレスなど、ユーザーのDBのレコードがスパマーによって作成されたと思われるものに変更されていると言われています。
私はそれらの列に_last_modified_列がないことに気付いたので、誰が言うまでもなく、いつ変更されたかさえも知ることができませんでした。そのコラムを追加しましたが、それはほとんど最初のステップではありません。
このテーブルを調べていたところ、パスワードがソルトもハッシュもされておらず、プレーンテキストとして保存されていることに気付きました。
クライアント通信
請負業者として、狂人のように腕を振るうことなく、どのようにして状況全体について彼らにアプローチできますか？何かアドバイス？私は穏やかなアプローチを考えていました、
問題＃1 概要 これが問題である理由 これを修正しないとどうなるか 修正案 問題＃2 概要 これが問題である理由 これを修正しないとどうなるか 修正案
あなたが提案する穏やかなアプローチが最善でしょう。このデータが公開されると、パスワードの再利用により、ほとんどのユーザーがIDの盗難に対して脆弱になることを指摘します。これは、Targetに影響を与えたのと同じ問題であることを指摘するのにかなり良いタイミングです（会社がTargetでないと仮定した場合）。そしてあなたの上司はこれを変更することをかなり受け入れる必要があります。
データの合法性に関して、ユーザー名/パスワードがCCデータ、個人情報などと同じであるとは考えていません。ただし、ユーザーのために持っている情報によって異なる場合があります。私は弁護士ではありません。これらの側面はあなたの啓示の中で最もよく取り上げられ、合法性を判断するために会社の法務部門に持ち込まれる必要があります。
https://en.wikipedia.org/wiki/Information_privacy_law
そしてあなたもあなたを助けるためにこのXKCDを持っています：
これは、あなたがこれでアプローチしようとしている聴衆に本当に依存します。私はあなたが言っているような深刻なセキュリティ問題を抱える会社で働いていましたが、私が彼らにそれを示すまでそれを聞くことを拒否しました。
可能な場合、1つのアプローチは、基本的には、これらのハックですでに発生した可能性のあることを項目化するのと同じように、あなたがやろうとしていることをまとめることです。聴衆が技術者でない場合は、おそらくこれらの妥協がもたらす可能性のあるビジネスコストを指摘する必要があります。明らかにハッキングされたアカウントは、システムの信頼性を低下させ、製品の顧客価値を低下させます。言うまでもなく、ユーザーのプレーンテキストのパスワードと電子メールアドレスを持つ侵害されたシステムは、深刻な波及効果を引き起こす可能性があります。
可能な場合は、次にすべきことはそれを証明することです。このシステムをテスト環境で立てることができる場合は、それを実行してください。次に、アプリケーションのクライアント側からシステムに与えることができる種類の影響をそれらの前で示します。技術者でさえ、これは私にとってかなり説得力があることが証明されています（ただし、彼らは通常、私の場合はまだ行動しませんでした）。
もちろん、あなたが言ったように、あなたは何か対策を講じるべきかどうか、そしてそれを達成するための努力の見積もりを説明する必要があります。一部の場所はとにかく気にしないだけですが、それは彼らがコストを正当化するのに役立ちます。少なくとも、意識を取り除き、自分が試みたことを知って前に進むことができます。
サーバーの保守契約を結んでいる場合、この契約には、オペレーティングシステム、アプリケーションソフトウェア、すべてのデータなどの整合性、セキュリティ、可用性を確保するなどの仕事の説明が含まれている必要があります。サーバーが安全であることを確認するために契約が期待する（そしてあなたに責任を負わせる）漠然としたヒントさえあれば、ビジネスケースをまとめるのに時間を無駄にせず、問題が修正されることを確実にするために良い仕事をします（コード変更のバージョン履歴を保持する前後のバックアップ）。
このような変更が1朝分の作業よりも多くかかるとは思いません。作業に費やした時間を尋ねられた場合は、ジャーナルを保持して、アクションを説明し、正当化できます。契約の範囲内で作業している場合、ここで問題は発生しません。時々、意思決定者の前ですべてのセキュリティを狂わせることはパニックを引き起こすか、最悪の場合、彼らがそれらの問題を気にしていないと彼らがそれを修正しないと言う機会を作り出します。違反！おそらくこれが常に最もビジネスフレンドリーなアプローチであるとは限りませんが、私の専門家の倫理では、自分の注意を引いた責任のあるシステムに暗号化されていないパスワードを残すことはできません。
個人的な経験から、新しい雇用主やクライアントで働き始めるたびに見つける傾向があるので、シナリオと期待を前もって話し合うことで、たとえば、あなたの側で多くのストレスを節約できます。たとえば、私が修正できるセキュリティの問題を見つけたら、喜んでいます。私は先に進み、毎回あなたに会うことなくこの作業を完了し、違反/事件の疑いがあることを通知するだけですか？彼らは彼らの観点から彼らがセキュリティやコンピュータのことについて心配することに興味がないので、彼らはほとんど常にこれにイエスと言うでしょう-それが彼らがあなたを雇った理由です！多分これはあなたが期待していた方法での質問には答えませんが、私はそれが思考の糧を与えることを願っています。よろしくお願いいたします。問題が修正されることを願っています。
確かに、お客様のメールアドレスの変更がすでに発生していて、それが問題と見なされている場合は、パスワードを変更する機能も問題になります。
これで、今後これが発生しないようにDBを十分に保護した場合、誰もがユーザーのパスワードを編集できる可能性は同様に修正され、誰かが今すぐパスワードを読み取れるかどうかを検討するだけで済みます。
もちろん、できる場合、または（nlikelyイベントで）DBを完全に保護していない場合は、パスワードを確実に暗号化する必要があります-方法は？ 「メールアドレスを更新する」問題と同じ状況に置くだけです。これにはアプリケーションの変更が必要かどうか、それが「難しすぎる」問題であるかどうかは、彼らとともに提起する必要がある別の問題です。コードを見て、提案された修正を行う前に、コードを変更するコストがどのくらいになるかを確認してください。