セキュリティで保護されたデータベースに保存されているパスワードを暗号化する必要があるのはなぜですか？

Webサービスがあります。現在、サーバー上のMySQLテーブルにプレーンテキストでパスワードを保存しています。私はこれがベストプラクティスではないことを知っています。それが私がそれに取り組んでいる理由です。

セキュリティで保護されたデータベースに保存されているパスワードを暗号化する必要があるのはなぜですか？誰かが私のデータベースにハッキングすると、全員のパスワードを取得することに気付きます。しかし、誰かが私のデータベースに入った場合、たとえばデータの削除など、他の問題があります。

私が考えることができるシナリオは、あなたがハッキングされているということです。数時間前からデータベースを復元すると、すべてが順調です。ただし、パスワードがプレーンテキストの場合...泥棒はすべてのパスワードを持っているため、すべてリセットする必要があります。ユーザーの面倒。

パスワードが暗号化されている場合は、以前のデータベースに復元するだけで済みます。これは正しい考えですか？

最初に、読み取り/書き込みよりも読み取り専用のアクセス権で自由になっている必要があります。ハッカーがデータにアクセスできても、編集できない可能性があります。

しかし、もっと重要なことは、これはあなたに関するものではありません。誰かがあなたのデータベースへの完全なアクセス権を持っているとあなたが台無しになるかもしれないという事実は無関係です。さらに重要なのは、ユーザーのデータです。

データベースを回復しても、ハッカーはユーザーのアカウントにアクセスできます。

そして、誰が他に何を知っていますか？Googleで同じパスワードを使用するとどうなりますか？またはPayPal？ハッカーが母親の旧姓、またはクレジットカードの最後の4桁にアクセスできる場合はどうなりますか？

それが他のアカウントにそれらを取得したらどうなりますか？ハッカーを過ぎてユーザーサポートシステムを通過して詳細を取得しないでください。

ただ...しないでください。それはユーザーの個人情報であり、それを見る必要はありません。それはあなたの評判でもあります。暗号化します。

編集：1つの追加のコメント、すべての回答とコメントを読むことから将来の読者を救うために...

（最も厳密な意味で）暗号化する場合は、公開キーと秘密キーのペアを使用する必要があります。

より単純で効果的なソリューションは、ランダムな塩とパスワードのハッシュ化です。ハッシュだけでは十分ではありません。ユーザーが共通のパスワードを使用している場合、単純なインターネット検索ですぐに利用できる逆ハッシュテーブルに表示されます。

ハッキングされた場合は、バックアップからサイトを復元して修正できます。 しかし、ハッカーはまだすべてのアカウントのパスワードを持っています！ この出来事の実例が文書化されています（Sony、Linked-in）。パスワードテーブルが適切にハッシュ化され、ソルトされていれば、サービスのセキュリティ保護と復元がはるかに簡単になります。

ハッキングされると想定し、バックアップ戦略を設計し、この前提を念頭に置いて機密データを暗号化することをお勧めします。そして、保護する必要があるのはハッカーだけではありません。不満、不正直、または単に無知な従業員は、プレーンテキストのパスワードを漏らす可能性があります。

ハッシュを使用しないと、パスワードを変更するまですべてのユーザーのアクセスを無効にする必要があります（可能な場合でも、すべてのユーザーにとって大きな頭痛の種になります）。パスワードがハッシュおよびソルトされていた場合、Webサービスを復元できます。攻撃者がユーザーのアカウントにアクセスするのははるかに困難です。

適切にハッシュされソルトされたパスワードは基本的に一方向です。ハッシュされたパスワードからパスワードを簡単に推測することはできません。サービスプロバイダーが推測できないため、リセットすることしかできません。

また、エリンが言ったように、独自のハッシュ（または暗号化）を試みたり、転がしたりしないでください。標準ライブラリを使用します。

しかし、誰かが私のデータベースに入ると、データを削除するなど、他の問題が発生します。

