0

現在、パスワードの保存と検証を含むプロジェクトに取り組んでいます。パスワードは 100,000 回の繰り返しでハッシュされ、データベースに永続化されます。これは、後でユーザーがログインしたときに取得および検証されます。負荷が低い場合、ハッシュの生成に約 1 秒かかり、ほとんどのユーザーが遅延を感じるため、これはうまく機能します。許容できる。

問題は、システムがますます多くのユーザー (最大 100 同時) を取得するにつれて、ハッシュが CPU を使い果たし、生成に 6 秒以上かかることです。これにより、ログオン時間が非常に遅くなり、残念ながらシステムのステートレスすべての呼び出しでパスワードの検証を必要とする api。

私が理解しているように、総当たり攻撃を回避するためにハッシングの計算コストを高くしたいと考えていますが、攻撃者がメモリダンプにアクセスしてデータベースにアクセスできる可能性ははるかに低いため、妥協案を実装することを考えています。ログオンに成功したら、反復回数を減らして (たとえば 5000 回) パスワードをハッシュし、それを短時間メモリに保存します。同じユーザー ID を検証する要求が来た場合は、メモリ内の安全性の低いバージョンを使用して検証します。それ以外の場合は、データベース内のより安全なバージョンを使用します。これにより、データベース bruce へのアクセスによる攻撃が防止され、高負荷のシナリオでは、メモリ内の安価なハッシュによってほとんどの要求を満たすことができます。

これは安全性が低いことは承知していますが、妥当なトレードオフですか? 気をつけるべき落とし穴はありますか?

エイドリアン

4

0 に答える 0