私はGawkerの事件について読んでいて、パスワードをハッシュするためにbcryptのみを使用することに関していくつかの記事が出てきました。ハッシュメカニズムが、別の方法に切り替えないように十分に安全であることを確認したいと思います。私の現在のアプリケーションでは、sha2-512と最低1000回の反復を利用したPBKDF2の実装を選択しました。
PBKDF2とBcryptの使用について、また変更を実装する必要があるかどうかについて意見を求めることはできますか?
2022年の時点で、scryptやArgon2などのメモリハード機能に切り替えるのが最適です。Bcryptもオプションになる可能性がありますが、メモリに負担がかかるわけではありません。
PBKDF2に関しては、2000年に1000回の反復を使用することが推奨されましたが、今ではもっと多くのことが必要になります。
また、bcryptを使用するときはもっと注意する必要があります:
また、bcryptはほとんどの種類のパスワードでPBKDF2よりも強力ですが、長いパスフレーズでは遅れをとることにも注意してください。これは、bcryptがパスフレーズの最初の55文字を超えて使用できないためですが、推定コストとNISTはです。パスフレーズエントロピーの推定値は、bcryptの55文字の制限が現時点で問題を引き起こす可能性が低いことを示唆しています。bcryptに依存するシステムの実装者は、この制限を回避する(たとえば、パスフレーズを「プレハッシュ」することによって) 55文字の制限に収まるようにするか、ユーザーが56番目以降の文字にパスワードエントロピーを入れすぎないようにするための措置を講じます(たとえば、Webサイトのユーザーに、スペースしかない入力ボックスにパスワードを入力するように依頼するなど)。 55文字の場合)。
そうは言っても、scryptもあります。
上記のスクリプトペーパーの表がないと、比較は不完全になります。
使用されているPBKDF2-HMAC-SHA256の反復回数は86,000と4,300,000です。
コメント(再:タイトル):
PBKDF2とBcryptの使用に関する意見と、変更を実装する必要があるかどうかについての意見はありますか?
私の意見:
BcryptではなくPBKDF2を使用してください。(理由もなく、私はBlofishよりもSHAを信頼しています)
「変更を実装する」べきかどうかについては、何を求めているのかわかりません。
暗号化/ハッシュの議論を、私の好みをw / r/tアルゴリズムで述べることからより明確に分離するように編集されました。