それはあなたが抱えている問題についてではなく、他のすべてのユーザーにそれが引き起こす可能性のある問題についてです。それは、サイトで作業している人々がそこに保存されているデータを悪用する誘惑（またはさらに悪いことに潜在的な責任）を取り除くことです。

人々が異なるシステムで異なるパスワードを使用するべきであるにもかかわらず、現実はそうではないことを参照してください。

...パスワードをハッシュ化するのはとても簡単なので、業界のベストプラクティスに従わない言い訳はありません。

データの削除などの顕著な攻撃は、通常はアマチュアのものであり、心配することはほとんどありません。経験豊富な攻撃者が最初に行うことの1つは、正当なアクセスを取得しようとすることです。そのため、使用した元の脆弱性にパッチを当てても、侵入することができます。彼が望むものを達成します。パスワードをハッシュせずに残すことで、あなたは彼の仕事をはるかに簡単にする可能性があります。また、彼の将来の悪意のある動作を検出して分離することを難しくしました。

また、すべての妥協が完全なシェルアクセスを提供するわけではありません。攻撃者が使用した脆弱性がusersテーブルへの読み取り専用のSQLインジェクションである場合はどうなりますか？パスワードをハッシュ化せずに残しておけば、彼はほぼ完全にアクセスできるようになりました。

これは、ユーザーのデータを保護する責任についての他の回答で示された理由に加えてです。私のポイントは、失うものがあるのはユーザーだけではないということです。

質問自体の誤りについては、ここに回答を投稿する必要があります。パスワードを暗号化する必要があるかどうかを尋ねています。誰もパスワードを暗号化しません。パスワードを暗号化することを唯一の目的とするFirefox SyncやRoboformなどのサービスとプログラムを除き、誰もいません。

定義を見てみましょう。

暗号化では、暗号化とはメッセージ（または情報）をエンコードするプロセスであり、許可された者のみがメッセージを読み取ることができます。

そしてハッシュ：

ハッシュ関数は、任意の長さのデータを固定長のデータにマッピングするアルゴリズムです。

つまり、暗号化は双方向の変換であり、ハッシュは一方向の変換であるため、後で表示するために復号化しない限り、これは暗号化ではありません。

また、塩をハッシュするだけではありません！パスワードをハッシュする前に、このページ全体を読んでください。

OPが現在検討しているハッシュアルゴリズムについては、SHA-384やSHA-512などのハイエンドのSHA-2バリアントをお勧めします。

そして、ハッシュのラウンドを使用するようにしてください。1回ハッシュしないで、複数回ハッシュします。

ログインプロセスをさらに保護するために、このページを読むことを検討してください。

第二に、データベースのセキュリティを十分に確保することはできません。セキュリティホールと常に進化するリスクが常に存在します。マーフィーの法則に従い、常に最悪の事態に備える必要があります。

PDRなりますが、他の点など、すべてのウェブサイトで同じパスワードを使用する人々 、より多くの情報を得るためにソーシャルエンジニアリングを使用して、ハッカーなど：私が言う他に、正確にどのようなもの

ここには重要な原則があります。ユーザーのパスワードを知っているビジネスを持つ人は1人だけです。それがユーザーです。彼らの妻/夫、医者、あるいは司祭でさえありません。

プログラマー、データベース管理者、使用しているサービスを担当するシステム技術者は含まれていません。プログラマーは、ユーザーが実際にパスワードを知っていることを証明する責任を負っているため、これは挑戦を生み出します。

純粋なソリューションは、ユーザーが新しい予測不可能なデータに挑戦し、このデータとパスワードに基づいた応答を返さなければならないメカニズムを持つことです。この実装の1つは、ユーザーにデジタル署名で新しく生成されたデータにデジタル署名するよう求めることであり、アカウントの作成に使用したのと同じ暗号キーペアを使用したことを数学的に証明できます。

