パスワードリセット機能に関するプログラマーの推論を少し理解しています。次のうちどれがより安全か、またはそれらが等しいかどうか誰かに教えてもらえますか？
オプション1：ユーザーに次のメールが送信されます。
Url: http://mysite/reset/user%mail.com
CODE: 57583
次に、ユーザーは手動でコードを入力する必要があるページに移動しますが、電子メールはすでにWebフォームに入力されています。
オプション2：ユーザーに次の電子メールが送信されます。
URL: http://mysite/reset/user%mail.com&code=57583
私はプログラマーではありません。これが単純な質問である場合、または2番目のURLが適切にフォーマットされていない場合、ここでの私のポイントは、例1ではユーザーが手動でコードを入力する必要があり、2番目の例ではフォームがpre -コードが入力されます。
それで、これらは他と同じくらい効果的に安全でしょうか、それとも一方には重大なセキュリティ上の利点がありますか？
どちらも同じように安全です-電子メールがユーザーの受信トレイに到着し、その電子メールがサイトのそのユーザーアカウントにマップされている場合、それが目的のユーザーであると安全に想定できます。ユーザーが代替メールを追加できるようにすることでセキュリティを強化できます。ユーザーがパスワードリセットコードをEmail-Aに送信すると、他のすべてのメールアドレスに「ねえあなたまたは誰かがパスワードリセットメールをEmail-Aに送信しました」という通知を送信します。 。これがクールでない場合は、ここをクリックしてください」
どちらの場合も電子メールに同じ情報が含まれるため、どちらも同じです。
2番目のオプションは私にはもっとユーザーフレンドリーに思えます。しかし、両方を簡単に提供できます（誰かがメールクライアントを持っているため、URLを開くことができません...）
個人的には、両方のアプローチが同等に安全であると考えています（アプローチ2の方がユーザーフレンドリーです）。
ただし、より長いコードを使用する必要があります。そうしないと、簡単に推測でき、攻撃者はリセットトークンを推測するだけでパスワードを自由にリセットできます。
すでにURLを介してユーザーの電子メールを公開しているため、キーを追加しても実際には安全性が低下することはありません。
ユーザーの電子メールをまったく公開しないことでセキュリティを向上させることができます-トークンで電子メールを隠します： mysite.com/reset/some-token?key= [key]
ページにメールを表示しない： email @d**** 。com
そうすれば、人々はブルートフォース方式を使用して、人々がシステムの登録者であるかどうかを確認できなくなります。ほとんどのサイトではおそらく問題ではありませんが、電子メールや登録者リストを公開しないことが重要ないくつかのユースケースを見ることができました。
私は2番目のオプションに行きます。最初のものと比較して害を及ぼすことなく、それはユーザーエクスペリエンス/使いやすさを改善します。
他の人が述べているように、どちらも同じように安全であり、2番目のオプションはよりユーザーフレンドリーです。ただし、攻撃者が「コード」を簡単に推測できないことが重要です。つまり、コードを順番に生成したり、推測しやすいアルゴリズムを使用したりすることは避けてください。最後に、推測攻撃に対する予防策として、特定のIPアドレスが誤ってコードを推測しようとしていると思われる場合は、IPベースのブロッキングを実装することをお勧めします。別のオプションは、コードが10回誤って推測された場合に、ユーザーアカウントがパスワードをリセットしないようにロックすることです（たとえば）。