63

Webアプリケーションにパスワード回復を実装したい。

秘密の質問は使わないようにしたいと思います。

パスワードをメールで送ることもできますが、危険だと思います。

新しい一時的なランダムパスワードを生成して電子メールで送信できるかもしれませんが、上記の点と同じくらい危険だと思います。

たとえばhttp://example.com/token=xxxxのように電子メールでURLを送信できますか。 ここで、xxxxはユーザーに関連付けられたランダムトークンです。したがって、ユーザーがそのURLに移動すると、パスワードをリセットできます。

4

12 に答える 12

86

私が空軍にいたときのセキュリティルールは次のとおりでした。パスワードを設定またはリセットするときは、ユーザーIDとパスワードを同じ電子メールで送信しないでください。そうすれば、誰かがパスワードをスヌーピングする電子メールを傍受している場合、セキュリティを侵害するために、両方の電子メールを正常に傍受し、それらを接続できるようにする必要があります。

「このURLにアクセスしてパスワードをリセットする」を使用しているサイトをたくさん見ました。何かが足りないかもしれません-私はセキュリティの専門家であるとは主張していません-しかし、それが新しい一時的なパスワードを発明して送信するよりも安全であるかどうかはわかりません。ハッカーが電子メールを傍受した場合、なぜ彼はそのリンクにアクセスして、正当なユーザーと同様に新しいパスワードを確認できないのでしょうか。セキュリティ上のメリットがないユーザーにとっては、余分な手間がかかるように思えます。

ちなみに、セキュリティ保護用の質問を使用しないことをおめでとうございます。このデバイスのロジックは私を逃れます。コンピュータセキュリティの黎明期から、「高校の名前や好きな色など、ハッカーが発見または推測できる自分自身に関する情報であるパスワードを作成しないでください。ハッカーは可能かもしれません。あなたの高校の名前を調べるために、あるいは彼らがあなたを知らないかあなたについて何も知らなくても、あなたが学校に行った場所の近くにまだ住んでいるなら、彼らは彼らがそれに当たるまで地元の学校を試すことによってそれを得るかもしれません。ハッカーがそれを推測できるように、少数の可能性のあるお気に入りの色など。代わりに、パスワードは、文字、数字、および句読点の無意味な組み合わせである必要があります。」しかし今、私たちは彼らにもこう言います。文字、数字、句読点の無意味な組み合わせを思い出すのに苦労している場合でも、問題ありません。高校の名前や好きな色など、覚えやすい自分の情報をいくつか持っていき、それを「セキュリティの質問」への回答、つまり代替パスワードとして使用できます。」

確かに、セキュリティの質問は、最初から間違ったパスワードを選択した場合よりも、ハッカーにとってさらに簡単になります。少なくとも、パスワードに個人情報を使用しただけの場合、ハッカーは、使用した個人情報を必ずしも知っているとは限りません。犬の名前を使いましたか?あなたの誕生日は?あなたの好きなアイスクリームの味は?彼はそれらすべてを試さなければならないでしょう。ただし、セキュリティ保護用の質問では、パスワードとして使用した個人情報をハッカーに正確に伝えます。

セキュリティ保護用の質問を使用する代わりに、「パスワードを忘れた場合は、画面の下部に表示されます。他人のアカウントにハッキングしようとしている場合は、絶対に禁止されています。下にスクロールします。」安全性はわずかに低下します。

不思議に思わないかもしれませんが、私が生まれた都市や最初の車のメーカーをサイトから尋ねられたとき、私は彼の質問に実際に答えることはしません。意味のないパスワードを教えます。

</ rant>

于 2010-04-29T04:11:49.220 に答える
51

まず、ユーザーのパスワードのプレーンテキストコピー、または暗号化されたバージョンを保存しないでください。ユーザーのパスワードのハッシュ化されたコピーのみを保持したい。

回復ソリューションに関しては、ユーザーのパスワードを変更するための回復リンクが私の経験では最良の解決策であることがわかりました。次回のログイン後に変更される新しいランダムパスワードを送信するのとセキュリティの観点からはほぼ同じですが、ユーザーにとってはおそらくもう少し便利です。それでも、リカバリURLは、妥当な短い期間の後に期限切れにすることをお勧めします。また、1回だけ使用できるようにすることをお勧めします。

于 2010-04-29T02:13:21.510 に答える
20

この問題に対するほとんどの解決策はセキュリティを弱体化させるため、何をすべきかを言うのは難しい. SMSの送信、コールバック検証、ワンタイムパスワードジェネレーター、またはパスワードを別の媒体に復元するその他のスキームを調査したい場合を除きます。