実際には、純粋なソリューションにはかなりのクライアント側のインフラストラクチャと処理が必要であり、多くのWebサイトでは、これは多くの場合、保護されるデータには適切ではありません。

より一般的なソリューションは次のとおりです。

アプリケーションでパスワードが最初に受信された時点で、パスワードはハッシュ関数に渡され、アプリケーションのランダムな「塩」値がハッシュ関数に渡されます。

元の文字列はメモリ内で上書きされ、この時点からソルトハッシュはデータベースに保存されるか、データベースレコードと比較されます。

ここでセキュリティを提供する重要な側面は次のとおりです。

1. ハッシュの知識は認証を直接提供しません。
2. ハッシュからパスワードを逆算することは実用的ではありません。
3. 結果のハッシュはユーザー名とパスワードの両方に依存するため、レインボーテーブル（パスワードと計算されたハッシュの長いリスト）の使用はより困難になります。

防御の第2層としてパスワードを「暗号化」する必要があります（実際には、ハッシュの適切な概念のために「ハッシュ」）。これは、データベースの読み取り専用を垣間見る攻撃者がエスカレートするのを防ぐためのものです。それを読み取り/書き込みアクセスに変更し、正確にデータの変更を開始します。読み取り専用の部分的な違反は、現実の世界で発生します。たとえば、読み取り専用のアクセス権を持つアカウントからのSQLインジェクション攻撃や、破棄されたハードディスクまたは古いバックアップテープを収集機から取得するなどです。私はそこでこの主題について長々と書いた。

パスワードをハッシュする適切な方法については、この回答を参照してください。これには、ソルト、イテレーション、そして何よりも、独自のアルゴリズムを発明することは含まれません（手作りの暗号化は災害の確実なレシピです）。

他の人が言ったことは繰り返しませんが、PHP 5.3.8以降を使用している場合は、PHPネイティブbcryptを使用してパスワードを保存する必要があります。これはPHPに組み込まれています。PHP 5.5を使用している場合は、利用可能な最高のパスワード定数を使用できます。また、ライブラリを使用して5.3.8以上を5.5のように動作させることもできます。

Stack Overflow question PHPでパスワードをハッシュするためにbcryptをどのように使用しますか？それを説明し、そこにある他の返信でさらに説明します。これを自分でやろうとしないでください。

その回答に記載されている理由により、私はpdrからの回答に同意します。

以下を追加します。簡単に実行でき、あらゆるアプリケーションのベストプラクティスとして一般に受け入れられているため、実行する必要があります。より具体的には、永続ストレージに書き込む前に、パスワードを常にソルトおよびハッシュする必要があります。ここでは、ソルティングと適切な暗号化ハッシュの選択の重要性に関する適切なリファレンスがあります（いくつかの一般的な言語で無料のソースコードも提供されます）：https : //crackstation.net/hashing-security.htm

少しの余分な開発時間は、ユーザーに提供する保護の価値があり、開発者としての評判に値します。

私が考えることができるシナリオは、あなたがハッキングされているということです。

あなたが考える必要がある別のシナリオ：誰かがあなたのDBA（またはあなたのDBでselectクエリを実行できる他の人）に$ 100、ユーザーのパスワードを与えるために。または、ソーシャルエンジニアがインターンをします。

次に、それらのパスワードを使用して、ユーザーのGmail ...またはコマースサイトにログインします...（人々は...賢くはないので、サイト間で同じパスワードを使用するため）。

次に、激怒したユーザーは、パスワードを公開したことで会社を訴えます。

NOBODY（社内の人を含む）は、プレーンテキストのパスワードを読み取れる必要があります。今まで。そのための正当なビジネス上または技術的な必要性はありません。

1つには、データベース管理者でさえユーザーのパスワードを表示すべきではありません。管理者がパスワードを確認してユーザーのアカウントにログインすることにした場合、それらをハッシュすることでこれを防ぐことができます。

さて、これについて誰もまだ言及していないのは驚くべきことですが、データベースの物理的なセキュリティはどうですか？

