メールでパスワードリセットリンクを送信する
今日、誰もが互いにより安全にしようとするとき、企業が情報セキュリティに数十億ドルを費やしているとき、パスワードのリセットが残されたのは少し奇妙に思われます。メールプロバイダで。
電子メールでパスワードを送信することは悪い考えです。私たちは皆それを知っています。電子メールプロバイダーの安全性を誰が知っていますか？メールアカウントがハッキングされたかどうか誰が知っていますか？ （中間者）の間に誰が聴いているのか誰が知っていますか？など...そのため、パスワードを電子メールで送信する人はほとんどいません。
しかし、パスワードの回復はどうですか？ほとんどのWebサイトはリンクを電子メールで送信するだけで、それをクリックした後、パスワードを変更できます。したがって、Webサイトのセキュリティがいかに安全であっても、ユーザーをハッキングするのは簡単ですよね。
メールプロバイダーを信頼せずに、安全なパスワードリセットシステムを作成するにはどうすればよいですか？
SMS（これも安全ではありません）などのリソースを使用せずに、すべての人に適用できるソリューションを探しています。予算のないプログラマが何をすべきか、という答えを探しています-ですから、まだそれを使用することができます。
ここに私が考えたいくつかの事柄があります：
- セキュリティの質問-現在、誰もがオンラインの誰でも何でも見つけることができるので、それらの質問はそれほど安全ではありません。
- 回復コード-正直に言ってください。 Webサイトから回復コードを印刷して保存するように求められた場合、そうしますか？ほとんど誰もそうしません。そして、彼らがそうした場合、彼らはおそらくしばらくするとそれを失うでしょう...
SMSやカタツムリメールなど）以外の電子メール以外のバンドを介して、一意のテキスト文字列、別名トークン（暗号で保護された、ランダムに生成された）をユーザーに送信します。アプリのパスワードは、サイトのWebフォームにトークンを入力した場合のみです。
または、スマートカードなど、すべてのユーザーがアプリを使用するために必要な物理デバイスを使用します。
これは本当に良い解決策がなければ問題になるかもしれません。ここにいくつかの提案があります。それらはすべて2つのグループに分類されます-非常に効果的ではありませんが実用的（1-4）または効果的ですが、少し非実用的（5-6）です。通常の電子メールと組み合わせて使用できる、またはおそらく使用する必要があることに注意してください。
- トークンが有効な時間を制限します。
- 新しいパスワードを要求するIPとリンクをクリックするIPのジオロケーションが同じであることを確認します。これは、Torユーザーのように一部の機能を破壊する可能性がありますが、それでも価値があるかもしれません。 （これは、送信中にトークンが盗まれるのを防ぐだけです。攻撃者が電子メールアカウントにアクセスできる場合は何もしません。）
- 郵便番号や個人が最近プライベートメッセージを送信した別のユーザーなど、ユーザーに関する追加情報を尋ねます。これは、（a）ユーザーが100％知っていること、および（b）簡単に公開されない情報である必要があります。どちらにも当てはまらないリスクがあるため、これが役立つかどうかは疑問です。
- 上記と同様：昔ながらのセキュリティの質問を使用します。つまり、サインアップの両方の要件を満たす情報をユーザーに明示的に提供してもらいます。リスクは、ユーザーが何かをランダムに入力してそれを忘れてしまい、それによってアカウントがブリックされることです。繰り返しになりますが、誰かがあなたの母親の旧姓を本当に知りたいのであれば、きっとそうなるはずです。
- トークンを「帯域外」で送信します。 SMSまたは古い形式のカタツムリメールで。それらのセキュリティが心配な場合は、メールトークンと組み合わせて使用してください。
- Vrtjasonはコメントで次のように提案しています。「ユーザーがロックアウトされた場合に備えて、長寿命トークンの短いリストをユーザーに提供します。ユーザーはそれらをハードコピーに印刷し（多分最初の登録直後）、そのリストを財布に入れます。」
パスワードリセット機能の詳細については、次の質問をご覧ください。 「パスワードを忘れた」機能を実装する方法は？
では、電子メールプロバイダーを信頼せずに、安全なパスワードリセットシステムを作成するにはどうすればよいでしょうか。
「信頼されたデバイス」の概念を持つことができます。つまり、有効なログインが完了すると、Cookieとして保存され、そのサーバー側にも保存（ハッシュ）された、そのデバイスの長期トークンを設定します。
パスワードリセットトークンが電子メールで送信される場合は、信頼できるデバイスのCookieを確認して、以前にログインが正常に完了したデバイスがパスワードリセットを行うことを要求するだけです。
プロセスは次のようになります。ユーザーはページにアクセスし、メールアドレスを入力してトークンを取得します。電子メールでリンクをたどってパスワードをリセットする場合は、デバイス識別子が以前にログインしたものと一致することを確認してください。
ユーザーが別のデバイスからリセットを完了できないという点で、リセットにはいくつかの制限があります。また、認証されたユーザーが信頼できるデバイスリストを管理できるようにする必要があります（たとえば、簡単にするために、デバイスに名前を割り当てたり、現在のデバイス以外のすべてのデバイスをクリアしたりして、サーバー側の記録を消去することができます。それら）。
これにより、パスワードの変更がメールプロバイダーの盗聴者によって行われるのを防ぐことができます。
別の可能性は、2要素認証を採用し、パスワードのリセットを続行するために2FAデバイスの検証を要求することです。
もう1つのオプションは、リセット要求と実際に変更されたパスワードに同じセッションが使用されていることを確認することです。ただし、リセットメールが送信される前に、ユーザーを何らかの方法で確認する必要があります。たとえば、いくつかのセキュリティの質問をすることができますが、メールプロバイダーが他の電子メールを読んで、可能性のある回答を明らかにできる場合、これは弱いです（このオプションは完全性のために提供されていますが、お勧めできません）。
this answer も参照してください。
主なオプションは次のとおりです。
メール確認のみ-ほとんどのサイトがこれを行います。シンプルで基本的に無料で、フォーラム、eコマース、ソーシャルネットワーキングなどのサイトで十分に安全です。ほとんどのユーザーは、メールプロバイダーを信頼する必要があることを受け入れます。
セキュリティの質問-最も一般的な追加のセキュリティメカニズム。これは、「最初のペットの名前は何ですか」などの質問、または「最後の配達の郵便番号」などのアカウントの詳細である可能性があります。それらはユーザー（自分の好きな色を忘れている）を煩わしく、限られたセキュリティを提供しますが、開発者にとってはかなり簡単です。
代替確認-ほとんどの場合、SMSを使用した電話による確認ですが、これは新しいパスワードを実際の手紙で投稿することによる住所確認である可能性があります。ユーザーにとってそれほど難しくありません。電話番号の提供に反対する人もいますが、これはスパムアカウントの抑制にもつながります。開発するのに十分なほど単純ですが、SMSを送信し、物理的な手紙を送信するにはさらにコストがかかります。これは、大規模なプロバイダーにとっては推奨されるオプションになっています。
トークンのリセット-これは、より安全なオプションの1つであり、開発者にとって簡単です。ただし、これはユーザーにとっては不便で、めったに使用されません。
本人確認-ユーザーがサインアップするときに、実際のID（名前、政府のID番号など）をキャプチャします。彼らのパスワードをリセットするために、彼らはあなたが確認する政府IDを持って直接あなたのところへ行きます。これは非常に安全ですが、オーバーヘッドが高く、グローバルWebサイトでは機能しません。これのバリエーションは、サインアップ（つまり、直接のサインアップのみを意味する）で生体認証の詳細をキャプチャし、パスワードのリセットのために生体認証を検証することです。
問題の回避策-OpenID Connectでのログインのみを許可し、忘れたパスワードの問題はIDプロバイダーに任せます。これはおそらく最良の戦略的オプションですが、OpenID Connectはまだ十分に確立されていないため、ユーザーと開発者の両方にとって困難です。
そのため、さまざまな利点と欠点を持つさまざまなオプションがあります。あなたがあなたの質問に入れたすべての制限を考えると、それらすべてを満足させるテクニックはありません。あなたはあなたのサイトが何をしているのかを述べていませんが、私は単純な電子メール検証があなたにとって最良の選択肢であることを期待しています。それが本当に受け入れられない場合は、おそらくいくらかお金をかけて、SMS検証を行う必要があります。
これには特効薬はありません。
事実：他のサービスプロバイダーを信頼したくない場合、およびいくつかの第2要素のアプリまたはトークンに基づくプライベートな独立したソリューションを提供したくない場合は、ユーザーに尋ねる必要があります彼と秘密を守り、彼がそれを安全に保つ必要があることを彼が理解することを確認するため。
例： keybase.ioのアプローチを見てください。彼らは彼らが「紙の鍵」と呼ぶものを生成します。単語の長いリストです。彼らは何度もあなたにそれを紙に書き留めて安全に保管するように頼みます。このキーは回復に使用できます。また、キーを紛失した場合にアクセスできるようにする方法はまったくありません。
それに関する問題は、人々がこの秘密を書き留めてそれを安全に保つ用意があるかどうかを知るのが難しいということです。これは、保護されていて、この方法で回復できるデータのユーザーにとっての重要性に依存すると思います。これがアカウントを復元する唯一の方法であることを明確にし、ユーザーがメモして安全な場所にロックしたかどうか確認を何度も求める必要があります。それでも、一部のユーザーは翌日、「紙の鍵」を紛失したため、アカウントを復元する方法についての情報を求めるサポートに連絡します。
メールによるリカバリはそれほど悪くありません：メールで送信されるリカバリトークンは、メールで送信されるパスワードとは異なります。主に、トークンは短時間で期限切れになり、1回しか使用できないためです（少なくとも、あなたがそれを正しく行う場合）;そのため、安全ではないと考えることはできません。完璧ではありませんが、ほとんどのインターネットユーザーと多くのシナリオで問題なく機能する優れたオプションです。
メールによるリカバリを改善するにはどうすればよいですか？
セキュリティを向上させるには、次の方法があります。
- アカウントの変更（SMS、Whatsappなど）について他のメッセージングシステムでユーザーに通知し、発生したことをユーザーが認識していることを確認し、必要に応じて対策を講じます。それを行うための無料のオプションがあります。
- これらの他のシステム（第2要素）の確認を要求することもできるため、攻撃者は電子メールだけでなく、おそらくこれも無料ではありません。ただし、携帯電話を紛失した場合、携帯電話に基づく確認は有効にならず、正当なユーザーが正確にパスワードを変更したい場合にも問題になります。
- 古いパスワードを使用して変更を元に戻すための時間枠を与えてください。
- また、変更後にアカウントロックアウトの時間枠を必要とする場合があるため、攻撃者が侵入する前に、ユーザーにそれを元に戻すように求める時間を与えることができます。そのロックアウトで怒っているユーザーを確実に獲得できますが、一部の攻撃は緩和されます。また、ユーザーからのデータに基づいていくつかの自動チェックを追加することもできます（ユーザーが通常接続しているものとは異なるブラウザー/場所からの回復を求めていますか？しばらくロックアウトします。そうでない場合は、リセットさせますすぐにパスワードを入力してください）。
ただし、最終的には、2種類の人がいます：システムでの保護に関心があり、安全性を維持するための優れた強力なパスワードを持っている人、おそらく一部のパスワード管理システムでは、あなたが提供し、最終的には回復方法が必要ない可能性がある場合は2FAを使用します（一部のサービスが回復しないというオプションを私に提供してくれたら嬉しいです-実際、サービスが私に弱い「安全な質問」を尋ねたとき「私はだれでも（私でも）誰もそれを使用できないようにするために、ただランダムに意味不明なものを付けました）。または、上記の紙の鍵のように、ユーザーフレンドリーではない保護があれば幸いです。
また、システムの保護についてはそれほど気にしないが、自分の電子メールの保護についてはもっと気にする人もいるでしょう。そのため、ほとんどのシナリオでは電子メールで十分であり、重要なシステムでは紙の鍵や他のプライベートアプローチが適切なオプションであることがわかりました。
警告：回復リクエストを行ったブラウザに基づいてユーザーを特定しようとする解決策には欠陥があります
ここでの多くの答えは、回復リンクが、回復要求リンクが作成されたのと同じ場所（ブラウザ）でのみ使用されていることを確認することに基づいています。このような検証を提案するソリューションは、攻撃モデルに準拠していません。つまり、電子メールアカウントが何らかの形で侵害されています。攻撃者が標的の電子メールを読むことができる場合、標的は回復リンクを要求する必要はありません。彼は回復リンクを自身に要求し、電子メールと対応するリンクを両方とも同じブラウザー/システムで取得します。
この種のソリューションはセキュリティの向上ではないことに注意してください。それは攻撃に関して何も変更せず、それをより難しくしません。攻撃者は、どういうわけか、標的の電子メールにアクセスする必要があるだけで、それ以上は必要ありません。良いアナロジーは、攻撃者があなたの家の開いたドアを見つけたということです。しかし今、あなたは彼に錠と対応する鍵を選んで、それでドアを閉めて鍵を保持することを要求します。攻撃者は鍵を使用してドアを再び開けて侵入します。実際にはセキュリティの向上ではなく、単に煩わしいものです。
このような方法は、攻撃者がone電子メールのみにアクセスできる攻撃シナリオのセキュリティを向上させるだけであり、これは、正当なユーザーがまさに彼が回復リンクを要求し、ユーザーの前にそれを使用する場合に受信します（要求したばかりで、電子メールの到着を期待しています）。ただし、攻撃者が自分で回復リクエストを開始した場合、同じパスをたどる電子メールを傍受することはできません。私にとって現実的なシナリオではなく、OP質問シナリオでもありません。
これを実現するために電子メールプロバイダーを信頼する必要はありません。次のアーキテクチャは、十分に安全なパスワードリセットリンクを作成するために使用できます。
データベース
次の列を持つテーブル。
- ユーザーID（100文字）
- ReqID（128文字）
- Stime（タイムスタンプ）
- VHash（128文字）
リクエストページ
リクエストページでユーザー名を受け入れ、それとともに FingerprintJS2 などのJSライブラリを使用して、ブラウザの一意のフィンガープリントを生成します。
それらをサーバーに送信します。
バックエンド
sha256(BrowserFingerprint+UserID+md5(CLIENT_IP))を実行してVhash（検証ハッシュ）を作成します
注：IPの変化が速い場合は、IPを使用しないでください。
値をテーブルに保存し、リクエストID（ReqID）を生成します。これをユーザーへのリンクの一部としてメールで送信します。
Host.com/reset.php?req=4v6sdb4d89b41r8
リンクページ
新しいパスワードを受け入れ、ブラウザの指紋とともにサーバーに送信します。
バックエンド
検証ハッシュを再生成して照合できるかどうかを確認します。ハッシュが一致しない場合、またはリクエストがリクエストから30分後に送信された場合は拒否します。
文末脚注
もう少し安全性の低い方法は、クライアントのCookieに値を保存し、ブラウザのフィンガープリントと同様の方法でハッシュを使用することです。
これは興味深いトピックです。残念ながら、除外によって可能性を絞り込んでいます。それ以外の場合は、2番目のチャネルをお勧めします。
ダークネットのいくつかのサイトは、あなたがあなたの質問で概説したのと同じ欲求を持っています：彼らは人々が電子メールアカウントを持っていることを期待していません（匿名の電子メールはそれほど簡単ではありません）、または彼らは電子メールプロバイダーを信頼していません。これが、2つの異なるアプローチを使用する理由です。
- ユーザーはパスワードのリセット中に使用されるパスフレーズを書き留める必要があります
- ユーザーは、パスワードが欠落した場合のフォールバックである証明書をアップロードする必要があります
インターネットの陰になっている部分を離れると、銀行の運営状況を見ることができます。彼らはセキュリティの質問も使用しますが、次のようなより動的で短期的な情報にも依存しています。
- 最後のトランザクションのおおよその量
- おおよその電流バランス
- 先月/年末のおおよその残高
- アカウントの権限に関する詳細（サードパーティがアカウントへのアクセスを許可されている）
これらの可能性のいくつかを組み合わせることができ、5つのうち4つが正しい場合は、パスワードのリセットを受け入れることができます。開発者がよく忘れてしまうこと：そのような「ソフトパスワードリセット」の可能性を持たせたいかどうかをユーザーに決定させます。
安全なパスワードリセットシステムを構築するには、信頼できる通信手段が必要です。プロバイダーが誰がパスワードをリセットしようとしているのかわからない場合、プロバイダーはアカウントの正当な所有者に対してのみパスワードをリセットしていることを確信できません。
したがって、最新のパスワードリセット機能のほとんどは、一定の信頼レベルと一定のリスク許容の間のバランスです。
非常に価値の高い、または国益にかかわるデータへのパスワードを扱う場合など、最も安全な面では、パスワードのリセットには、複数のステップによる確認の後、対面の会議が含まれる可能性があります。要求者、いくつかの生体認証識別子、およびいくつかの他の形式の識別に会った。これは、ほとんどのWebサイトでは非現実的です。
安全性が最も低い側では、ユーザー名が正しいことを確認し、パスワードをリセットするパスワードリセットプロセスを使用できます。はい、あります。いいえ、少しでも役に立ちません。
その間に、既存のすべてのパスワードリセットスキームがあります。ユーザーを信頼して強力な電子メールパスワードを選択し、ユーザーの電子メールプロバイダーを適切に保護することを決定できます。そうです。一部のプロバイダーはセキュリティに非常に優れていますが、他のプロバイダーは非常に優れています。また、パスワードのリセットプロセスを用意する必要があることと、ユーザーに電子メールを送信して本人確認を行うことはできないことを忘れないでください。リセットトークンの有効期限を比較的短くすることで、電子メールアカウントにアクセスするユーザーが受ける可能性のあるダメージを制限できます。1時間で十分な場合もありますが、価値の高いアカウントの場合は5分が適切です。ただし、これを行うと、ユーザーにとってある程度の不便を受け入れる必要があります。メールがすぐに届くとは限りません。
TOTPやSMSコードなどの2番目の要素を導入することができます。しかし、それはあなたが思っているよりも2番目の要素の方が少ないかもしれません。現在、多くの人が電話でメールを受信しています。 SMSによって送信されたコードを含む電子メールによるリセットは、実際には誰かがユーザーの電話を盗んだことを意味する可能性があります。TOTPアプリケーションと同じです。ユーザーがパスコードを設定しなかった場合、彼らの電話にアクセスでき、現在のコードを取得でき、それを使用するための短い期間があります。
ユーザーが電話をかけ、キーパッドから何かを入力するプロセスを持つことができます。電話会社の場合は、特定の回線から電話をかけていることを確認できますが、電話会社でない場合は、必要なときに人々が感心することはありません。特定の電話番号を保持してパスワードをリセットできるようにします。とにかくそれを偽装することは完全に可能です。
セキュリティの質問をすることはできますが、これらは一般に簡単に推測したり、忘れたりすることが多く、購入した最後の飲み物の価格を覚えていなかったため、正当なユーザーは自分のアカウントのパスワードをリセットできません。または、ウィンドウを通過する次の車両の色。
パスワードリセットを特定のデバイスにリンクし、「リセットトークン」を何らかの方法でデバイスにローカルに保存することができます（おそらくHTML5 localstorage）-一部のオンラインパスワードマネージャーでは、以前にログインしたデバイスから、関係のないデバイスよりも簡単にリセットできます端末。ただし、パスワードのリセットの理由の1つはデバイスの盗難であるため、これが唯一の方法ではありません。
これらすべてを検討した結果、セキュリティ予算が大きい大企業の多くは、何かを信頼する必要があり、セキュリティと使いやすさのバランスをとる上で最善の選択肢は、ユーザーを漠然と安全であると信頼することであるという結論に達しましたメールシステム。価値の高いアカウントの場合、追加のレイヤーが追加される可能性があります-AmazonではAWSアカウントに2FAを使用できます。Googleには、メールアカウントに対して有効にできる認証アプリケーションがあります。不明なデバイスからログインすると、Steamのメール確認コードが含まれます-これらはすべて基本的にプロバイダーにユーザーを確認できる方法が必要になります。
したがって、最良のオプションは、おそらく上記のものからの追加の方法を使用して、電子メールに固執することです。リセットがリセット要求と同じIPアドレスから行われるように要求することもできますが、これはユーザーがコンピューターにログインして電話でリセットの電子メールを取得しようとしたときに問題を引き起こす可能性があります。
または、パスワードのリセット方法がないことをユーザーに明確に伝えます。笑いすぎて手に負えないようにしないでください。特に価値の高いアカウントの場合、これは完全に正当です。一部のオンラインパスワードマネージャーはこれを実装しています。デバイスのデータを暗号化します。デバイスが紛失し、暗号化キーがわからない場合、データは役に立ちません。これは単なるランダムなバイトであり、可能なすべてのパスワードをブルートフォースで強制する以外に回復方法はありません。その場合、ユーザーのメールが安全でないことを心配する必要はありません。彼らは自分自身にパスワードをメールで送るかもしれませんが、それが常にどこかに保存されていることを確認します...
私はあなたのすべての要件を満たす解決策は存在しないと思います。大企業が何百万もの研究に費やしたものとは異なる、より安全なソリューションが必要です。電子メールを信頼できず、SMSなどの外部ソースを使用できず、セキュリティの質問に依存できず、オフライン（印刷）のセキュリティコードを使用せず、任意のWebサイトで使用可能であり、予算なしで実装する必要がある。勝負を受けて立つ！
セキュリティは、時間、労力、許容可能なリスクの間のトレードオフです。
1つの可能な解決策は、イメージを使用することです。 「 正しい馬のバッテリーの定番 」の写真など、思い出に残る画像のプールを用意します。 （xkcdに感謝）ユーザーがWebサイトにサインアップするときに、2枚の写真を見せ、これらがパスワード回復用の写真であることを伝え、パスワードとともにデータベースに保存します。多くの場合、パスワードを忘れたとき、それが何であるかについての一般的な考えを持っています。問題は、2番目の「e」が「3」であり、最初の「e」ではないことを忘れていることです（たとえば）。 「ほぼパスワード」はありません。画像は少し異なります。画像を正確に覚えていなくても、画像やそれに似たものを見たことがあることを思い出すことができます。たとえば、「ああ、「馬のバッテリーのようなもの」を見たのを覚えています。
これで、いくつかの変更を加えて、標準の「パスワードを忘れた」手法の1つを使用できます。ユーザーがパスワードのリセットを要求する場合、登録時にユーザーに表示される画像が含まれている場合と含まれていない場合がある画像のグリッドを提示します。 「これまでに見たことがない」オプションを必ず含めてください。次に、選択した画像とともにリクエストを送信します。ユーザーが正しい画像を提示して選択した場合は、有効なパスワードリセットリンクをメールで送信します。正しい画像が提示されておらず、ユーザーが「これらのいずれも今まで見たことがない」と選択した場合は、有効なパスワードリセットリンクをメールで送信します。それ以外の場合は、機能しないパスワードリセットリンクをメールで送信します。 （これは、攻撃者がこの時点で失敗したことを知らないためです。）
この時点で、誰かがパスワードを変更しようとしていることをユーザーに通知するメールを送信します。攻撃者がメールにアクセスして削除できる場合でも、ユーザーの電話またはその他のデバイスに通知がポップアップ表示される場合があります。また、パスワードが変更されていることを実際のサイトに通知します。パスワードリセットリンクによって生成されたページで、最初からの正しい画像を含めずに、もう一度画像テストを行います。 （これが、最初に2つのイメージを使用した理由です。）正しいイメージが再度選択された場合は、パスワードをリセットします。そうでない場合は、パスワードのリセットが失敗したことをユーザーに伝え、待機タイマーを開始します。 （5分、1時間、1日など）
正当なユーザーは、画像が表示されたときに画像を呼び出すことができ、パスワードをリセットできます。攻撃者は、ユーザーの電子メールへのアクセス権を持つだけでなく、どの2つの画像が表示されているかわからないため、2回正しく推測する必要があります。これは絶対に確実なことではありませんが、正当なユーザーが反応する時間を確保できるように、攻撃者を十分に遅くする必要があります。
方法：セキュリティリスク
- メールによるリンク：メールアカウントがハッキングされている可能性があります
- セキュリティの質問：個人情報は収集されたものをオンラインで検索できます（対象についてある程度の知識がある場合）
- 回復コード：実用的ではありません。人々は通常、それを紛失したり、自分のメールアドレスに保存したりします（これにより、方法1のセキュリティリスクが発生します）
私があなたなら、物理トークンを使用して2FAを実装するか、またはvrtjasonが指摘したように、暗号的に安全な（疑似）ランダムに生成された一意のテキスト文字列を実装します。しかし、物理的なアプローチを無視した予算なしのソリューションを探しているとおっしゃいました。したがって、私が考えることはあまりありません。受け入れる必要があるのは、ある時点で誰か（または何か）を信頼する必要があるということです。メールプロバイダー、ISP、またはこの場合は自分のユーザー（テキストの文字列を安全に保存するため）。
ここでの重要な側面は、ソリューションのバランスをとることです。
- ソリューション導入コストとサポートコスト
- セキュリティのレベル
- 使いやすさ
前述の制限と説明されているシナリオを考慮して、説明されている2つの回復方法を組み合わせて状況に対処することを検討してください。
すべての例で、ユーザーは忘れたパスワードを回復するための最初のステップとして必要となるセキュリティの質問として機能する個人情報を入力する必要があります。
簡単な組み合わせです。質問に適切に回答した後、Webサービスは回復リンクを送信してメールで送信します。攻撃者が攻撃を成功させるためには、セキュリティの質問に答えるために必要な個人情報と電子メールアカウントの両方を侵害している必要があります。
Challenge。秘密の質問を解いた直後、ウェブサイトはランダムな文字列を生成し、メールで送信します。ユーザーはそれを開いてWebサイトに戻り、そこに文字列を入力します。両方の文字列が等しい場合、パスワード回復プロセスが続行される場合があります。 （キーを交換するためにDiffie-Hellmanのバリエーションを実装することもできます）
PKI。これは、特別な場合にオンラインで可能なソリューションです。しかし、セキュリティの質問を使用する必要さえありません。ユーザーは単にウェブサイトにアクセスしてパスワードを要求します。ウェブサイトは新しいものを生成し、ユーザーの公開鍵で暗号化して、最後にメールで送信します。意図された受信者だけが、対応する秘密鍵でパスワードを復号化できます。もちろん、このソリューションは一般的なシナリオではほとんど実用的ではありません。ただし、高度なセキュリティが必須であり、ユーザー数が過剰ではない場合に実行できます。
多分ばかげたアイデアかもしれませんが、とにかくアイデアです。
登録すると、アカウントが失われた場合に使用する画像を要求されます。この写真は、ランダム、グランドキャニオンの素敵な夕日、家族の写真など、何でもかまいません。システムはこの画像のハッシュを生成して保存します（画像は保存されません）。
パスワードを紛失した場合は、この画像をもう一度提供するよう求められます。ハッシュが一致する場合、パスワードをリセットするように求められます。
だから基本的に私は通常のセキュリティの質問を写真のアップロードに置き換えます。
シンプルなソリューション。
ユーザーがパスワードのリセットを要求したら、次の画面でランダムなソルトをユーザーに提供します。
リセットページへのリンクを含むランダムなリセットキーをメールで送信します。
ソルト、キー、ユーザー、および有効期限の両方をデータベースに保存します。
リセットページでは、ランダム化されたソルトを他のページからコピーして貼り付ける必要があります。そうしないと、メールのキーが役に立たなくなります。
これは、電子メールプロバイダーを信頼する必要がなく、ユーザーがパスワードと同時に設定した情報を覚えておく必要がなく、どのWebサイトでも簡単に実装できるという要件を満たしていると思います。一部のウェブサイトではすでにこれを使用しているのを見たと思いますが、どのウェブサイトか覚えていません。
編集
少し高度なソリューション。上記と同じですが、ウェブサイトも次の条件を満たす必要があります。
- アカウント作成時にユーザーに暗号化キーを生成してもらいます。公開鍵は、ユーザーへのトラフィックを暗号化するためにWebサイトデータベースに格納されます。
- ユーザーがユーザーにログインするたびに、暗号化キーのパスワードも入力する必要があります。これにより、ページがjavascript/jqueryでローカルにデコードされ、Webサーバーに送信されることはありません。
- この同じキーは、ユーザー名を入力した後のすべてのパスワードリセットページで使用されるため、ユーザーの電子メールシステムを侵害した攻撃者はパスワードリセットプロセスを完了できません。暗号化キーを知っている人だけがそうすることができます。