jBCryptを安全に使用し、組織に推奨できますか？
私はすべての開発者に、保存されたパスワードのハッシュにbcryptを使用することをお勧めします。私たちはすべてJavaを使用していますが、jBCryptの最新バージョン番号（0.3）はそれがベータリリースであることを示しているため、jBCryptを推奨するのをためらっています。SpringSecurityの最新バージョンには、ほとんどがjBCryptの正確なコードです。「大部分」とは、Spring Securityがコードの規則に合わせて変更したことと、それ以外に私が検出できることはほとんどないということです。私にとって、Spring Securityは承認のかなり良い印です。私の質問は： Springの実装をお勧めしますか？テストして結果を実際のbcryptの結果と比較すると、これで十分でしょうか？テストが完全であるかどうかはどうすればわかりますか？
jBCrypt code を自分で監査できます。それは小さいです。750行のソースコードファイルが1つあり、その半分は定数の配列です。さらに、これはJavaなので、Cの恐ろしい「未定義の動作」を恐れる必要はありません。それがマシンでうまく機能すれば、うまく機能しますeverywhere（そのようなコードの場合、スレッド、浮動小数点計算のシステムアクセス、Javaの「1回の書き込みでどこでも実行」のマントラが当てはまる傾向がある）は含まれません。
また、添付のTestBCrypt.Javaファイルを確認することもできます。これは、既知のテストベクタ（一部の非ASCIIパスワードを含む）を適度に完全に適用したもののようです。コードは私には問題なく見えます。
ほとんどのオープンソースプロジェクトでは、バージョン番号は意味がありません。ソフトウェアの実際の技術的な品質よりも、著者の内面の充足感を翻訳しているためです。
注：もちろん、遅いハッシュのポイントはJava youを使用することにより、防御側と攻撃側の間の予算争いなので攻撃者に3倍の利点をもたらしています。heは、最適化されたCまたはアセンブリ（または一部のFPGA）を使用します。しかし、適切に適用されたbcryptは、Javaを使用する場合でも、パスワードの保存が最悪の問題にならないようにするのに十分なはずです。
BCryptは、Springのバージョンでも、オリジナルのMindriot jBCryptポートでも、間違いなく安全に推奨できます。バージョン番号は作者のバージョン管理スキームの結果にすぎないので、怖がらせないでください。
リリースノートについては http://www.mindrot.org/projects/jBCrypt/ を参照してください