暗号化についてはよくわかりませんが、すでに暗号化されているパスワードを暗号化するメリットはありますか? 私は塩について知っていますが、これが行われる前に、それは重要ですか?
5 に答える
ハッシュが一方向の場合、暗号化は双方向です。ハッシュを元に戻すことはできませんが、暗号化された文字列を復号化できます。
シンプルだが良い例の 1 つは、md5 ハッシュ + ソルトを使用することです: MD5('password' + 'random_string') - 使用する PHP または MySQL に関係なく、結果は同じです。したがって、ここにあるのは「passwordrandom_string」のハッシュであり、辞書を使用して一致する可能性はほとんどありません。
したがって、パスワードを確認するたびに、次のことを行います。
if (md5($password . 'random_string') == $hash_from_db)
更新: しかし、セキュリティについて本当に心配している場合 (これは通常、アプリケーションが非常に機密性の高いデータを扱う場合にのみ行う必要があります)、さらに言えば、それについてはクレイジーなパラノイアと狂気があります: インターネット上には多くのハッシュ方法があります. ランダムなソルトを含むものを見つけ(すべてのパスワードにほぼ無制限の量のハッシュを含めることができます)、いくつかの変更を加え、他のハッシュアルゴリズムと組み合わせます-問題は解決しました.
知っておくべきことの1つは、ハッシュが遅いほどうまくいくことがあります。つまり、何らかの方法でログイン試行カウンターにネズミ穴がある場合、ブルートフォース プロセスが本当に遅くなります。
あなたが見ることができる一例 - bcrypt (ハッシュにJavaを使用します)。あなたがそれを使うべきだと言っているのではなく、あなたが探すべきものの例にすぎません。
異なるキーを使用して2 回暗号化することで、いくつかの利点が得られます。たとえば、より弱い暗号で暗号化されたファイルを、その後より強力な暗号と鍵強度で再度暗号化すると、弱い暗号のみを使用するよりも解読が難しくなります。例えは、銀行の金庫室の中に薄っぺらな鍵の箱を置くことです。ただし、一般に、弱い暗号で 2 回暗号化するよりも、強力な暗号で暗号化する方が適切です。
複数の信頼障壁を越える場合など、何かを 2 回暗号化することが適切な場合もあります。たとえば、ファイルをクラウド プロバイダー (信頼できないかもしれません) に送信する前にファイルを暗号化する場合があります。クラウド プロバイダーが別のオフサイト バックアップ会社 (クラウド プロバイダーが信頼していない可能性があります) にファイルを送信する必要がある場合、彼らはファイルを再度暗号化する可能性があります。
そうは言っても、パスワードの場合、パスワードを保存するためのソルトと一緒に強力なハッシュ (sha1 など) を使用した方がよいでしょう。
この質問には、このトピックに関するいくつかの関連する議論があります。リンクされたスレッドで指摘されているように、それは悪い考えであり、潜在的に暗号化を弱める可能性がある場合があるため、何をしようとしているのか本当に確信がない限り、これを行いたくないでしょう.
暗号化の基本的な基礎は、復号化 (非多項式時間) よりも暗号化 (多項式時間) の方が簡単だということです。暗号化が破られる唯一の方法は、次のいずれかまたは両方が true の場合です。
- 暗号化スキームに脆弱性があり、暗号化にかかる多項式時間と、攻撃者が復号化するのにかかると予想される非多項式時間との間のギャップが減少します。
- 誰かがあなたのデータを (非多項式時間で) 復号化するのに十分な計算リソースを持っています。
二重暗号化が実際に問題 1 の可能性を高める場合があるように思われるので、それは危険です。しかし、問題#2は私にとってより大きな問題のようです。アイデアは、十分な計算リソースを持つ攻撃者が私のデータを解読できるということです。これは、私が暗号化したときよりも桁違いに多くの計算リソースを投資して私のデータを解読する意思がある/できることを意味する行為です。
攻撃者が私のデータを復号化するために必要な膨大な計算リソースを持っていることを認めれば、攻撃者がその 2 倍のリソースを持っている可能性があるという考えは、私にはまったく不合理に思えません。
また、同じキーを使用している場合、追加のセキュリティはまったくないことにも注意してください。一方がクラックされると、両方がクラックされたことになります。いずれかの暗号化方式で発生する問題 #1 から保護するために、2 つの異なるキーを使用して 2 つの異なる暗号化技術を使用して何かを暗号化することには価値がある可能性がありますが、それは確かに議論の余地があります。
暗号化の意味によって異なります。Microsoft の SQL Server 暗号化エンジンなどを使用してデータベース上の情報を実際に暗号化している場合は、問題ありません。データベース レベルの暗号化は安全ではないため、これに依存しないでください。キーは引き続きマシンに保存され、データベースと一緒にそのキーを探し出さない単純な攻撃者を防ぐだけです。
通常、データベースが暗号化されている場合、データベースはプレーンテキストでのデータのエクスポートもサポートします。これは、攻撃者がシステムに侵入した場合、それを実行できることを意味します。彼らがハードドライブしか持っていない場合(外付けドライブが盗まれた場合)、それはあなたを救います.
通常、パスワードはアプリケーションでハッシュしてからデータベースに送信する必要があります。64 バイトのソルトを生成してから、バイナリ連結を示すSHA-512(salt || password)
whereを使用することは安全であると考えられています。ランダム化された ASCII テキストをソルトに使用せず、または Microsoft のなどの安全な乱数ジェネレーターを使用してください。これにより、攻撃者は一般的なパスワードの逆引き用に事前に計算されたハッシュのリストを保存できなくなります。||
/dev/urandom
CryptGenRandom
盗まれたバックアップ ドライブのシナリオを防ぎたい場合は、データベースをバックアップし、暗号化を維持し、暗号化されたデータベースから離れた安全な環境にキーを保存することも確認する必要があります。これを「鍵と鍵の分離」と呼んでいます。これは、データベースがエクスポートされている状況では役に立たないため、前述のようにハッシュも行う必要があります。暗号化に加えてハッシュを使用すると、1.) 攻撃者は名前やアドレスなどの機密性の低い他の情報を取得できなくなり、2.) 攻撃者はパスワードやその他の資格情報の回復を試みることさえできなくなります。
肝心なのは、脅威モデルに依存するということです。
はい。それは問題である。機密データを平文でどこにでも保存することは、悪い習慣を超えています。危ないです。標準の md5 ハッシュでさえ、現在は「壊れている」と見なされており、ソルトせずに単独で使用したり、他のハッシュの組み合わせを併用したりしないでください。物事を揺さぶるためだけに。
$salt = 'Yh%Gg^!&ud$*';
$encryption = md5(sha1($salt.md5(md5($salt.$_POST['pwd']))));
$query = mysql_query("SELECT * FROM users WHERE name=$uname AND pass=$encryption");
最も安全というわけではありませんが、誰かがテーブル情報を手に入れたとしても、ソルトとハッシュの組み合わせを知らなければクラックすることはできません。
最終的には、データの機密性に基づいて知識に基づいた決定を下す必要があります。あらゆる種類のユーザーパスワードを保存している場合、あなたでさえそれらが何であるかを知っているべきではありません.