t_wの輪郭

PKCS #5 では、ソルトの長さを最低でも64ビットにすることを推奨しており[6]、アメリカ国立標準技術研究所は、128ビットのソルトを推奨している[7]。

教科書などでは、ソルトに乱数を使っている実装をよく見かけますが、原理的には乱数である必要はありません。通常、ソルトはハッシュ値とともに保存するので、オフライン攻撃者にとってソルトは秘密情報ではありません。また、ある程度長さが確保できれば、ユーザーIDそのものをソルトにすることもできますが、ユーザーIDを後から変更できるサイトの場合は実装に工夫が必要になります。

プログラマがパスワードをハッシュ化する際に毎回同じソルトを使用するケース。 この場合でも、既存のレインボーテーブルを無効化することはできる（ソルトの値が適切であれば）。ただし、広く使われている製品にソルトがハードコーディングされると、そこから抽出したソルトを使って新しいレインボーテーブルを生成できてしまう。 また、ソルトが固定だと、パスワードが同じユーザーはハッシュ値も同じになってしまう（ハッシュ値を作る際にユーザ名を混ぜ込んでいる場合を除く）。これにより、一つのハッシュ値で複数のユーザーを攻撃するのが容易になってしまう。

https://ja.wikipedia.org/wiki/ソルト_(暗号)

　メールアドレスもハッシュ化を試してみたところ、問題が一つ発生した。メールアドレスとパスワードによって認証する時、メールアドレスにSALTを付与したうえでハッシュ化しているために、利用者が入力したメールアドレスをキーとして、DBに格納されているハッシュ化したパスワードを引き出すことができない。
　無理やり突合するならば、すべてのSALTを取り出して、ハッシュ化して突合すれば何とかできるが、計算コストがかかってしまう。
　もしくは、メールアドレス以外に主キーにできる値を持たせられればいいが、それを利用者に覚えてもらうというのも現実的ではない。

　良いアイデアだと思ったが、うまくいかないので棄却するしかない。

https://nodejs.org/api/crypto.html#cryptopbkdf2password-salt-iterations-keylen-digest-callback

レインボーテーブルってもんがあるので単にハッシュ関数通しただけじゃだめですよ！

saltを入れないといけないということを言っている？