bcrypt.net
.net 6
bcrypt.codeplex.com の移植。セキュリティが強化され、修正、機能が欠落しており、.net サポートが強化されています。
nuget または Packet を使用してダウンロード (https://fsprojects.github.io/Paket/)
パッケージ: https://www.nuget.org/packages/BCrypt.Net-Next/
署名済みパッケージ - https://www.nuget.org/packages/BCrypt.Net-Next.StrongName/
テストハーネスフォルダーと単体テストにはさまざまな例があります
最も簡単な使用法は次のとおりです...
パスワードをハッシュするには:
ファイルスコープの名前空間が表示されます。必要に応じて中括弧を想像してください。
Top level namespace
namespace DotNetSix ;
using BCrypt . Net ;
string passwordHash = BCrypt . HashPassword ( "my password" ) ;ライブラリの命名により、名前空間が using ステートメントの後にある場合、.net が名前を正しく解決できないため呼び出しが変更されます。名前空間全体を入力するのではなく、単に以下のようにインポート エイリアスを使用することをお勧めします。
using BC = BCrypt . Net . BCrypt ;
namespace DotNetSix ;
string passwordHash = BC . HashPassword ( "my password" ) ;CSProj レベルでエイリアシングを行うこともできます。 using ステートメントを追加する必要はまったくありません
この例では、コード内でエイリアス BC.HashPassword() を使用できます。
< ItemGroup >
<!-- emits global using BcryptNet = global::BCrypt.Net.BCrypt; -->
< Using Include = " BCrypt.Net.BCrypt " Alias = " BC " />
</ ItemGroup >このバージョンでは、他の参照を行わずにコード ベースでVerifyとHashPassword呼び出すだけで済みます。
< ItemGroup >
<!-- emits global using static global::BCrypt.Net.BCrypt; -->
< Using Include = " BCrypt.Net.BCrypt " Static = " True " />
</ ItemGroup >注: このライブラリでは独自のソルトを提供できますが、ライブラリにソルトを生成させることを強くお勧めします。これらのメソッドは、互換性を維持し、その使用を必要とするより高度なクロスプラットフォーム要件に対応するために提供されています。
ハッシュに対してパスワードを検証するには(ハッシュを保存し、検証のためにストレージから取得したと仮定します):
名前空間に関するこれまでの注意事項はすべてここにも適用されます
BCrypt . Verify ( "my password" , passwordHash ) ;このハッシュの実装では、作業係数 (2^ ラウンド数) が 11 に設定されたソルトが自動的に生成されます (これは、ほとんどの実装のデフォルトと一致し、現在、適切なレベルのセキュリティ/リスクとみなされています)。
計算の手間を省くために、反復をまとめた小さな表を以下に示します。このライブラリで許可される最小値は互換性のために 4 で、最大値は 31 です (31 になるとプロセッサが停止します)。
| Cost | Iterations |
|-------|--------------------------|
| 8 | 256 iterations |
| 9 | 512 iterations |
| 10 | 1,024 iterations |
| 11 | 2,048 iterations |
| 12 | 4,096 iterations |
| 13 | 8,192 iterations |
| 14 | 16,384 iterations |
| 15 | 32,768 iterations |
| 16 | 65,536 iterations |
| 17 | 131,072 iterations |
| 18 | 262,144 iterations |
| 19 | 524,288 iterations |
| 20 | 1,048,576 iterations |
| 21 | 2,097,152 iterations |
| 22 | 4,194,304 iterations |
| 23 | 8,388,608 iterations |
| 24 | 16,777,216 iterations |
| 25 | 33,554,432 iterations |
| 26 | 67,108,864 iterations |
| 27 | 134,217,728 iterations |
| 28 | 268,435,456 iterations |
| 29 | 536,870,912 iterations |
| 30 | 1,073,741,824 iterations |
| 31 | 2,147,483,648 iterations |
etc
コンソール プログラムを作成し、この BCrypt ライブラリを追加し、このコードを使用することで実行できる簡単なベンチマークです。
var cost = 16 ;
var timeTarget = 100 ; // Milliseconds
long timeTaken ;
do
{
var sw = Stopwatch . StartNew ( ) ;
BCrypt . HashPassword ( "RwiKnN>9xg3*C)1AZl.)y8f_:GCz,vt3T]PI" , workFactor : cost ) ;
sw . Stop ( ) ;
timeTaken = sw . ElapsedMilliseconds ;
cost -= 1 ;
} while ( ( timeTaken ) >= timeTarget ) ;
Console . WriteLine ( "Appropriate Cost Found: " + ( cost + 1 ) ) ;
Console . ReadLine ( ) ;これは 16 65,536 iterationsから開始され、目標時間に達するまでコストが削減されます。許容時間をどの程度と考えるかはあなた次第ですが、10 未満の場合は、10 のままにして、より大きなサーバー パッケージに投資することを真剣にお勧めします。
bcrypt に推奨される 56 バイトのパスワード制限 (ヌル終了バイトを含む) は、Blowfish キーの 448 ビット制限に関連しています。この制限を超えるバイトはハッシュに完全に混合されないため、これらのバイトが結果のハッシュに実際にどのような影響を与えるかを考慮すると、bcrypt パスワードの 72 バイトの絶対制限はあまり意味がありません。
他の言語では、パスフレーズ/パスワードを事前にハッシュして使用されるエントロピーを増やすことで、この認識されている問題に対処しています。Dropbox は、これに関するより公開された記事の 1 つです。
次のコードを使用するだけで、拡張ハッシュを選択できます (基本的にメソッド呼び出しの前に拡張を付けます)。
var enhancedHashPassword = BCrypt . EnhancedHashPassword ( myPassword ) ;
var validatePassword = BCrypt . EnhancedVerify ( myPassword , enhancedHashPassword ) ;デフォルトでは、ライブラリはパスフレーズの SHA384 ハッシュを使用し、生成されたマテリアルは bcrypt に渡され、通常の bcrypt ルーチンを介してハッシュが形成されます。 SHA の別のバージョンを指定したい場合、またはライブラリのメジャー リリースで変更された場合に備えてコード内で使用するバージョンを明示的に設定したい場合は、上記に対する次の変更を使用してそれを行うことができます。
var enhancedHashPassword = BCrypt . EnhancedHashPassword ( myPassword , hashType : HashType . SHA384 ) ;
var validatePassword = BCrypt . EnhancedVerify ( myPassword , enhancedHashPassword , hashType : HashType . SHA384 ) ;なぜ SHA384 なのか?これは、パフォーマンス、セキュリティ、衝突保護のバランスが良く、長さ拡張攻撃に対して脆弱ではなかった唯一のバージョンです https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash -長さ拡張攻撃 。
拡張エントロピーを使用する必要がありますか?使っても何も損はしない
なぜ SHA タイプを変更する必要があるのですか?一部のライブラリは SHA256 を使用する PassLib ハッシュのようなものなので、主に互換性の問題です。 DropBox では SHA512 が使用されていたため、Dropbox で働いていた場合は互換性が必要になるでしょう。この機能強化は、すでに事前ハッシュして標準メソッド呼び出しに渡すことができるという点で、主に利便性の拡張です。
それは何をするのですか？パスワードの utf8 バイトを inputBytes SHA ハッシュとして取得し、(他の言語実装との互換性のため) Base64 に変換してから、それらのバイトを使用して標準の bcrypt 呼び出しを実行します。
現在の SDK https://www.microsoft.com/net/download では、少なくとも VS2022 が必要です。
nuget パッケージはbuildfornuget.cmdまたは
dotnet restore . s rc
dotnet pack . s rc B Crypt.Net --configuration Releasedotnet test .srcBCrypt.Net.UnitTests TestGenerateSaltWithMaxWorkFactorを実行すると、かなりの時間がかかります。
C# で実装された jBCrypt の .Net ポート。これは、Blowfish 暗号化アルゴリズムのキーイング スケジュールの変種を使用し、ハッシュ関数のコストを決定できる作業要素を導入し、アルゴリズムを「将来も保証」できるようにします。
これは、どう見ても、Damien Miller によって書かれた jBCrypt の直接移植です。主な違いは、いくつかの便利なメソッドの追加といくつかの軽いリファクタリングです。 BCrypt.Net と jBCrypt の同等性を検証する最も簡単な方法は、単体テストを比較することです。
BCrypt が重要な理由の概要については、「パスワードを安全に保存する方法」を参照してください。一般に、これは、ハッシュを生成するためにより多くの CPU パワーを必要とするように時間の経過とともに調整できるハッシュ アルゴリズムです。これは本質的に、ムーアの法則に対するある程度の保護を提供します。つまり、コンピューターが高速化するにつれて、より多くの CPU パワーが必要になるようにこのアルゴリズムを調整できます。特定のパスワードをハッシュするために必要な CPU パワーが増えるほど、「ハッカー」がパスワードごとに投資しなければならない時間も長くなります。 「作業係数」は結果のハッシュに埋め込まれているため、このアルゴリズムによって生成されたハッシュには前方/後方互換性があります。
これは、Blowfish 暗号化アルゴリズムのキーイング スケジュールの変種を使用し、ハッシュ関数のコストがどれくらいかかるかを判断できる作業要素を導入します。このため、BCrypt はムーアの法則に従うことができます。コンピューターの速度が向上すると、作業係数が増加する可能性があり、ハッシュは遅くなります。
Niels Provos と David Mazières は、Blowfish に基づいて bcrypt と呼ばれる crypt() スキームを設計し、1999 年の USENIX で発表しました。
これらのハッシュの印刷可能な形式は次で始まります。
$2$ – Currently obsolete
$2a$ – The current key used to identify this scheme.
Since a major security flaw was discovered in 2011 in a third-party implementation of the algorithm,
hashes indicated by this string are now ambiguous and might have been generated by the flawed
implementation, or a subsequent fixed, implementation.
The flaw may be triggered by some password strings containing non-ASCII characters, such as specially
crafted password strings.
$2b$ – Used by some recent implementations which include a mitigation to a wraparound problem.
Previous versions of the algorithm have a problem with long passwords. By design, long passwords
are truncated at 72 characters, but there is an 8-bit wraparound problem with certain password
lengths resulting in weak hashes.
$2x$ – Post-2011 bug discovery, old hashes can be renamed to be $2x$ to indicate that they were generated with
the broken algorithm. These hashes are still weak, but at least it's clear which algorithm was used to
generate them.
$2y$ – Post Post-2011 bug discovery, $2y$ may be used to unambiguously use the new, corrected algorithm. On an
implementation suffering from the bug, $2y$ simply won't work. On a newer, fixed implementation, it will
produce the same result as using $2a$.
何よりもまず、このライブラリはmindrotの jBCrypt のポートとして誕生し、その後 bcrypt リビジョンが一致するように設定されました (この場合は$2a$ 。単一のリビジョンのみを処理すると、移行やその他の問題を処理するためにリビジョンが変更された実装でクロスプラットフォームの問題が発生するため、これは変更されました。
The original bcrypt code (released in OpenBSD 2.1) identified itself as
$2$. Shortly after release, a bug was fixed and the hash identifier
changed to $2a$. Support for "minor" versions wasn't really
planned, but it was backwards compatible.
Solar Designer wrote a second implementation of bcrypt. This
reimplementation suffered from a flaw dealing with 8 bit characters
and led to the introduction of the 'x' and 'y' flavours. OpenBSD did
not have this problem and supports neither 'x' nor 'y' hash versions.
---
Solar found a bug in their OpenBSD implementation of bcrypt when hashing
long passwords. The length is stored in an unsigned char type, which
will overflow and wrap at 256. Although we consider the existence of
affected hashes very rare, in order to differentiate hashes generated
before and after the fix, we are introducing a new minor 'b'.
OpenBSD 5.5 (coming this spring) will accept and verify 'b' hashes,
although it will still generate 'a' hashes. OpenBSD 5.6 (coming this
fall) will change to generating 'b' hashes by default.
A future release of Solar's bcrypt code should also support 'b'.
2a、2x、2y、2b の間に違いはありません。それらはすべて同じ結果を出力します。
リリースノートはこちら https://github.com/BcryptNet/bcrypt.net/releases
v4.0.3 - .net 6 ターゲティングの追加。ターゲットを整理します。
v4.0.2 - .net 5 ターゲティングの追加。 shaxxx作成を使用してラップしてリリースします。
v4.0.0 (重大な変更) - Enhanced Hashingのバグが発見され、作成されたハッシュが異なる言語間で動作しなくなります。 V4 では、この問題を修正するとともに、PHP と Python からのテスト ベクトルを追加して、将来的に問題が修正されるようにします。 V4 では、Base64 が追加される前に存在した従来の 384 オプションも削除されています。
v3.5.0 - Enhanced Hashingにバグが発見され、作成されたハッシュが異なる言語間で動作しなくなります。修正 3.5 リリースの一部として、 Verify機能が含まれており、 HashPasswordは追加のv4CompatibleEnhancedEntropyパラメーターが与えられました。これにより、ユーザーは拡張ハッシュを通常どおり検証できるようになります。次に、V4 を使用して再ハッシュ + 保存します。この機能は純粋に移行を可能にするためのものであり、V4 では削除されています。
v3.3.3 - ネットコアのパフォーマンス (ヒープ削減) と正規表現の削除 https://github.com/BcryptNet/bcrypt.net/releases/tag/3.3.0
v2.1.3 -
v2.1.2 -
PasswordNeedsReshashのタイプミスをPasswordNeedsRehashに修正v2.1.1 -
v2.1.0 -
PasswordNeedsReshash(string hash, int newMinimumWorkLoad)を追加します。ValidateAndReplacePasswordメソッドを追加して、インラインのパスワード検証と置換を可能にします。認証が失敗した場合は、 BcryptAuthenticationExceptionをスローします。v2.0.1 -
v2.0.0 -
大部分の .net 用にパッケージ化された新しいリリースと、タイミング攻撃によるリスクを軽減するためのセーフイコールが含まれています https://en.wikipedia.org/wiki/Timing_攻撃 / https://cryptocoding.net/index.php/Coding_rules#Compare_secret_strings_in_constant_time技術的には、BCrypt の実装の詳細により、理論的にはタイミング攻撃が軽減されます。しかし、Bcrypt.net の公式検証関数は、ハッシュ比較で一致しないバイトが見つかるとすぐに関数を返すため、タイミング攻撃に対して脆弱でした。