ただし、してはいけないこと

  • パスワードを送信します - 結局のところ、すでに述べたように、パスワードを持っていないからです。

  • 新しい一時パスワードを生成します。これは、パスワードを送信するのと同じくらい安全ではないだけでなく、サービス拒否攻撃の可能性にもつながります。私はそのサイトに行き、あなたのふりをして新しいパスワードを要求することができますが、(電子メールをチェックしていない場合) ログインできず、理由がわからず、新しい新しいパスワードを要求する必要があります.. .

トークンはおそらく行く方法です。それを受信すると、パスワードを忘れたという要求が通知されますが、確認しない限り、何のアクションも実行されません。また、リスクを制限するために、有効期限が比較的短いワンタイム トークンにすることもできます。

もちろん、多くはアプリケーションに依存します。mytwitteringfacetube.com で自分のアカウントがハッキングされるのを防ぐことよりも、明らかに財務情報やその他の機密情報を保護することが重要です。これは不便ですが、誰かがソーシャル ネットワーク サイトで誰かの ID を盗もうとする場合、自分のアカウントを開いて、盗まれたもので偽装することができるからです。とにかく情報。

于 2010-04-29T05:08:44.710 に答える
10

もちろん、元のパスワードは保存していないため、メールで送信することはできません(そうですか?!)。一時パスワードの送信(1回のログインでのみ機能するため、変更する必要があります)と、パスワードをリセットするためのリンクは、セキュリティの観点から同等です。

于 2010-04-29T02:12:33.133 に答える
5

秘密の質問法に対する態度がわかりません。パスワードを「BlueHouse」にしてから、「あなたの好きなものは何ですか?」という秘密の質問をするつもりはありません。そして答えは「青と家」です。セキュリティの質問は、実際のパスワードを取得するための魔法の鍵ではありません。これは通常、ファイルに登録されている電子メール アドレスに送信される新しいパスワードを取得する方法です。他にどのようにしているのかはわかりませんが、次の 2 つのいずれかを行っているようです。

1) ユーザーが「パスワードを忘れた」ボタンをクリックすると、新しいパスワードがユーザーに送信されます。

2) ユーザーは [パスワードを忘れました] ボタンをクリックし、セキュリティの質問に答えてから、新しいパスワードをファイルのアドレスに電子メールで送信する必要があります。

オプション番号2の方が安全だと私には思えます。

トークンを送信する方がパスワードを送信するよりも安全なのはなぜですか? メール アカウントがハッキングされている場合は、ハッキングされています。パスワード、トークン、または新しいパスワードをリセットするためのリンクがあるかどうかは問題ではありません。忘れないでください。ほとんどのサイトでは、「ハッキング用に新しいパスワードが次のメール アドレスに送信されました」とは表示されません。ハッカーは、ハッキングする必要がある電子メール アドレスを推測する必要があります。

于 2011-03-16T17:48:34.143 に答える
5

私はアンディに同意します。セキュリティの質問は通常、パスワードとは無関係ですか? (私の場合)質問と回答があり、パスワードとは関係がないことを意味します。これは偽のパスワード リセット リクエストを防ぐために使用されているようで、実際に使用されています。

想像してみてください - 誰かがサイトの「パスワードを忘れた」ユーティリティにアクセスして、無数の電子メール アドレスを入力したり、迷惑をかけたい 1 人だけを入力したりする可能性があります。その時点でパスワードがリセットされた場合、それらの電子メール アドレスに属しているユーザーは、パスワードがリセットされたことを電子メールで通知し、次にサイトにアクセスしたときに、リセットされたパスワードを使用してサイトにログインする必要があります。セキュリティの質問を使用すると、これを行うのは簡単ではありません。

Amazon が指定されたメールへのリンクを送信していることがわかります。また、DOS 攻撃を防ぐためにキャプチャを入力する必要があります。リンクなので、パスワードをすぐにリセットせず、ユーザーがリンクをクリックするとパスワードがリセットされることを意味していると思います。上記のシナリオでは、ユーザーは電子メールを見て「いいえ、私はそれをしていません」と言うだけで、パスワードを不必要に変更する必要はありません。セキュリティの質問により、最初の試行が妨げられ、正当なユーザーが最初に電子メールを取得できなかった可能性があります.

これに関するホワイトペーパーは次のとおりです。 http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html

これは実際、認証プロセスの主要部分として秘密の質問を推奨しています。また、電子メールで認証コードを送信して要求することは、オプションで含めることができる単なるアドオン レイヤーです。

于 2011-04-20T15:57:43.500 に答える
4