世界最高のITセキュリティが設定されている場合でも、ストレージメディアに物理的にアクセスできる人を止めることはできません。今日の午後、チームがスーパーボウルで優勝し、オフィス/ホスティングプロバイダーがいる市内のダウンタウンで小さな暴動が起きた場合はどうなりますか？（米国の2つの大きなIT領域であるシアトルとデンバーのことを考えると、それは無理だとは思いません）。暴徒はあなたの建物にぶつかり、当局が圧倒されている間に、誰かが平文パスワードを含むDBを持つハードウェアの一部をつかみますか？

連邦幹部が現れ、機器を押収すると、高位の幹部が会社でのポジションを使って違法な株式取引を行っていたため、どうなりますか？その後、FRBはこれらのパスワードを使用して顧客を調査しますが、何も問題はありませんでした。それから彼らは、あなたが彼らを無防備にしたことを悟ります。

IT部門が、インターンに古いドライブを「配る」前にスケジュールされた交換を行うときに、DBを保持していた古いRAIDドライブを消去することを忘れると、寮のルームメイトが残されたものを見つけて、彼らができることを見つけたときにどうなりますか？それを販売し、彼らにさかのぼることはありませんか？

DBサーバーがマザーボードを爆破し、ITが新しいサーバーにイメージを復元し、古いサーバーの「死体」がリサイクルヒープに投入されるとどうなりますか。これらのドライブはまだ良好であり、そのデータはまだそこにあります。

まともなアーキテクトは、セキュリティは後でファイアウォールや運用ポリシーを使用して「ボルトオン」するものではないことを知っています。セキュリティは非常に最初から設計の基本的な部分である必要があり、それはパスワードが一方向ハッシュ化され、されることを意味しNEVER（でも独自のデータセンター内）うち暗号化して送信されず、決して回復可能。取得できるものはすべて危険にさらされる可能性があります。

データベースがハッキングされるケースを別にすれば、顧客として、パスワードを知ってほしくないでしょう。リクエストに応じてパスワードを簡単にキャッチできることは知っていますが、好きなときにいつでもクエリを実行できるようになっているのではないという方が良いと感じました。

パスワードがプレーンテキストで保存されている場合、そのパスワードはユーザーおよびそのテーブルにアクセスできるユーザーに知られていることを意味します。ユーザーとパスワードの実装に関する全体的な考えは、プライバシーとセキュリティの両方の理由から、システム内の特定のセッションがその人物に属することを保証することです。

ユーザー名/パスワードが人々のグループによって知られている場合、個人を明確に識別することは役に立たなくなり、個人情報の盗難、詐欺の多くの可能なシナリオを作成します...

そのため、パスワードは非対称暗号化プロトコルを使用して保存されます。これにより、パスワードを読み取れずに検証できるようになります。

この質問には根本的な欠陥があると思います。事実、「安全なデータベース」というものはありません。悪意のあるユーザーがサーバー上の任意のデータにアクセスできるようにするシステムのどこかに欠陥があることを前提とする必要があります。Heartbleedは優れた事例であり、研究者によって気付かれる前に2年以上にわたって悪用されていました。データを保護するための方法をすべて知っているかもしれませんが、サーバーで使用している他のすべてのソフトウェアとそれらがやり取りする複雑な方法を説明することはできません。

誰かがあなたに興味を持った場合、あなたはハッキングされます。そもそもハッキングされるのを防ぐために最善を尽くすことが重要ですが、できるだけ多くのハードルを配置することで、発生した場合の被害を軽減することも重要です。パスワードをハッシュします。設定するのはそれほど難しくはありません。また、ユーザーのプライバシーを真剣に考えないことで、ユーザーに損害を与えています。ヤフー、ソニー、またはターゲットなど、すべてハッキングされた企業よりも、悪意のある攻撃からあなたが何らかの形で保護されていると考えるのはhub慢です。