BCryptはC＃で使用するのに適したハッシュアルゴリズムですか？どこで見つけることができますか？[閉まっている]

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

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

パスワードハッシュスキームを選択するときは、何に注意する必要がありますか？BCryptは「良い」実装ですか？

最初に、重要ないくつかの用語：

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

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

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

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

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

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

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

残念ながら、これをすべて行ったとしても、ハッカーがパスワードを見つけ出す可能性はありますが、非常に長い時間がかかります。それはあなたの主な敵です：時間。

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

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

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

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

その他のリソース：

1. Jeff Atwood：.NET Encryption Simplified（ハッシュの概要に最適）
2. ジェフ・アトウッド：私はあなたとしてログインしました
3. ジェフ・アトウッド：おそらくパスワードを正しく保存していない
4. Jeff Atwood：スピードハッシュ

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

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

StackIdは以前にBCryptを使用しており、次の理由によりPBKDF2に移動しました。

それらの好奇心のために、PBKDF2でパスワードをハッシュしています。関連するコードがここにあります（ http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ）、いくつかの間接層があります。以前のイテレーションでは、BCryptを使用していました。.NETフレームワークに組み込まれているためPBKDF2に移動しましたが、BCryptでは実装を確認する必要があります（小さな作業ではありません）。

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

（GitHubの更新されたリンク）

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

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

2014年の編集：検証済みの暗号アルゴリズムを使用することの義務性に疑問を投げかける人のために、OpenSSLで悪用されたハートブレッドハックによって引き起こされた荒廃を見てください。それは未検証の実装を使用するコストです。それは安全です....だれでもサーバーのメモリの内容全体を読み取ることができることがわかるまでは。

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

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

2015編集：推奨ベースの言語を削除し、絶対言語に置き換えました。後世に埋め込まれたオリジナルのKevin Montroseコメント。