安全なデータベースに保存されているパスワードを暗号化する必要があるのはなぜですか？
Webサービスを利用しています。現在、サーバー上の MySQL テーブルにパスワードをプレーンテキストで保存しています。これはベストプラクティスではないことを知っているので、私はそれに取り組んでいます。
安全なデータベースに保存されているパスワードを暗号化する必要があるのはなぜですか？誰かが私のデータベースにハッキングした場合、彼らは全員のパスワードを入手することを理解しています。しかし、データの削除など、誰かが私のデータベースにアクセスした場合、他の問題があります。
私が考えられるシナリオは、あなたがハッキングされているというものです。あなたは数時間前からデータベースを復元し、すべてが順調です。ただし、パスワードがプレーンテキストの場合...泥棒にはすべてのパスワードがあり、すべてリセットする必要があります。ユーザーの手間。
パスワードが暗号化されている場合は、以前のデータベースに復元できます。これは正しい考えですか？
まず、読み取りと書き込みよりも読み取り専用のアクセス権を使用するほうが自由です。ハッカーがあなたのデータにアクセスできても、編集できない可能性があります。
しかし、もっと重要なのは、これはあなたについてではありません。 誰かがあなたのデータベースへの完全なアクセス権を持っているなら、あなたが台無しになるかもしれないという事実は無関係です。さらに重要なのは、ユーザーのデータです。
データベースを回復しても、ハッカーは引き続きユーザーのアカウントにアクセスできます。
そして誰が他に何を知っていますか？ Googleで同じパスワードを使用している場合はどうなりますか？またはPayPal？ハッカーが母親の旧姓、またはクレジットカードの下4桁にアクセスできるとしたらどうでしょう。
それらが他のアカウントに入るとどうなりますか？ ユーザーサポートシステムにアクセスして詳細情報を取得する を通過するようにハッカーを通過しないでください。
ただ...ただしないでください。これはユーザーの個人情報であり、表示する必要はありません。それはあなたの評判でもあります。暗号化します。
編集：将来の読者がすべての回答とコメントを読むのを防ぐために、1つの追加コメント...
（厳密な意味で）暗号化する場合は、 公開/秘密鍵のペア を使用する必要があります。
より簡単で効果的な解決策は、 ランダム-ソルト および ハッシュ パスワードを使用することです。ハッシュだけでは十分ではありません。ユーザーが共通のパスワードを使用している場合は、簡単なインターネット検索ですぐに利用できるリバースハッシュテーブルに表示されます。
ハッキングされた場合は、バックアップからサイトを復元して修正できます。 しかし、ハッカーはまだ全員のアカウントのパスワードを持っています！これが起こっていることの文書化された実例（Sony、Linked-in）があり、パスワードテーブルが適切にハッシュ化およびソルト処理されていれば、サービスの迅速な保護と復元ははるかに簡単でした。
ハッキングされることを想定してバックアップ戦略を設計し、この想定を念頭に置いて機密データを暗号化することをお勧めします。そしてそれはあなたが防御する必要があるハッカーだけではありません。不満、不正、または無知な従業員がプレーンテキストのパスワードを渡す可能性があります。
ハッシュ化しないと、パスワードを変更するまで全員のアクセスを無効にする必要があります（可能な場合でも、全員にとって大きな問題になります）。パスワードがハッシュ化およびソルト処理されている場合、Webサービスを復元でき、攻撃者がユーザーのアカウントにアクセスすることははるかに困難になります。
適切にハッシュおよびソルト処理されたパスワードは、基本的に一方向です。ハッシュされたパスワードからパスワードを簡単に推測することはできません。あなたも、サービスプロバイダーはそれを推測できないため、リセットすることしかできません。
また、エリンが言ったように、独自のハッシュ（または暗号化）を試して転がしてはいけません。標準ライブラリを使用します。
しかし、誰かが私のデータベースに入った場合、つまりデータを削除する場合、他の問題があります。
あなたが抱えている問題についてではなく、他のすべてのユーザーにとってそれが引き起こすかもしれない問題についてです。これは、サイトで作業している人々がそこに格納されているデータを悪用する誘惑（またはさらに悪いことに、潜在的な責任）を取り除くことです。
人々が異なるシステムで異なるパスワードを使用するべきであるべきであるにもかかわらず、実際はしないでくださいです。
...そしてパスワードをハッシュするのはとても簡単なので、業界のベストプラクティスに従わないことの言い訳はありません。
データの削除などの顕著な攻撃は通常アマチュアのものであり、あなたの心配の中で最も少ないです。経験豊富な攻撃者が最初に行うことの1つは、正当なアクセスを取得しようとすることです。そのため、彼が使用した元の脆弱性にパッチを適用したとしても、侵入することができます。彼が望むものを達成します。パスワードをハッシュ化しないままにしておくと、彼の仕事がずっと簡単になる可能性があります。また、彼の将来の悪意のある動作を検出して隔離することも難しくしました。
また、すべての妥協が完全なシェルアクセスを提供するわけではありません。攻撃者が使用した脆弱性がusersテーブルに対する読み取り専用のSQLインジェクションである場合はどうなりますか？パスワードをハッシュ化せずに残しておくだけで、ほとんど完全なアクセス権が与えられました。
これは、ユーザーのデータを保護する責任について他の回答が示した理由に加えてです。私の要点は、失うものを持っているのはユーザーだけではないということです。
質問自体の誤りについてここに回答を投稿する必要があります。パスワードを暗号化するかどうかを尋ねています。パスワードを暗号化する人はいません。パスワードの暗号化のみを目的とするFirefox SyncやRoboformなどのサービスやプログラムを除いて、誰も使用できません。
定義を見てみましょう：
暗号化では、暗号化とは、許可された者だけがメッセージを読み取ることができるようにメッセージ（または情報）をエンコードするプロセスです。
そしてハッシュ：
ハッシュ関数は、任意の長さのデータを固定長のデータにマップする任意のアルゴリズムです。
言い換えると、暗号化は双方向変換であり、ハッシュは一方向変換であるため、復号化しない限り後で表示してください。これは暗号化ではありません。
また、ハッシュするだけではなく、salt！ パスワードをハッシュ化する前に、このページ全体をお読みください。
OPが現在検討しているハッシュアルゴリズムについては、SHA-384やSHA-512などのハイエンドSHA-2の変種を提案します。
そして、ハッシュのラウンドを使用することを確認してください。 1回ハッシュしないでください。複数回ハッシュしてください。
ログインプロセスをより安全にするために このページ を読むことを検討してください。
第二に、データベースが十分に安全になることはありません。常にセキュリティホールと進化し続けるリスクがあります。マーフィーの法則に従い、常に最悪の事態に備える必要があります。
pdrが作成するその他のポイント は、私が他に何を言っているかです。すべてのWebサイトに同じパスワードを使用する人々、ソーシャルエンジニアリングを使用してより多くの情報を取得するハッカーなど。
ここで問題となっている重要な原則があります。ユーザーのパスワードを知っているビジネスを持っている人は1人だけです。それがユーザーです。彼らの妻/夫、彼らの医者、あるいは彼らの司祭でさえ。
これには、プログラマ、データベース管理者、または使用しているサービスを担当するシステム技術者は含まれていません。プログラマーは、ユーザーが実際にパスワードを知っているという証明を受け取る責任があるため、これは課題を引き起こします。これは、純粋な方法で解決するのは簡単な問題です。
純粋な解決策は、ユーザーが新しい予測できないデータでチャレンジされ、このデータとパスワードに基づく応答を返す必要があるメカニズムを持つことです。この実装の1つとして、新しく生成されたデータにデジタル署名でデジタル署名するようユーザーに依頼し、アカウントを最初に作成したときに使用したものと同じ暗号化キーペアを使用したことを数学的に証明できます。
実際には、純粋なソリューションにはクライアント側のインフラストラクチャと処理が必要であり、多くのWebサイトでは、保護されているデータに適さないことがよくあります。
より一般的な解決策は次のとおりです。
アプリケーションでパスワードが最初に受信された時点で、パスワードがハッシュ関数に渡され、アプリケーションのランダムな「塩」値がハッシュ関数に渡されます。
次に、元の文字列がメモリに上書きされ、この時点から、ソルトハッシュがデータベースに保存されるか、データベースレコードと比較されます。
ここでセキュリティを提供する主な側面は次のとおりです。
- ハッシュの知識は直接認証を提供しません。
- ハッシュからのパスワードの逆計算は非現実的です。
- 生成されるハッシュはユーザー名とパスワードの両方に依存するため、Rainbowテーブル（パスワードとその計算されたハッシュの長いリスト）の使用はさらに難しくなります。
パスワードを2番目の防御層としてパスワードを「暗号化」する（実際には「ハッシュ」、適切なハッシュの概念です）：これは、データベースを読み取り専用で垣間見た攻撃者がそれを読み取り/書き込みアクセスにエスカレートすることを防ぎ、正確にはデータの変更を開始します。読み取り専用の部分的な違反は、現実の世界で発生します。読み取り専用アクセス権を持つアカウントからのSQLインジェクション攻撃、または破棄されたハードディスクまたは古いバックアップテープを収集から取得する。私はこの問題について詳しく書きました there 。
パスワードをハッシュする適切な方法については、 この答え を参照してください。これにはソルト、イテレーション、そして何よりも独自のアルゴリズムの発明ではありません（自家製の暗号化は災害の確実なレシピです）。
私は他の人が言ったことを繰り返さないが、あなたが [〜＃〜] php [〜＃〜] 5.3.8以上を持っていると仮定すると、PHPネイティブbcryptパスワードを保存します。これはPHPに組み込まれています。PHP 5.5を使用している場合は、利用可能な最良のパスワード定数を使用できます。また、 5.3.8以上を5.5のように動作させるライブラリ。
スタックオーバーフローの質問PHPでパスワードをハッシュするためにbcryptをどのように使用しますか？がそれを説明し、他の返信で詳細を説明しています。これを自分でやろうとしないでください。
その回答に述べられている理由から、私はpdrからの回答に同意します。
私は以下を追加します：それは簡単であり、一般にあらゆるアプリケーションのベストプラクティスとして受け入れられているため、実行する必要があります。より具体的には、永続ストレージに書き込む前に、パスワードは常にソルト化およびハッシュ化する必要があります。以下は、ソルティングと適切な暗号化ハッシュの選択の重要性に関する優れたリファレンスです（これにより、いくつかの一般的な言語で無料のソースコードも提供されます）。 https://crackstation.net/hashing-security.htm
わずかな追加の開発時間は、ユーザーに提供する保護と、開発者としてのあなたの評判にとって十分価値があります。
まず、データベース管理者でさえユーザーのパスワードを見るべきではありません。それらをハッシュすると、管理者がパスワードを確認してユーザーのアカウントにログインする場合に、これを防ぐことができます。
私が考えられるシナリオは、あなたがハッキングされているというものです。
あなたが考える必要がある別のシナリオ：誰かがDBA（または他の人がDBで選択クエリを実行できる人）を100ドル落として、ユーザーのパスワードを与えました。またはソーシャルエンジニアがそれを行うためのインターンです。
次に、それらのパスワードを使用して、ユーザーのGmail ...または商取引サイトにログインします（人々は...賢いとは言えないため、サイト間で同じパスワードを使用します）。
次に、怒りのユーザーは、パスワードを公開したとしてあなたの会社を訴えます。
NOBODY（社内の人々を含む）はプレーンテキストのパスワードを読み取ることができる必要があります。ずっと。そのための正当なビジネス上または技術上のニーズはありません。
まあ、それはまだ誰もこれについて言及していないのは驚くべきことですが、データベースの[〜＃〜] physical [〜＃〜]セキュリティはどうですか？
あなたは世界最高のITセキュリティを設定しているかもしれませんが、それはあなたのストレージメディアへの物理的なアクセスを得ることができる人を止めません。あなたのチームが今日の午後にスーパーボウルに勝ち、小さな暴動があなたのオフィス/ホスティングプロバイダーがいるあなたの街のダウンタウンエリアで噴火するとどうなりますか？ （それが米国の2つの大きなIT分野であるシアトル対デンバーであるとすれば、それは不合理ではないと思います）。暴徒があなたの建物に衝突し、当局が圧倒されている間に、誰かがあなたのハードウェアの一部に、平文のパスワードが含まれているDBを持っていますか？
一部の高級幹部が会社での彼の立場を利用して違法な株式取引を行っていたために、FRBが現れてあなたの機器を押収した場合はどうなりますか？その後、FRBはそれらのパスワードを使用して顧客を調査しますが、顧客は何も間違っていませんでした。その後、彼らはそれが脆弱であることが[〜＃〜]あなた[〜＃〜]であることに気付きました。
IT部門が、古いドライブをインターンに「配付」する前に定期交換を行うときに、DBを保持していた古いRAIDドライブを消去するのを忘れ、その後、寮のルームメートが残っているものを見つけて、何ができるかを把握した場合、どうなりますか。それを売る」と彼らにさかのぼることはありませんか？
DBサーバーがマザーボードをブローし、ITが新しいサーバーにイメージを復元し、古いサーバーの「死体」がリサイクルヒープに投入されるとどうなりますか？それらのドライブはまだ良好であり、そのデータはまだそこにあります。
適切なアーキテクトであれば、セキュリティはファイアウォールや運用ポリシーを使用して後で「強化」するものではないことを知っています。セキュリティは設計の最初から基本的な部分でなければなりません。つまり、パスワードは一方向にハッシュされます[〜＃〜]決して[〜＃〜]暗号化なしで送信され（自分のデータセンター内であっても）、決して回復できません。取得できるものはすべて侵害される可能性があります。