どの程度のセキュリティを確保したいかによって異なります。極端な例の 1 つはパスワード リセット プロセスです。このプロセスでは、メールボックスも危険にさらされる可能性があるため、ID などを使用して連絡を取り、本人であることを証明します。実際、人々はどこでも同じパスワードを使用する傾向があるため、これは非常に可能性が高いです。もう一方の端には、ランダムな新しいパスワードを電子メールで送信するだけの標準的なアプローチがあります。

「秘密の」質問と回答は、ユーザー名とパスワードの別の形式であり、通常は信じられないほど簡単に推測できるという致命的な欠陥があるため、使用したくないほど優れています。

トークンについてのあなたの指摘では、それが全体的なセキュリティに大きな違いをもたらすとは思いません. ユーザーがパスワードを変更できるようにするトークンを送信するか、ランダムなパスワードをすぐに送信するかは、大きな違いはありません。

トークンが一度だけ使用可能であることを確認してください。できれば、リクエスト後 +24 時間など、限られた期間のみ使用できるようにしてください。

そして、以前の回答で指摘されたように、プレーンなパスワードを決して保存しないでください。それらをハッシュします。できればを加えてください。

于 2010-04-29T02:50:12.060 に答える
3

これが私がそれを解決した方法です:

「users」テーブルにフィールドを追加retrieve_tokenしました。retrieve_expiration

ユーザーは、電子メールを提供し、キャプチャに入力して、パスワードのリセットを要求します。フィールドに対してランダムなハッシュ値が生成されます。retrieve_tokenつまりmd5($user_id.time())、 whileretrieve_expirationは次の 45 分で期限切れになる日時に設定されます。リンク付きの電子メールがユーザーに送信されます。

https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570

認証が必要な場合は、SSL を必須にする必要があります。メールと IP アドレスを保存するリセット要求をログに記録するためのテーブルを追加することもできます。ブルート攻撃の可能性を追跡するのに役立ち、必要に応じて攻撃者の IP をブロックできます。

パスワードのリセットを要求するための秘密の質問を実装することもできますが、誰かが要求を何度も繰り返すのを思いとどまらせるにはキャプチャだけで十分だと思います。

于 2013-12-06T23:48:28.050 に答える
2

@ジェイ。新しい一時パスワードを誰かに送信するだけでなく、URL にアクセスしてパスワードをリセットする理由は、セキュリティだけではありません。トークンを含む URL のようなものがなければ、ある人が別の人のパスワードをリセットする可能性があります。メールにアクセスする必要はありません。誰かに相談したいことがあれば、新しいパスワードのリセットを開始し続けることができます。次に、貧弱なターゲットはログオンしてパスワードを何度も変更する必要があります。

トークンを送信することにより、ユーザーがそのパスワードでログインして確認するまで、ユーザーのパスワードは変更されません。リセット メールのスパムは無視できます。トークンは、GUID を使用して新しいパスワードを生成するのと同じくらい (簡単ではないにしても) 簡単に生成できます。開発者にとって、それほど面倒なことではありません。

また、GUID は一意であるため (生成されたパスワードは一意ではない場合があります)、トークンをユーザー名に関連付けることができます。URL に間違ったユーザー名が指定されている場合、トークンは取り消される可能性があります (つまり、別の人がトークンを開始し、誰かがトークンを傍受した場合. ユーザー名が電子メールと同じではないと仮定します)。

于 2013-07-24T07:07:51.490 に答える
0

セキュリティの質問/回答について。Web サイトのユーザーとして、私は個人的にそれらを使用しません (私はそれらにゴミを入力します)。しかし、一部の人がここで言うように、それらは確かに役に立たない、または無意味ではありません。

次の状況を考えてみましょう: あなたのサイトのユーザーが昼食に行くためにデスクを離れ、自分のワークステーションをロックしていませんでした。悪意のあるユーザーがパスワードの回復/リセットのページにアクセスし、ユーザーのユーザー名を入力できるようになりました。システムは、セキュリティの回答を求めるプロンプトを表示せずに、回復/リセットされたパスワードを電子メールで送信します。

于 2013-04-19T00:15:12.677 に答える
0

これは、誰かがNode.jsでそれを行った方法の例です。基本的にランダムトークン、有効期限を生成し、トークンが添付されたリンクを送信し、reset/:tokenユーザーがそのトークンで存在することを保証するルートを持っています(これも期限切れではありません)。その場合は、パスワードのリセット ページにリダイレクトします。

http://sahatyallabov.com/how-to-implement-password-reset-in-nodejs/

于 2014-08-18T16:45:25.700 に答える