134

パスワードをハッシュするとき、多くのプログラマーが BCrypt アルゴリズムの使用を推奨していることを読みました。

私は C# でプログラミングしていますが、BCrypt の適切な実装を誰かが知っているかどうか疑問に思っていますか? このページを見つけましたが、偽物かどうかはよくわかりません。

パスワード ハッシュ スキームを選択する際に注意すべきことは何ですか? BCrypt は「良い」実装ですか?

4

2 に答える 2

156

まず、重要ないくつかの用語：

ハッシュ-文字列を取得し、元の文字列に戻すことができない文字のシーケンスを生成する行為。

対称暗号化-（通常は単に「暗号化」と呼ばれます）-文字列を取得し、 暗号化したのと同じ暗号化キーを使用して元の文字列に復号化できる文字列を生成する行為。

レインボーテーブル-特定のハッシュアルゴリズムでハッシュされた文字のすべてのバリエーションを含むルックアップテーブル。

ソルト-ハッシュされる前に元の文字列に追加される既知のランダムな文字列。

.NET Frameworkの場合、Bcryptにはまだ検証済みのリファレンス実装がありません。既存の実装に重大な欠陥があるかどうかを知る方法がないため、これは重要です。BCryptfor.NETの実装はこちらから入手できます。暗号化について、それが良い実装か悪い実装かを言うのに十分なことはわかりません。暗号化は非常に深い分野です。 独自の暗号化アルゴリズムを構築しようとしないでください。真剣に。

独自のパスワードセキュリティ（ため息）を実装する場合は、いくつかのことを行う必要があります。

  1. 比較的安全なハッシュアルゴリズムを使用します。
  2. ハッシュされる前に、各パスワードをソルトします。
  3. パスワードごとに一意の長いソルトを使用し、パスワードとともにソルトを保存します。
  4. 強力なパスワードが必要です。

残念ながら、これをすべて行ったとしても、断固としたハッカーがパスワードを理解する可能性はありますが、非常に長い時間がかかります。それがあなたの最大の敵です：時間。

bcryptアルゴリズムが機能するのは、MD5よりもパスワードのハッシュに5桁長い時間がかかるためです。（そして、AESまたはSHA-512よりもはるかに長い）。これにより、ハッカーはパスワードを検索するためのレインボーテーブルを作成するためにより多くの時間を費やす必要があり、パスワードがハッキングされる危険性がはるかに低くなります。

パスワードをソルトおよびハッシュしていて、各ソルトが異なる場合、潜在的なハッカーは、ソルト+ハッシュされた1つのパスワード用のレインボーテーブルを作成するために、ソルトのバリエーションごとにレインボーテーブルを作成する必要があります。つまり、100万人のユーザーがいる場合、ハッカーは100万のレインボーテーブルを生成する必要があります。すべてのユーザーに同じソルトを使用している場合、ハッカーはシステムを正常にハッキングするために1つのレインボーテーブルを生成するだけで済みます。

パスワードをソルトしていない場合、攻撃者がしなければならないのは、すべての実装（AES、SHA-512、MD5）の既存のRainbowテーブルをプルアップし、ハッシュと一致するかどうかを確認することだけです。これはすでに行われているため、攻撃者はこれらのレインボーテーブルを自分で計算する必要はありません。

これでも、適切なセキュリティ対策を講じる必要があります。サイトで別の攻撃ベクトル（XSS、SQLインジェクション、CSRFなど）を正常に使用できる場合、適切なパスワードセキュリティは重要ではありません。物議を醸す声明のように聞こえますが、考えてみてください。SQLインジェクション攻撃を通じてすべてのユーザー情報を取得できる場合、またはXSSを介してユーザーにCookieを提供してもらうことができる場合は、パスワードがどれほど優れているかは関係ありません。セキュリティはです。

その他のリソース：

  1. Jeff Atwood：.NET暗号化の簡素化（ハッシュの概要に最適）
  2. ジェフ・アトウッド：私はあなたとしてログインしました
  3. ジェフ・アトウッド：おそらくパスワードを間違って保存しているでしょう
  4. ジェフ・アトウッド：スピードハッシュ

注：他の優れたリソースをお勧めしてください。私は何十人もの著者による十数の記事を読んだに違いありませんが、ジェフのようにこの主題についてはっきりと書いている人はほとんどいません。見つけたら記事を編集してください。

于 2010-12-14T04:32:17.450 に答える
77

.NET で BCrypt を使用しないでください。PBKDF2 は、組み込みの .NET フレームワーク実装でそのまま使用する必要があります。これは、 NIST によって推奨されているアルゴリズムであるとともに、.NET で暗号的に検証された唯一の自由に利用できる実装です。

StackId は以前は BCrypt を使用していましたが、まさにこの理由で PBKDF2 に移行しました。

好奇心旺盛な方のために、私たちは PBKDF2 でパスワードをハッシュしています。関連するコードはこちら ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ) で、間接的なレイヤーをいくつか経由しています。以前のイテレーションでは、BCrypt を使用していました。PBKDF2 は .NET フレームワークに組み込まれているため、PBKDF2 に移行しましたが、BCrypt では実装を検証する必要がありました (簡単なことではありません)。

ケビン・モントローズ、2011 年 5 月 27 日

(GitHub のリンクを更新)

編集:暗号用語での検証済みの意味は容易には理解されないようです。検証済みの実装とは、エラーなしで実装されていることが暗号学的に証明されていることを意味します。このコストは、簡単に 20,000 ドル以上に達する可能性があります。私が OpenSSL の調査を行っていたときにこれを思い出し、検証プロセス全体を完了していないと述べているところを読みましたが、完全に検証する必要がある場合は、正しい道を示し、関連するコストについて言及しました. 特定の政府要件には、検証済みの暗号化アルゴリズムの義務が含まれています。

.NET での bcrypt の実装は検証されていません。検証されていない暗号化実装を使用すると、暗号化されたものへのバックドアを許可するなどの意図的な悪意のある障害や、暗号的に安全でないデータをもたらす意図しない実装障害が含まれていないことを完全に確信することはできません。

2014 年編集:検証済みの暗号化アルゴリズムを使用することの必然性に疑問を呈した人は、OpenSSL で悪用されたハートブリード ハックによってもたらされた荒廃を見てください。これは、検証されていない実装を使用するコストです。それは安全です....サーバーのメモリの内容全体を誰かが読み取ることができることがわかるまで。

Heartbleed を導入した変更の作成者である Robin Seggelmann は、「長さを含む変数の検証に失敗した」と述べ、欠陥のある実装を提出する意図を否定しました。Heartbleed の開示に続いて、Seggelmann は 2 番目の側面に焦点を当てることを提案し、OpenSSL は十分な数の人々によってレビューされていないと述べました。

これは未検証の実装の定義です。ほんのわずかな欠陥でも、セキュリティ全体が機能しなくなる可能性があります。

2015 年編集:推奨事項に基づく文言を削除し、絶対文に置き換えました。後世のためにオリジナルのケビン・モントローズのコメントを埋め込みました。

于 2011-06-03T13:59:55.943 に答える