BCryptはC＃で使用するのに適したハッシュアルゴリズムですか？どこで見つけることができますか？
私は、パスワードをハッシュするとき、多くのプログラマーがBCryptアルゴリズムの使用を推奨していることを読みました。
私はC＃でプログラミングしていますが、BCryptの優れた実装を知っている人がいるかどうか疑問に思っていますか？ このページ を見つけましたが、それが偽物かどうかはわかりません。
パスワードハッシュスキームを選択する際に注意すべきことは何ですか？ BCryptは「良い」実装ですか？
まず、重要ないくつかの用語：
Hashing-文字列を取得し、元の文字列に戻すことができない文字のシーケンスを生成する行為。
対称暗号化-（通常は単に「暗号化」と呼ばれます）-文字列を取得し、シーケンスを生成する行為を暗号化した同じ暗号化キーを使用して元の文字列に復号化できる文字。
レインボーテーブル-特定のハッシュアルゴリズムでハッシュされた文字のすべてのバリエーションを含むルックアップテーブル。
Salt-ハッシュされる前に元の文字列に追加される既知のランダム文字列。
.NET Frameworkの場合、Bcryptにはverified参照実装がまだありません。既存の実装に重大な欠陥があるかどうかを知る方法がないため、これは重要です。 ここでの.NETのBCrypt の実装を取得できます。暗号化については、実装が良いか悪いかを判断するのに十分な知識がありません。暗号化は非常に深い分野です。 独自の暗号化アルゴリズムを構築しようとしないでください。真剣に。
独自のパスワードセキュリティ（ため息）を実装する場合、いくつかのことを行う必要があります。
- 比較的安全なハッシュアルゴリズム を使用します。
- ハッシュされる前に各パスワードをソルトします。
- 各パスワードに固有の長いソルト を使用し、ソルトをパスワードとともに保存します。
- 強力なパスワードが必要です。
残念ながら、このすべてを実行したとしても、決意のあるハッカーはパスワードを潜在的に把握できる可能性がありますが、彼には本当に長い時間がかかります。それがあなたの主な敵です：時間。
bcryptアルゴリズムは、MD5よりもパスワードをハッシュするのにfive桁長い時間がかかるため、機能します ; （それでもAESやSHA-512よりはるかに長いです）。ハッカーは、Rainbowテーブルを作成してパスワードを検索するのにより多くの時間を費やすことを余儀なくされ、パスワードがハッキングされる危険性がはるかに低くなります。
パスワードをソルトおよびハッシュし、各ソルトが異なる場合、 潜在的なハッカーはソルトのバリエーションごとにレインボーテーブルを作成する必要があります ハッシュ化されたパスワード。つまり、ユーザーが100万人いる場合、ハッカーは100万のレインボーテーブルを生成する必要があります。すべてのユーザーに同じソルトを使用している場合、ハッカーはシステムを正常にハッキングするために1つのRainbowテーブルを生成するだけで済みます。
パスワードをソルトしていない場合、攻撃者がしなければならないことは、実装（AES、SHA-512、MD5）ごとに既存のRainbowテーブルを取得し、ハッシュと一致するかどうかを確認することです。これは 既に行われている 、攻撃者はこれらのRainbowテーブル自体を計算する必要はありません。
これだけでも、 適切なセキュリティ対策を講じる必要があります 。サイトで別の攻撃ベクトル（XSS、SQLインジェクション、CSRF、 et。al。 ）を正常に使用できる場合、良好なパスワードセキュリティは重要ではありません。物議を醸す声明のように聞こえますが、考えてみてください。SQLインジェクション攻撃ですべてのユーザー情報を取得できる場合、またはXSSでユーザーにCookieを提供できる場合は、 それは問題ではありませんパスワードセキュリティの質 。
その他のリソース：
- ジェフ・アトウッド： 。NET Encryption Simplified （ハッシュの概要に最適）
- ジェフ・アトウッド： あなたと同じようにログインしました
- ジェフ・アトウッド： おそらくパスワードを間違って保存しています
- ジェフ・アトウッド： Speed Hashing
注：他の適切なリソースを推奨してください。私は何十人もの著者によるダースの記事を読んだに違いありませんが、ジェフのように主題についてはっきりと書いている人はほとんどいません。記事を見つけたら編集してください。
.NETでBCryptを使用しないでくださいmust usePBKDF2は、組み込みの.NETフレームワーク実装と同様に使用する必要があります。これは、 NISTが推奨するアルゴリズム であるとともに、.NETで唯一自由に利用できる暗号で検証された実装です。
StackIdは以前、BCryptを使用し、まさにこの理由でPBKDF2に移行しました。
好奇心those盛な方のために、PBKDF2でパスワードをハッシュしています。 Relaventコードはここにあります（ http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ）、間接的ないくつかのレイヤーを介しています。以前の反復では、BCryptを使用していました。 .NETフレームワークに組み込まれているためPBKDF2に移行しましたが、BCryptでは実装を確認する必要があります（小さな仕事はありません）。
Edit：暗号用語でのverifiedの意味は容易に理解できないようです。 。これのコストは、簡単に20,000ドル以上に達する可能性があります。 OpenSSLの調査を行っていたとき、これを思い出し、検証プロセス全体を完了していないと述べている箇所を読みましたが、完全に検証する必要がある場合は、正しい道筋を示し、関連するコストについて言及しました。特定の政府の要件には、検証済み暗号化アルゴリズムの義務が含まれています。
.NETのbcrypt実装は検証されていません。検証されていない暗号化の実装を使用すると、暗号化されたものへのバックドアの許可などの意図的な悪意のあるフォールトや、暗号的に安全でないデータをもたらす意図しない実装フォールトが存在しないことを完全に確信することはできません。
2014 edit：検証された暗号アルゴリズムを使用することの必須性に疑問を持っている人は、OpenSSLで悪用された heartbleed hack によって引き起こされた破壊を見てください。それは未検証の実装を使用するコストです。それは安全です...あなたがだれでもあなたのサーバーの全メモリ内容を読むことができるとわかるまで。
Heartbleedを導入した変更の著者であるRobin Seggelmannは、「長さを含む変数の検証に失敗した」と述べ、欠陥のある実装を提出する意図を否定しました。 Heartbleedの開示に続いて、Seggelmannは、OpenSSLが十分な人々によってレビューされていないと述べて、2番目の側面に注目することを提案しました。
これは未検証の実装の定義です。わずかな欠陥でさえ、セキュリティ全体を損なう可能性があります。
2015 edit：推奨ベースの言語を削除し、絶対言語に置き換えました。子孫のためのオリジナルのケビン・モントローズのコメントを埋め込んだ。