ナンスを含む電子メールのアクティベーション/登録/パスワードリセットリンクのベストプラクティスは何ですか
アプリケーションはメールを送信して、ユーザーアカウントを確認するか、パスワードをリセットします。私は次のようにすべきであると信じており、参照と実装を求めています。
私の見解によれば、アプリケーションがユーザーのアドレスを確認するためにメールでリンクを送信する必要がある場合、リンクとアプリケーションのリンクの処理には次の特性が必要です。
- リンクのリクエストURIに nonce が含まれています（
http://Host/path?nonce）。 - リンク（GET）をたどると、ユーザーにフォームが表示され、オプションでノンスが表示されます。
- ユーザーが入力を確認します（POST）。
- サーバーはリクエストを受信し、
- 入力パラメータをチェックし、
- 変更を実行し、
- ナンスを無効にします。
これは Safeメソッドとべき等メソッドのHTTP RFC ごとに正しいはずです。
問題は、このプロセスに1つの追加ページまたはユーザーアクション（項目3）が含まれることであり、これは多くの人々によって（無駄ではないとしても）不要であると見なされることです。私はこのアプローチを仲間や顧客に提示するのに問題があったので、より広い技術グループからの意見を求めています。 POSTステップをスキップすることに反対した唯一の引数は、ブラウザからリンクを事前にロードすることでした。
- この主題について、アイデアをよりよく説明し、技術に詳しくない人でさえ納得させるような参考文献がありますか（ジャーナル、ブログなどのベストプラクティス）？
- このアプローチを実装する参照サイト（できれば人気があり、多くのユーザーがいる）がありますか？
- そうでない場合、文書化された理由または同等の代替手段がありますか？
ありがとうございました、
カリエム
スペアの詳細
主要部分は短くしましたが、意図的に省略していた詳細に関する議論を減らすために、いくつかの仮定を追加します。
- メールの内容はこのディスカッションの一部ではありません。ユーザーは、アクションを実行するにはリンクをクリックする必要があることを知っています。ユーザーが反応しない場合、何も起こりません。これも既知です。
- ユーザーにメールを送信する理由や、通信ポリシーを示す必要はありません。ユーザーが電子メールを受信することを期待していると仮定します。
- ナンスには有効期限のタイムスタンプがあり、重複を減らすために受信者の電子メールアドレスに直接関連付けられています。
注
OpenIDなどを使用すると、通常のWebアプリケーションは標準のユーザーアカウント管理（パスワード、電子メールなど）の実装から解放されますが、一部の顧客は「自分のユーザー」を望みます
奇妙なことに、私はまだ満足のいく質問も答えもここで見つけていません。私がこれまでに見つけたもの：
この質問は、 ASP.NET（C＃）で安全で一意の「使い捨て」アクティベーションURLを実装する と非常に似ています。
私の答えはあなたのスキームに近く、いくつかの問題が指摘されています-短い有効期間、ダブルサインアップの処理など。
cryptographicnonceの使用も重要です。多くの場合、スキップする傾向があります。 「GUIDを使用するだけ」...
ここで重要なのは、GETのべき等性に関する新しい点です。
私はあなたの一般的な意図に同意しますが、dem等性が一度限りのリンクに直接矛盾することは明らかであり、これはこのような状況では必要です。
私は、これがGETのべき等性を実際に侵害していないと主張したかったのですが、残念ながらそうではありません...一方、RFCはGET[〜＃〜] should [〜＃〜]べき等である必要があります。したがって、この場合はそれを忘れて、1回限りの自動無効化リンクに固執します。
本当に厳密に厳密なRFCコンプライアンスを目指して、非べき等（？）GETを取得したくない場合は、GETページでPOST-RFCのその周辺の抜け穴のようなものですが、合法であり、ユーザーに二重オプトインを要求する必要はありません。
あなたは本当にプリロードを心配する必要はありません（CSRF、またはブラウザオプティマイザーについて話しますか？）...
パスワードのリセットについて：
ユーザーの登録済み電子メールアドレスに電子メールを送信してこれを行うことは、実際には非常に一般的ですが、良好なセキュリティではありません。これを行うと、アプリケーションのセキュリティがユーザーのメールプロバイダーに完全にアウトソースされます。必要なパスワードの長さと、使用する巧妙なパスワードハッシュは関係ありません。ユーザーに送信されたメールを読むことでサイトにアクセスできるようになります。メールアカウントにアクセスできるか、暗号化されていないメールをユーザーの途中で読むことができるからです（邪悪なシステム管理者）。
これは、問題のサイトのセキュリティ要件に応じて重要である場合とそうでない場合がありますが、私はサイトのユーザーとして、少なくともこのようなパスワードリセット機能を安全でないと考えて無効にできるようにしたいと考えています。
このホワイトペーパー がトピックを説明していることがわかりました。
安全な方法でそれを行う方法の短いバージョン：
アカウントに関する確固たる事実を要求する
- ユーザー名。
- 電子メールアドレス。
- 10桁の口座番号またはその他の社会保障番号などの情報。
ユーザーが少なくとも3つの事前定義された質問（ユーザーが事前に定義したもので、ユーザーが独自の質問を作成しないようにする）に答える必要があります。 「お気に入りの色は何ですか」ではなく、「お気に入りの休暇スポットは何ですか」のように。
オプション：確認コードを、ユーザーが入力する必要がある事前定義の電子メールアドレスまたはセル番号（SMS）に送信します。
ユーザーが新しいパスワードを入力できるようにします。
私は一般的に、以下に提案するいくつかの修正に同意します。
- ユーザーがサイトに登録して、メールを送信します。
- 確認メールは、2つのリンクを使用してユーザーアカウントに送信されます。a）GUID=登録を確認するための1つのリンクb）GUID=検証
- 電子メールから検証URLにアクセスすると、自動的に検証され、システムで検証GUIDがそのようにマークされます。
- ユーザーがメールから拒否URLにアクセスすると、確認のキューから自動的に削除されますが、さらに重要なことは、ユーザーにメールの登録が残念であることを伝え、システムからメールを削除するなどのオプションを提供できることです。これにより、誰かがあなたのシステムに私の電子メールを入力することについてのカスタムサービスタイプの苦情を停止します...何とか何とか。
はい。ユーザーが検証リンクをクリックすると、検証されたと見なす必要があります。ページの2番目のボタンをクリックさせるのは少しだけで、登録した人にスパムを送信する予定のダブルオプトインスタイルの登録にのみ必要です。通常、標準の登録/検証スキームではこれは必要ありません。