ユーザーがパスワードを忘れた場合、より安全なオプションは何かと考えていました
- ランダムに生成された新しいパスワードを電子メール アドレスに送信します (データベース内のすべての電子メール アドレスが機能することが確認されています)。
または
- ユーザーがパスワードをリセットできる特定の期間内に有効期限が切れるリンクを含む電子メールを送信します。
後者が追加のテーブルを使用するという事実を除けば、より安全でより良い方法は何だと思いますか?
ユーザーがパスワードを忘れた場合、より安全なオプションは何かと考えていました
または
後者が追加のテーブルを使用するという事実を除けば、より安全でより良い方法は何だと思いますか?
パスワードが記載されたメールを送信する場合は、次のことを意味します。
したがって、パスワードを電子メールで送信するのは安全ではないようです...
ユーザーとして、ある種のトークンを含み、しばらくすると期限切れになるリンクを使用すると、パスワードが「より安全」であると感じるでしょう。
その「しばらくすると有効期限が切れる」という部分は重要です。ところで、誰かがしばらくしてからリンクをクリックした場合(たとえば、ユーザーのメールボックスにアクセスした人)、リンクが新しいパスワードの生成に使用されないようにします。
もちろん、これは「メールボックスを検索」してパスワードを見つけることができないことを意味します -- しかし、いつでも新しいパスワードを求めることができます。また忘れてしまいました ^^
ユーザーがパスワードをリセットできる特定の期間内に有効期限が切れるリンクを含む電子メールを送信します。
あれ、間違いなく。
電子メールは常に平文で (サイト接続ができない可能性があります)、より多くのマシンにアクセスできます。パスワードを電子メールに入れないでください。一時的なリセット トークンは、後でメールボックスがハッキングされた場合、トークンが使用できなくなることも意味します。
後者が追加のテーブルを使用するという事実は別として、
その必要はありません。特定のユーザーが特定の期間内にパスワードをリセットすることを承認する暗号トークンを生成できます。余分なデータは必要ありません。
HMAC ベースのメッセージ認証コード (ファンシー ハッシュ) を使用した例:
details= user_id+' '+token_expiry_timestamp
mac= hmac_sha2(server_secret, details)
token= details+' '+mac
次にtoken
、クリック可能な URL の一部としてメールでユーザーに送信します。クリックバックを受け取ったらmac
、サーバー側の秘密を使用してそのユーザーと時間をどうすべきかを判断し、渡された mac と照合します。一致する場合は、以前に署名したパスワード リクエストである必要があります。
user_id, token_expiry_timestamp, mac= token split on ' '
details= user_id+' '+token_expiry_timestamp
if hmac_sha2(server_secret, details)!=mac
complain
else if token_expiry_timestamp<now
complain
else
allow password for user_id to be changed
これには状態は必要ありませんが、使用状況を記録しない場合はトークンが複数回使用される可能性があるため、有効期限を短くする必要があります。
人々が無視しているように見える違いの 1 つは、たとえば Web アプリケーションを例にとると、通常、パスワード リセット オプションは、サイトにアクセスし、パスワードをリセットしたいアカウントのユーザー名/ログインを知っている人なら誰でも利用できるということです。
ユーザーがパスワードをリセットできるようにするためにクリックする必要があるリンクを電子メールで送信することにより、ユーザーが誤ってまたは悪意を持って他の人のパスワードをリセットすることを回避できます。パスワードのリセットを依頼したのではないので、このメールは無視してください。」
それ自体がセキュリティ リスクではない場合でも、確認なしでパスワードをリセットすることは大きな迷惑になる可能性があります。
明らかに後者の方がはるかに安全です。メールははがきのようなものです。読みたいと思えば誰でも読める。また、パスワードが変更されたら、電子メールを送信してループを閉じます。
ランダムな 1 回限りのパスワードを電子メールで送信します。
最初に到着したときにパスワードを変更するように強制します。
パスワードを変更したことを通知します。
ランダムなパスワードを送信することは、リンクを送信することと同じくらい危険です。つまり、誰でも最初に電子メールを取得し、最初にユーザーとしてログインできます。
変更を強制することで、最初に取得した人はパスワードを設定しないと再取得できなくなります。
変更をユーザーに通知すると、パスワードが変更されたことがわかります。これは、攻撃者が実際にログインして通知メールを変更する前に発生する可能性があります。
そのため、誰かが最初にサイトにアクセスした場合、元のパスワードが無効になるため、ユーザーへの元の電子メールは機能しなくなります。また、パスワードの変更が通知されます。
これにより、彼らが現れて自分のアカウントにログインできないことに気付いたときに、システム管理者に通知する機会が提供されます。
これらのいずれも、電子メールを傍受して一部のアクセス権を取得する人物の能力を阻止するものではありませんが、少なくとも、元の既得のユーザーに何かがおかしいことを知らせることができます.
どちらも同等であると述べている人もいますが、これは次の理由から正しくありません。
1) リセット リンクを使用すると、攻撃者が電子メールにアクセスし、リセット リンクを使用してパスワードを変更した場合、実際のリセット メールと通知が攻撃者によって削除された場合でも、ユーザーに警告が表示されます。ユーザーがパスワードのリセットを要求し、攻撃者がランダムなパスワードを (かなり後で) 見た場合、パスワードを郵送すると、攻撃者はユーザーに警告することなく、サイト上のユーザーのアカウントにアクセスできます。
2) また、パスワードをメールで送信すると、ユーザーは他のサイトでパスワードを再利用するように誘惑される可能性があり、メールにアクセスできる攻撃者は、他のサイトがアカウント回復によるアカウント乗っ取りに対して脆弱でなくても、他のサイトにアクセスできます。
電子メールで送信されたランダム パスワードとリセット リンクの両方を使用すると、攻撃者がユーザーの電子メールを制御すると、ユーザーのアカウントにアクセスできます。この場合にできることは、ユーザーのハンドル数によって異なります。たとえば、プライマリと代替の電子メール アドレスを持っている場合、リセットが要求されて使用されたとき、またはそれらが使用されたときに、両方の電子メール アカウントに通知を送信する必要があります。電話があれば、メールに加えてテキストを送ることもできます。使用状況自体を監視することはできますが、それは困難です。
その他のいくつかの問題:
リンクは複数回使用できますか? 有効期限が切れて予測不可能な値を持つこと (MAC が接続されているため、サーバーの状態なしで検証できる) とは別に、アカウントのパスワードを複数回リセットしようとした場合 (登録の成功/失敗、登録の成功/失敗、リモート IP アドレス、タイムスタンプなど) を削除し、最初に中止して、アカウントを非アクティブな状態にします。
アカウント復旧フロー (アカウントの価値によって異なります) を介してアカウントの乗っ取りを防ぐために、より多くの防御メカニズムが必要かどうかを確認するために、どの程度の悪用が発生しているかを確認することをお勧めします。
この場合、可能であればメールアドレスやその他の連絡先情報を最新の状態に保つことも非常に重要です(メールアドレスは使用されていない場合はリサイクルされます)、メールアドレスやその他のそのような情報を更新/追加する方法と通知.
いつものように、通知 (テキスト、リンク、ランディング ページ) がフィッシング詐欺に簡単にならないようにしてください。
もちろん、これらの問題のいくつかは、大規模なサイトを持っていない限り、あまり関係がないかもしれません.
私はいつも、ハッシュコードを設定してリンクを提供するのが好きです。
その後、ユーザーにメールを送信して、パスワード回復リンクを要求したことを知らせ、設定後にパスワードが変更されたことを伝えることは、通常、違反があった場合の適切な礼儀です。
ユーザーは、意図せずにパスワードが変更されたという電子メールに非常に迅速に反応します。
残念ながら、本当の「安全な」方法はありません。ピンが役立つセキュリティの質問はありますが、真に安全になることはありません。
URL がパスワードなどを要求しない限り、ランダムに送信されたパスワードよりも優れていますが、パスワードがプレーン テキストで受信トレイに残らないという理由だけです。
言い換えれば、リンクは機会の窓を減らします。
bobince のソリューションからの拡張... ここでは、ユーザーはパスワード リセット ページで userId とトークンを再入力する必要があります。
パスワードのリセットページのリクエストに応じて
urserId = Input userId
token = Randomly generated token (or one time password)
tokenExpire = Decide token expiry date/time
Store in DB tokenExpiry for this urserId
urlToken= MD5 hash value of (urserId + token + tokenExpire)
pwdRestURL = server pwd reset url + "?urlToken=" + urlToken
Send above generated URL and make sure you do not
include either of userId or token in email
Display token to user (This is to be used on password reset page)
.
パスワードリセットページ (上記の pwdRestURL URL を使用)
urlToken = Token from URL request
userId = Input userId
token = Input token
tokenExpiry = tokenExpiry from DB for this user
resetToken = MD5 hash value of (urserId + token + tokenExpire)
IF
resetToken == urlToken
AND tokenExpiry for user is valid
THEN
Clear tokenExpiry
Allow user to change password
ELSE
Display Error
END IF
.
上記のアプローチの利点:
いくつかの回答を繰り返しているかもしれませんが、最近パスワード回復ツールの不具合がいくつか発生したため、回答せざるを得ません。同僚の個人アカウントの 1 つが侵害され、Google がホストするドメイン アプリが侵害されました。削除されていないプレーンテキストのパスワードと、Google で検索可能な愚かなパスワード回復の質問により、他のアカウントも侵害されました。
私は4 時間後に有効期限が切れる電子メールのリンクを強く支持しています。リンクを受け取った後、アカウントの1つにログインして4時間そこに座って、それがまだ侵害されていないことを確認しました. 24 ~ 48 時間は、それを行うには長すぎます。4時間は長すぎました。ユーザーが次回のログイン時に変更する必要があるランダムに生成されたパスワードが 2 番目に適していますが、実際にログインしているユーザーに完全に依存しています。パスワードは永久に変更されますが、ユーザーがリンクで何もしない場合、パスワードは変更されません。リセットされます。
システムを危険にさらそうとする熱心な個人に対する完全な解決策はありません。他よりも優れたソリューションがあります。
リンクを送信して、後でパスワードをリセットできるようにします。これにより、パスワードをリセットしようとしている実際のアカウントをいくらか確認する必要があります。メールを送信せずにパスワードをリセットすると、誰でもサイトにログインして他のユーザーのパスワードをリセットできます。これにより、サービス拒否タイプの脆弱性が作成されます。
ceeyajoz を除く全員が、欠陥のあるロジックを使用しています。セキュリティについて考えるのは難しいです。
どちらの場合も、平文の電子メールを使用します。電子メールがハッキングされると、どちらも同様に安全ではありません。
メールがハッキングされているため、URL の有効期限が切れても関係ありません。ハッカーは別のパスワード リセット URL を要求するだけです。一時パスワードが変更された場合、ハッカーは新しいパスワードを要求することができます。いずれにせよ、あなたはめちゃくちゃです。
したがって、パスワードを送信するだけです。これにより、ユーザーが新しいパスワードを選択するための手順が 1 つ少なくなります。
編集 「パスワードを送信する」と言ったとき、新しいランダムパスワードを送信するOPのコンテキストでした。
私は意志のプロセスに同意します。
ただし、与えられたオプションからのみ選択する場合は、どちらのオプションも基本的には電子メールで情報を送信するという点で同じですが、後者の方がより一般的な方法だと思います.
ハッカーが新しいパスワードを要求した場合、ユーザーの古いパスワードは機能しなくなります。少なくとも後者のオプションでは、実際にはユーザーの詳細は変更されません。