validate membership before or after?

 

The process works like this.

  • If login fails 5x they are required to reset the password and are sent to the password reset page.
  • User enters email address
  • Link is sent to the email address provided. Token, email and time is recorded.
  • Back at the site, if token is valid, db is checked to find if email addr is actual member.
  • If they are a member then password reset continues, otherwise they are at a dead end.

    • But after getting this writen I am wondering if I should check if the email address is associated with an actual member account or not BEFORE sending the email.

    So that is my question should I be verifying both before and after or is just after they return to the site sufficient? Implications?

  • User submits multiple times incorrect Login Data ...

    • Don't make assumptions

    You should not make assumptions if the password was wrong or was it actually the username - neither should you notify the user about the exact error (for security reasons. Don't.).

    Let the user figure that out:

    Username or Password are incorrect.
    Need help?
    I forgot my username I forgot my password

  • If one of the above is clicked (popup this:)

    • Your email: _________________ Send me a [password/username] reset link

  • Check in the DB if the submitted email actually exists!
    (Don't even think about sending Reset links to emails that are not in your registry!)
  • Email exists ? Create an Reset Record in DB for that account and send the reset link to your user's email.
  • Email does not exist ? Who cares! For security reasons you should display the same success message! (You don't want malicious users to play guessing games? Up to you.)

    • You should shortly receive an email with a Reset Link to [theEnteredEmail] .
    Didn't get any Reset Email? Resend

    (Optional) Don't lock the account at this point. Keep it accessible. If you have an Active Reset Record you might want to erase it if the user successfully accesses it's profile with the "old" data. The user might be tired or just a bit senile, he might remember his account data in a bit - and might not desire to reset anything, and might want to ignore the Reset-Link email.

    Failed password attempts

    Grace-time Lock/secure the account only if you notice a high volume of consecutive failed attempts. Create a DB Log of that specific case.
    If the username exists in your DB, but the passwords were incorrect → send a discrete notification to the corresponding User Profile Email with all the data you gathered from the log

    Hi [user] , the [day/time] we registered [n] failed Login attempts to your account:
    [logFile]
    (n severity=high) We secured/locked your account. Please follow this link to unlock your profile. [unlockProfileLink]
    (n severity=low) To make your account more secure use a strong password (Here you can suggest a rest password link)

    User is really senile,

    opens his email and follows the Reset Link :

  • Check if the Referring Reset-Link still valid for that account.
  • Valid? Create a temporary session

    • (You should be able to recognize the user account from the Referring URL link that associates to that the account's "opened" expiring Reset Record token)

    Hi [user]
    Your new [username/password]: _____________
    Repeat [username/password]: _____________ UPDATE [username/password]

  • On submit check if temporary session or Token are not expired and both fields match .

  • If the referrer matches the temporary Reset Record (token) associated to the account - change the password/or/username .

  • Success? User must still properly login from the Login page!

    • Your [username/password] is now updated. You'll receive shortly a confirmation email.

    Login :
    Username: _________
    Password: _________ LOGIN

  • Success? Authenticate Login session
  • Fail? Repeat from above :)

    • EDIT: In case that you do not act as an email account provider:

    You should definetly check if the email address is valid, before you send the email. The token you send should always be associated with an actual account, as well. Otherwise it would be possible to change the password of any account you wish. So my suggestion is:

  • User enters email address
  • The backend checks if that email address is existing (which the user has told you during the creation of his account). If yes, then generate a token and associate that token with the account. If not, dead end.
  • Send the token to the email address. User can click on it, verifies that he is the owner of that email address (and of that account, too) and is able to change his password.

    • If you act as an email account provider you could send him the token to a second email address, which the user has told you, when he registered his account. A better solution would be to send him a token via text message or via mail.

    链接地址: http://www.djcxy.com/p/92686.html

    上一篇: Laravel 5.4：密码重置令牌自定义长度？

    下一篇: 在之前或之后验证会员资格？