Web 上にパスワードを保存するための現在のベスト プラクティスは、sha256 やその他のハッシュ アルゴリズムではなく、bcrypt を使用することです。Bcrypt は素晴らしいように思えますが、私が見るところ 1 つの欠点があります: 作業係数 10 を使用するパスワードで満たされたデータベースがあり、計算能力が向上したために作業係数を 12 に増やしたい場合、これを行う方法がありません。ユーザーのパスワードを知らなくても、ユーザーが再度ログインするまで待機します。これは、アカウントを放棄したユーザーに問題を引き起こします。
代わりの解決策は、sha256 を使用して 2^(work factor) に等しい数のパスを実行することだと私には思えます。これを行うと、作業係数を増やしたいときに、保存されているすべてのパスワードのパス数の違いを実行できます。
まさにそれを行うためのコードを少し書きました。これが良いアイデアかどうかについて、皆さんからのフィードバックを得たいと思います。
これらのさまざまな暗号化アルゴリズムについて、多くの論文を掘り下げて読みました。最終的に私にある種の答えを与えてくれたのは、crypto.stackexchange.comのこの質問でした。私のアルゴリズムは、以前は聞いたことのないshacryptに多少似ていますが、それでも bcrypt ほど良くはありません。その理由は、bcrypt は作業要因に加えて、sha2 ファミリーよりも多くのメモリを処理する必要があるためです。つまり、GPU では効果的に並列化できません (ただし、FPGA ではより簡単に並列化できます) が、sha2 では (そして簡単に) 並列化できます。そのため、sha2 を何回実行しても、bcrypt ほど効果的ではありません。
余談ですが、scryptは CPU のワーク ファクターとメモリ ファクターの両方を備えているため、依然として大幅に優れています (したがって、GPU や FPGA で並列化することは本質的に不可能です)。唯一の問題は、現在 scrypt の nodejs ライブラリが基本的に使用できないことです。
bcryptパスの数を増やすための潜在的な解決策（または作業要素。実際にはbcryptを使用していませんが、これはアルゴリズムに依存しない答えです）：
パスワードが保存されているテーブルのエントリごとに、ハッシュされたパスの数も保存します。より多くのパスを使用する場合は、すべての新しいパスワードをそのパス数で保存し、それよりも少ないパスですべてのパスワードを 7 日間で期限切れになるように設定します。新しいパスワードを作成するときは、適切な数のパスでハッシュします。
または、パスワードをリセットすることはできませんが、次回ログインしようとしたときに、パスワードを再ハッシュしてテーブルに保存します。これは、ユーザーが長期間ログインしていない場合、DB 侵害が発生した場合にパスワードが侵害されやすくなることを意味します。そうは言っても、攻撃者にとっては、パスの少ない少数の人々よりも、パスの多い大衆を攻撃する方が価値があります（塩のせいで、この最後の文は間違っています）。