メールからのインスタントログイン。なぜこれを行った人が少ないのですか？
これを検索しようとしましたが、何も見つかりませんでした。ディスカッションまたは関連リンクが必要です。
スーパーソーシャルWebアプリにログインするようにユーザーを誘導するために電子メールを送信するとします。このメールの目的は、サイトに戻って、私たちを忘れる前にもう少し詳しく調べてもらうことです。当然、私たちは彼らが戻ってくる障壁を低くしたいと考えています。 Cookieは、毎回ログインする必要がないようにするのに役立ちますが、ユーザーが資格情報を忘れた場合には役立ちません。ここですぐに満足したいのです。ワンクリックでアクションベイビーに直接アクセスできます。代わりに、DBに保存した、ランダムに生成された時間に敏感なトークンのハッシュ形式をユーザーに送信できないのはなぜですか？彼らがこのトークンをサーバーに返すことができれば、私たちは彼らの身元を信頼することができます。
このシナリオは、トークンを正しく管理している限り、安全である可能性があるようです。プロセスは次のようになります。
John Doeにリマインダーメールを送信する前に、数日後に期限切れになる乱数トークン（推測を防ぐのに十分な数）を生成します。
電子メールには、ハッシュ形式のトークン（おそらく、ユーザーのIDを含むxor）を含むURLを含めます。
John Doeが自分の電子メールにログインしてリンクをクリックすると、サーバーはDBにトークンが存在し、有効期限が切れていないことを確認します。トークンが存在する場合、彼はサーバーによって自動的にログインされます。
セキュリティ：登録プロセスの一部として電子メールアドレスが確認されるという理由だけで、JohnDoeの電子メールは実際にはJohnDoeに属していると想定します。 John Doeの電子メールにアクセスできるすべてのユーザーは、自分のアカウントにアクセスできます。ただし、これは新しいことではありません。多くのサイトは、パスワードを電子メールにリセットする機能を実装しているため、ユーザーの電子メールアカウントは安全であるとすでに想定しています。
私のグーグルは、これを行う唯一のサイト、オンラインの出会い系サイトであるOKCupidを見つけました。誰かがこれを行う他のサイトを知っていますか？電子メールによるインスタントログインが一般的でないのはなぜですか？セキュリティ？追加された複雑さに対する実質的なメリットの欠如？
一部のサイトでは、「重要なもの」と「本当に本当に重要なもの」を区別できます。サイトの「重要なもの」により、ユーザーはポリシー、アクティブなメンバー、および受信グループメッセージを表示できるとしましょう。 「本当に、本当に重要なもの」を使用すると、ポリシーを変更したり、パスワードをリセットしたり、新しいユーザーを追加したりできます。したがって、できることは次のとおりです。
- Httpリンクに「重要なもの」へのアクセスを許可します。結局のところ、人々があなたのシステムのポリシー、ユーザー、またはメッセージについて知っていれば、それは世界の終わりではありません。
- 「本当に、本当に重要なもの」が要求された場合は、実際のユーザー名/パスワード認証を要求します。
本質的には、システム内でさまざまな信頼レベルを構築しています。ユーザーを誘惑するために送信する電子メールは、ほとんどの場合、無害なアクティビティ（「追加した新しいウィジェットを確認してください」）用であり、ユーザーがサイトにとどまりたい場合は、認証のための余分な時間を気にしません。
メールは安全ではありません。
電子メールが転送中に表示されないことを想定することはできません。また、ユーザーがSSLを介して電子メールを読むことを想定することもできません（特にWebメールクライアントを使用している場合）。
電子メールを介したパスワードのリセットには、通常（うまくいけば？）2番目の要素であるセキュリティの質問が必要です。
セキュリティ保護用の質問はありません。
ユーザーが何らかの理由で電子メールを友人に転送した場合、その友人はユーザーとしてログインできます。
多くのWebサイトでは、ユーザーは電子メールの確認を通じてパスワードを回復できます。あなたの考えはそれほど違いはありませんが、：
- ユーザーがSSL上のリンクをたどってサイトにログインしていない場合、キーは暗号化されずに渡され、パケットスニッフィングによってハイジャックされる可能性があります。
- 生成するトークンは数日で期限切れになるとおっしゃいました。有効期限が長いと、セッションハイジャックに対してより脆弱になります。パスワード回復用に作成されたトークンは、通常1時間以内に期限切れになります。
Lea Verouは、それについて興味深い考えを持っています。
この機能は、問題のユーザーがしばらく非アクティブであった場合にのみアクティブ化できました。頻繁に使用するユーザーはそれほど必要とせず、必要になったとしても簡単に逃げることはないため、それほど重要ではありません。
出典： http://lea.verou.me/2010/08/automatic-login-via-notification-emails/
人々が電子メールのログインリンクをクリックするのを完全に正常にすることで、基本的にフィッシングの罠を仕掛けることになります。次回、ログインリンク付きの平均的なメールのように見えるフィッシングメールが届いたとき、彼らはそれをクリックするだけでだまされます。
OpenID/OAuthを使用したログインを許可する方がよいと思います。そうすれば、ユーザーはどのような状況でもサイトのパスワードを覚えたり入力したりする必要がないため、「戻ってきてください！」メールは他のルートと何ら変わりはありません。
もちろん、Facebook、Google、またはその他の競合他社のアカウントをすでに持っている必要があります。
このスレッドでは、「パスワードのリセット」がほぼ同じことを行うことがたくさんあることを考えると、次のようになります。
パスワードリセットメカニズムを次の1つ以上と組み合わせるのは非常に一般的です（そしてそうでないことはお粗末です）。
不審なアクティビティの検出。これがなければ、あなたがアマチュア認証システムを作っていることを否定することはできません（おそらくそのような仕事をより有能な人々に任せますか？）。例えば。パスワードのリセットは、ユーザーが通常システムを使用している国からのものですか？アカウント（または最近のアカウント）へのログインに何度も失敗しましたか（辞書攻撃、ボットネットなど）？ここで決定を下す際に使用および評価したパスワードリセットメカニズムは、実際には（表面下で）何らかの形の疑わしいアクティビティの検出を利用していた可能性があります。
セキュリティの質問。 https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet
神、人々の愛のために、これを注意深く読んでください： https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
このハッシュリンクがサードパーティによって傍受されないことをどのように確認できますか？これは非常に安全だとは思いません。
これは、Godaddyがドメイン登録の連絡先情報の更新を処理する方法と非常に似ています（ただし、トークンをURLの一部にするのではなく、安全なフォームに入力または貼り付けるように求められます）。おそらく、思ったほど珍しいことではありません。
ご存知のように、これがパスワードのリセットの仕組みです（基本的に）。このようにログインしてみませんか？基本的に、ユーザー名とパスワードをクエリ文字列にクリアテキストで入力しているためです。これはbadです。参照： HTTPSクエリ文字列は安全ですか？
情報を別のテーブルに保存する必要はないと思います。有効期限のあるJWTトークンを「契約」として使用するとともに、検証コードなどのデータの有効期限がすぐに切れる「一時ストレージ」として使用したいと思います。手順は次のとおりです。
- シークレットと1分の有効期限で署名されたJWTキーを作成します。
user.idトークン内に保存 - トークンがログインに返送されたら、トークンの有効期限が切れておらず、改ざんされていないかどうかを確認します。このエンドポイントを使用してユーザーにログインできます。