63

アプリケーションは電子メールを送信して、ユーザー アカウントを確認したり、パスワードをリセットしたりします。以下が本来あるべき姿であると信じており、参照と実装を求めています。

アプリケーションがユーザーのアドレスを確認するために電子メールでリンクを送信する必要がある場合、私の見解によると、リンクとアプリケーションによるリンクの処理には、次の特性が必要です。

  1. リンクのリクエスト URI にnoncehttp://host/path?nonceが含まれています ( )。
  2. リンクをたどる (GET) と、ユーザーにはフォームが表示され、オプションで nonce が表示されます。
  3. ユーザーが入力を確認します (POST)。
  4. サーバーはリクエストを受け取り、
  • 入力パラメータをチェックし、
  • 変更を実行し、
  • ノンスを無効にします。

これはHTTP RFC on Safe and Idempotent Methodsに従って正しいはずです。

問題は、このプロセスには 1 つの追加のページまたはユーザー アクション (項目 3) が含まれていることです。これは、多くの人が (無用ではないにしても) 不必要だと考えています。このアプローチを同僚や顧客に提示するのに問題があったため、より広範な技術グループからの意見を求めています。POST ステップをスキップすることに対して私が持っていた唯一の議論は、ブラウザーからのリンクのプリロードの可能性でした。

  • アイデアをよりよく説明し、技術者ではない人でも納得できるような参考文献はありますか (ジャーナル、ブログなどからのベスト プラクティス)。
  • このアプローチを実装している参照サイト (できれば人気があり、多くのユーザーがいるサイト) はありますか?
  • そうでない場合、文書化された理由または同等の代替手段はありますか?

ありがとう、
カリエム

詳細は省略

主要な部分は短くしましたが、意図的に省略した詳細についての議論を減らすために、いくつかの仮定を追加します。

  • メールの内容は、この議論の一部ではありません。ユーザーは、アクションを実行するにはリンクをクリックする必要があることを知っています。ユーザーが反応しない場合、何も起こらないこともわかっています。
  • ユーザーにメールを送信する理由や通信ポ​​リシーを示す必要はありません。ユーザーは電子メールを受信することを期待していると想定します。
  • ナンスには有効期限のタイムスタンプがあり、重複を減らすために受信者の電子メール アドレスに直接関連付けられます。

ノート

OpenID などにより、通常の Web アプリケーションは標準的なユーザー アカウント管理 (パスワード、電子メールなど) の実装から解放されますが、それでも一部の顧客は「自分のユーザー」を望んでいます。

奇妙なことに、満足のいく質問も答えもここではまだ見つけていません。私がこれまでに見つけたもの：

4

3 に答える 3

27

この質問は、ASP.NET (C#) で安全で一意の「1 回限りの」アクティベーション URLを実装する によく似ています。

短い有効期間、二重サインアップの処理など、いくつかの問題が指摘されています。暗号
ナンス の使用も重要であり、多くの人がスキップする傾向があります。 GUID を使用します」...

あなたが提起する 1 つの新しいポイント、これはここで重要ですが、GET の冪等性についてです。
私はあなたの一般的な意図に同意しますが、冪等性がワンタイムリンクと直接矛盾していることは明らかです。これは、このような状況では必要です。

これは GET の冪等性に実際には違反していないと主張したかったのですが、残念ながら違反しています... 一方、RFC では、GET は冪等である必要があり、MUST ではないと述べています。したがって、この場合はやめて、1 回限りの自動無効化リンクに固執することをお勧めします。

厳密な RFC 準拠を本当に目指し、冪等でない (?) GET に陥らないようにしたい場合は、GET ページに POST を自動送信させることができます。ユーザーにダブルオプトインを要求する必要はありません。また、ユーザーを悩ませているわけでもありません...

プリロードについて本当に心配する必要はありません (CSRF について話しているのですか、それともブラウザー オプティマイザーについて話しているのですか?)... CSRF は nonce のために役に立たず、オプティマイザーは通常、プリロードされたページで JavaScript (自動送信に使用される) を処理しません。

于 2009-07-01T09:22:12.417 に答える
9

パスワードのリセットについて：

ユーザーの登録された電子メールアドレスに電子メールを送信することによってこれを行う方法は、実際には非常に一般的ですが、優れたセキュリティではありません。これを行うと、アプリケーションのセキュリティがユーザーの電子メールプロバイダーに完全にアウトソーシングされます。必要なパスワードの長さや、使用する巧妙なパスワードハッシュは関係ありません。私は電子メールアカウントにアクセスできるか、ユーザーに向かう途中のどこでも暗号化されていない電子メールを読むことができるので、ユーザーに送信された電子メールを読むことであなたのサイトに入ることができます（悪のシステム管理者を考えてください）。

これは、問題のサイトのセキュリティ要件に応じて重要な場合とそうでない場合がありますが、サイトのユーザーとして、私は安全ではないと考えているため、少なくともこのようなパスワードリセット機能を無効にできるようにしたいと思います。

このトピックについて説明しているこのホワイトペーパーを見つけました。

安全な方法でそれを行う方法の短いバージョン：

  1. アカウントに関する確かな事実を要求する

    1. ユーザー名。
    2. 電子メールアドレス。
    3. 10桁の口座番号または社会保障番号などの他の情報。

  2. 些細なことではない、少なくとも3つの事前定義された質問（ユーザーが事前定義し、ユーザーに独自の質問を作成させないでください）にユーザーが回答することを要求します。「あなたの好きな色は何ですか」ではなく、「あなたの好きな休暇の場所は何ですか」のように。

  3. オプション：ユーザーが入力する必要のある事前定義された電子メールアドレスまたはセル番号（SMS）に確認コードを送信します。

  4. ユーザーが新しいパスワードを入力できるようにします。

于 2009-07-16T16:26:02.853 に答える
1

私は一般的に、以下に提案するいくつかの変更に同意します。

  1. ユーザーはあなたのサイトに登録し、メールを提供します。
  2. 確認メールは、2つのリンクでユーザーアカウントに送信されます。a）登録を確認するためのGUIDを含む1つのリンクb）確認を拒否するためのGUIDを含む1つのリンク
  3. 電子メールから検証URLにアクセスすると、自動的に検証され、システムで検証GUIDがそのようにマークされます。
  4. 彼らが電子メールから拒否URLにアクセスすると、可能な検証のキューから自動的に削除されますが、さらに重要なことに、電子メールの登録について申し訳ありません。システムから電子メールを削除するなどのオプションをユーザーに提供できます。これにより、誰かが私の電子メールをシステムに入力したことに関するカスタムサービスタイプの苦情がなくなります...何とか何とか何とか。

はい、確認リンクをクリックすると確認済みであると想定する必要があります。ページの2番目のボタンをクリックさせるのは少し大変で、登録した人にスパムを送信する予定のダブルオプトインスタイルの登録にのみ必要です。標準の登録/検証スキームでは、通常、これは必要ありません。

于 2009-06-30T23:50:12.130 に答える