正確には、古いパスワードリセットトークンを削除する必要があるのはいつですか。
パスワードリセットトークンを操作するためのベストプラクティスを理解しようとしています。
ユーザーがパスワードのリセットプロセスを開始すると、リセットトークンがメールで送信され、ハッシュ化されたコピーがデータベースに保存されます。トークンにはDBでタイムスタンプが付けられており、たとえば24時間で期限切れと見なされます。
次に、次に何が起こるかについて2つのシナリオを検討します。
1）ユーザーはメールを受け取っていないと考え、再度リセットを試みます。彼が別のトークンを生成することを許可する必要がありますか？その場合、古いトークンをすぐに削除する必要がありますか？ （いずれにしても、問題が発生してから24時間後はすべて無効になりますdatetimeとにかく...）とにかく有効期限が切れる限り、少しの柔軟性があれば、サポートへの問い合わせを最小限に抑えることができると思います。ここで考慮しない攻撃タイプはありますか？
2）ユーザーはメールを受信してリセットリンクをクリックしましたが、リセットフォームに入力していません。リセットトークンはいつ削除する必要がありますか？リセットが成功した後でのみ、ユーザーは24時間の間何度でもリンクをクリックでき、最後にパスワードをリセットして初めてリンクが無効になります。または、セキュリティ上の懸念からリンクをクリックした直後にトークンを削除する必要がありますか？ （これはすべて有効期限が切れる前に発生します）
ユーザーがプロセスで邪魔される可能性があるため、ユーザーがトークンをクリックしたときに、トークンをリセットしないでください（たとえば、彼の猫はキーボードでジャンプしました-私はそれを非常に定期的に行っています）。
（2日前に、このようなリンクを使用していました。パスワードのリセットではなく、同様のリンクです。クリックするとすぐに無効になり、その背後のページはChromeと互換性がないことがわかりました。そのため、新しいリンクを要求し、プロセス全体をもう一度実行します。そのために私はそれらを呪いました。パスワードを扱うとき、ユーザーの協力的な味方を作り、彼を怒らせないようにする必要があります。）
パスワードが実際にリセットされると、保留中のすべてのパスワードリセットリンクが無効になります。一度に1つのリセットリンクのみを許可する方が簡単です。前のリンクがまだ有効なときにユーザーがパスワードのリセットを要求した場合は、もう一度送信するだけです（おそらく、タイムアウトカウンターをリセットします）。同時に有効ないくつかのdistinctパスワードリセットリンクをサポートする必要はありません。一度に1つのリンクを使用すると、データベースの設計が簡単になり、バグの範囲が少なくなります。
- 一度に1つのリセットトークンしか使用できないように、ユーザーがパスワードのリセットを1回だけリクエストできるようにすることをお勧めします。
- メールが正常に送信されたかどうかを常に追跡して、リセットトークンをデータベースに保存できます。
- ユーザーが再試行を試みた場合（およびアクティブなリセットリンクが存在する場合）、「リセットリンクが既に送信されている」ことをユーザーに通知します。
- パスワードトークンの削除について：パスワードトークンは、パスワードが正常にリセットされた後すぐに削除されます。残りのリンクをクリックした後は削除されません。
考えられる代替策の1つは、ユーザーのパスワードをリセットしてDBで更新することです。 「これは新しいパスワードです。すぐに変更してください。- 電子メール通信が暗号化されていない場合、パスワードのリセットプロセスは常に脆弱であることに注意してください。 時間制限リセットURLにより、潜在的な攻撃の攻撃ウィンドウを最小化することができます。