7

ユーザーのパスワードを mysql に保存することを検討してきましたが、MD5 や SHA1 などの暗号化アルゴリズムを使用してパスワードを保存する方法が一般的です。しかし、ユーザー x が自分のパスワードを忘れてしまい、そのパスワードを自分に送信したい場合はどうなるでしょうか? じゃあ何？彼女に md5 ハッシュを送信できません。この問題は、現実の世界でどのように扱われていますか。2 つのデータベースがありますか? 1 つはハッシュを比較し、もう 1 つはパスワードを忘れた場合に使用しますか? しかし、違いは何ですか。どちらも、その時点で接続している sql ユーザーによって読み取り専用になります。それで、あなたはそれをどのようにしますか？ありがとう！！

4

3 に答える 3

10

ユーザーにパスワードを送信しないことは、非常に標準的なセキュリティ対策です。代わりに、電子メール アカウントにアクセスする機能や、プロファイルに関する質問 (セキュリティの質問や住んでいる郵便番号など) に答える機能に関連付けられたパスワード リセット ユーティリティを提供します。

機能概要:

  1. ユーザーが「パスワードを忘れた場合のリンク」をクリックする
  2. ユーザーがセキュリティ チャレンジ情報を入力します (電子メール アドレス、必要に応じてセキュリティの質問)
  3. システムは、自動生成されたリンク (たとえば、クエリ文字列に生成された GUID を含む) を含むパスワード リセットの電子メールを送信します。
  4. システムは、リセット GUID、対象のユーザー、およびキーのタイムアウト時刻を含むパスワード リセット レコードを作成します。
  5. ユーザーは電子メールを取得し、リンクをクリックします。
  6. システムは GUID を照合し、パスワード リセット レコードを削除し、ユーザーをパスワード リセット ページに送信します。
于 2012-11-09T14:36:48.353 に答える
3

最善の解決策は、忘れたパスワードを入力しなくても新しいパスワードを入力できるリンクをユーザーに送信することです。

このリンクは 1 回だけ機能し、数時間しか機能しません。

新しいパスワードを作成してメールで送信しないでください。ユーザーはそのパスワードを使いたくなります (安全でないチャネルを介して送信されたという事実を無視します)。

于 2012-11-09T14:35:07.357 に答える
2

You are correct that passwords should not be stored in plain text (they should be hashed) and therefore cannot be delivered to users who have forgotten their password.

Essentially, what you desire is a way to circumvent your normal authentication scheme and you should first be aware that such a mechanism is a back door to the application.

Very often an assumption is made that only the desired user can access emails sent to the email address registered with your application. It is on this assumption that the 'standard' password reset mechanism is based. Here's my take on that:

  1. The forgotten password page is requested and the user is asked to enter their registered email address into a form which they then submit
    • The receiving code checks that the submitted email address is indeed registered and if it is:
      • delete any existing password reset tokens for this address from the appropriate storage
      • generate and store a new password reset token for this address
      • send an email to the user which informs them that
        • 'someone' has requested a password reset
        • to click the link if they do indeed wish to reset
        • to ignore the email if they did not request a reset
      • respond to the form submission with a page which says something along the lines of "if the address submitted was registered then a reset email has been sent"
    • If the submitted address was not one registered with the application then do nothing but respond to the submission with a page which says something along the lines of "if the address submitted was registered then a reset email has been sent" - just the same as if the address was a valid one (this is to make it more difficult for someone to discover email addresses registered with the application)
  2. The user then receives the forgotten password email and clicks the link within it. The link delivers the password reset token to the application.
  3. Upon receipt of a password reset token, the code checks that the token exists in storage and that it has not yet expired. If these hold true, then you assume that it must be the registered user who submitted the token and you can allow them to set a new password (a simple form with password and password confirmation inputs and a submit button and which contains zero personal information - not even their name).
  4. Once the password has been set, you can direct the user to the login page where they enter their credentials as normal.

This isn't a perfect scheme. It's a trade-off between security and convenience and make no mistake that it constitutes a back door to the application. For low value applications it is usually good enough.

Further reading:

于 2012-11-09T15:45:47.857 に答える