誰かがウェブアプリケーションのセルフパスワードリセットメカニズムを適切に実装するためのリファレンスを提供できますか？
Webアプリケーションにセルフパスワードリセットを実装しています。その方法を知っています（事前登録された電子メールアドレスのユーザーへの電子メール時間制限付きパスワードリセットURL）。
私の問題は、開発者がその手法を使用していることを示すための参照が見つからないことです。誰かがこのテクニックに関するいくつかの優れたリファレンスの方向に私を向けることができますか？
いくつかの提案：
確認されるまでユーザーのパスワードをリセットしないでください。ユーザーのパスワードをすぐにリセットしないでください。ユーザーが事前に登録したメールアドレスに送信された確認リンクをクリックしたときにのみ、パスワードをリセットします。
CAPTCHAが必要です。ユーザーが自分のパスワードをリセットするように要求した場合、先に進む前にCAPTCHAを解決するように強制します。これは、自動化ツールが多くのユーザーに悲しみを与えようとするのを防ぎ、ユーザーに（ロボットではなく）人間であることを証明することを強制するためです。
ランダムネス。期間限定のパスワードリセットURLには、ランダムで推測不可能なコンポーネントを含める必要があります。必ず暗号品質のランダム性を使用してください。 _/dev/urandom_または_System.Security.Cryptography.RNGCryptoServiceProvider_からの出力が適切な選択です。 Rand()またはrandom()または_System.Random_からの出力は十分にランダムではなく、悪い選択です。 GUIDまたはタイムスタンプは十分にランダムではなく、適切な選択ではありません。
制限時間を含めます。リセット確認リンクは、妥当な時間（24時間など）が経過すると期限切れになります。リンクは1回だけ使用でき、使用するとすぐに期限切れになります。
メールに説明テキストを含めます。誰かがリクエストした場合に備えて、メールが送信された理由を説明するために、メールに説明テキストを追加することができます。自分のものではないアカウントにリセットします。 「誰かがアカウントusernameのパスワードのリセットをsiteにリクエストしました。このリクエストを行った場合は、ここをクリックしてパスワードを変更してください。このリクエスト、リクエストをキャンセルするにはここをクリックしてください。」
パスワードのリセット後にメールを送信します。パスワードが正常にリセットされたら、ユーザーにメールを送信して、パスワードが変更されたことを通知します。そのメールに新しいパスワードを含めないでください。
キャンセルを監視します。ユーザーがリセットを要求していないことを示すキャンセルリンクをクリックする頻度を監視するロジックを含めることを検討してください。これが特定のしきい値を超える場合は、システムオペレーターにアラートを送信すると便利です。また、あるリクエストのキャンセルリンクにアクセスした場合確認リンクにアクセスした後、それはそのユーザーに対する攻撃の潜在的な兆候です。たとえば、ユーザーのパスワードを無効にして、パスワードを再度リセットするように要求します。 （これは、次の攻撃に対する防御策です。攻撃者はユーザーのメールボックスにアクセスし、サイトのパスワードのリセットを要求し、確認リンクにアクセスします。攻撃者がユーザーの受信トレイからこれらの電子メールを削除しない場合、次に、実際のユーザーがメールを読んだときに、キャンセルリンクをクリックして、問題の可能性を示します。
HTTPSを使用します。リンクはhttps（http：ではなく）を使用して、さまざまな攻撃（たとえば、インターネットからWebサーフィンを行うユーザーに対するFiresheep攻撃）から保護する必要があります。カフェ）。
これらの操作をログに記録します。このような要求をすべてログに記録することをお勧めします。ユーザーのユーザー名をログに記録することに加えて、リセットリンクのユーザーへのメール送信を要求したクライアントのIPアドレスと、リセットリンクにアクセスしたクライアントのIPアドレスをログに記録することができます。
追加の読み物また、Troy Huntの優れたブログ投稿もご覧ください 安全なパスワードリセット機能の構築について知りたかったことすべて 。このリソースへのリンクを提供してくれた@coryTに感謝します。
最後に、非パスワード認証を検討してください。パスワードには認証メカニズムとして多くの問題があり、安全な保管場所など、ユーザーを認証する他の方法を検討する場合があります。それらを認証するための推測できない秘密を持つ彼らのマシン上の永続的なクッキー。この方法では、パスワードを忘れたり、ユーザーがフィッシングされたりすることはありませんが、ユーザーが新しいマシンまたは新しいブラウザーからのアクセスを許可する方法を提供する必要があります（おそらくユーザーの事前のメールアドレスを介して）登録されたメールアドレス）。 この調査ペーパー は、多くのフォールバック認証方法とその長所と短所について優れた調査を行っています。
Troy Huntは、この正確な質問について非常に素晴らしい記事を書いています。 安全なパスワードリセット機能の構築について知りたいことすべて
パスワードを送信できる場所は、パスワードをハッシュしないことを意味しますが、「プレーンテキスト」に復号化できる場所に保管します。これ自体は悪いです。
おそらく「最も」安全ではありませんが、より安全な方法は次のとおりです。
パスワードを要求したら、GUIDが埋め込まれたユーザーにパスワードリセットリンクを送信します。 GUID=のセッションは、hmm、1時間程度で期限切れになります。
さて、あなたの質問は、パスワード/アカウント回復プロセスをどのように構成すべきですか？それは、最適化する対象に依存します：手間のかからないユーザーエクスペリエンスまたは優れたセキュリティ。
優れたセキュリティが必要な場合：
- サインアップ中に、ユーザーは自分のメールアドレスを入力する必要があります。
サインアップ中に、ユーザーは認証用のセカンダリチャネルを入力する必要があります-携帯電話番号またはチャレンジ質問と回答（つまり、「 母親の旧姓 以上）」。
リカバリ中、システムはまず、上記のセカンダリチャネル（チャレンジ質問）、またはSMSを使用して携帯電話などにコードを送信することで、大まかな身元確認を行います。
上記の最初のIDチェックがクリアされると、システムはパスワードリセットメールを以前に入力したメールアドレスのみに送信します。これは、f.xを防ぐための追加の重要な手段です。 Sarah Palinタイプのエクスプロイト 。
電子メールには、新しいパスワードなどを含めないでください。 a）が、URLで提供される推測不可能なシークレット値を介してアカウントにリンクされている、サイトのHTTPS暗号化Webページへのクリック可能なリンクが必要ですb）は時間制限があるため、アカウント復元はリクエストされてからx時間しか機能しません。c）は、 newパスワードを作成するエンドユーザー。
すべてのアカウントリセットトランザクションに適切なログを記録し、人間がこれらを実際に監視して、疑わしいと思われる場合は対処する（IPアドレスfxのサーバーログを確認し、多くの要求が同じIPアドレスからのものであるか、インスタンスがユーザーが登録済みアカウントの所有者などとは異なる国からパスワードをリセットしようとしている）。
この複雑さを完全に回避することもできます：まだ初期の段階ですが、OAuth/OpenID/Facebook経由でサインイン、グーグル等はあなたのシステムからこの複雑さを完全に取り除きますが、 おそらくあまり確立されていないユーザビリティ で。
パスワードリセットを実行する最も安全な方法は、ユーザーIDに関連付けられた有効期限付きの大きなランダムな一意のワンタイムリセットトークンを生成することです。 SQLアクセス権を持つ攻撃者がトークンを使用して任意のユーザーパスワードをリセットする可能性があるため、トークンはデータベースでハッシュする必要があります。
リセットリンクは、リセットトークンを含む電子メールアドレスに送信する必要があります。ユーザーがリンクをクリックすると、トークンのハッシュがデータベースで見つかり、有効期限が将来の日付であることが確認されます。これらの条件が満たされている場合、ユーザーには新しいパスワードを入力するための画面が表示されます。
このプロセス全体必須はSSL経由で行う必要があります。そうしないと、ユーザーが行う前に、攻撃者がURLを盗聴してパスワードをリセットする可能性があります。
その他のヒント：
- 秘密は、攻撃者にとっては小さな煩わしさであり、ユーザーにとっては大きな煩わしさです。それらを完全に避けてください。
- パスワードのリセットを送信する前に、ユーザーに人間による確認のチャレンジ（CAPTCHAなど）を提示します。これにより、自動リセット要求が防止されます。
- リセットを実行するIPアドレスが、以前にアカウントに正常にログインしたことがあるかどうかを確認します。そうでない場合は、アカウント/ユーザーについてさらに詳細を尋ねます。アカウント作成年、生年月日、住所の最初の行。
- 「このメールはリクエストしませんでした」リンクを追加して、ユーザーが誤ったパスワードリセットリクエストを報告できるようにします。
アプリケーションに適しているかどうかは不明ですが、オンラインバンキングアプリケーションで使用されているものと同様のタイプのものは、SMSメッセージングで登録済みの携帯電話にリセットコードの半分を送信することです。攻撃者の観点から見ると、これは完全なPITAです。これを破るには、いくつかのチャネルの妥協が必要です。
SMSによる2要素認証1あなたは顧客とその携帯電話番号を知っています。SMS彼らに、それが本人であることを検証するためにWebサイトに追加する一意のコード:)
数ステップの手順にします。たとえば、次のようなもの：
- ユーザーがパスワードを忘れました。 「パスワードを忘れたので、次に何をすればいいのかメールでお知らせします」ボタンをクリックします（ボタンのラベルは異なる場合があります;））
- サーバーは彼にリンクを送信します
www.yourdomain.com/lostpassword?param_1=x;param_2=y - 彼はリンクをクリックし、自分自身に新しいパスワードを作成することができます
- 彼は送信をクリックします。すべてが完了しました。みんな幸せ
唯一のキャッチはポイント3）にあります。 XとYの値はランダムで予測不可能で、この1つの特定のアカウントに関連付けられている必要があります。また、1回限りの使用で、短時間（24時間？）後に古くなる必要があります。両方の値を、対応する列を持つ専用のテーブルに格納します。
| some_id | user_id | X | Y | expire_time
ユーザーが適切なリンクを使用しようとする場合、有効期限が満たされているかどうかを確認し、満たされていない場合は、パスワードの変更を許可します。