Difference between revisions of "Password reset strategy"

Revision as of 15:32, 10 August 2017

Introduction

As part of standard operating procedure, the system needs to help users who have forgotten their password or user id in a simple and secure fashion, without any interaction of support staff.

Common attack vectors

• Password resets issued by someone as part of a denial of service attack
• Forged mails with reset links in sent by hackers or scammers
• Compromised mailboxes

Aims & key points of interest

• We never reveal more information than absolutely necessary
  • No usernames, passwords, personal information (such as first or last names etc.)
• Users do not like automatically generated passwords
  • They like to set their own passwords
• Sending a new password or a one-time password/code in an email is insecure
• The password reset link inside the email will only be used:
  • For a short period of time (e.g. 48 hours)
  • Until such time as the password has been reset
• The password reset link will be secure, and any modification must be detectable
  • The user's mailbox may be compromised in the future; the link must not be modifiable (e.g. by changing the username, timestamp etc)

Password policies demanding upper/lower/number/symbol or frequent change encourage stupid password selection (such as "Pa$$w0rd", or "Qwerty!@£111", "Qwerty!@£112" etc.) and/or insecure behaviour (such as writing them down). A far better approach is to allow their modern browser to generate a random one and store is securely, or to encourage them to choose a sentence of, say, 20+ characters made up of four or five words. Encourage them to avoid well-known sentences, as things like "i think therefore i am" and first lines of Shakespeare will start appearing - guessable, and thus insecure.

Process

There are two possible initiators:

• The user has forgotten their user name, or
• The user has forgotten their password.

We do not need to care about which piece of information they have forgotten. We will use their registered email address to send them a link allowing them to set their password.

• User clicks "I've forgotten my password"
• The user is prompted for their email address.
• A password-reset URL is generated.
• The URL is emailed to the user's mailbox.
• The user clicks the link
• The URL is validated by the server
• The user is presented with the customary two-password-boxes

Absolutely nothing in the system changes until this final stage is complete:

• The new password is saved

Password reset URL

The password URL comprises the following information:

  <scheme>://<host>/security/resetPassword/<userId>/<timestamp>/<hmac>

Where:

• userId is the UUID associated with the user's account - it is not the username used to login.
• timestamp is the time that the password reset was requested.
• hmac is the HMAC which encodes the other two variables, thus preventing their alteration.

Additionally, the HMAC uses two further mix-ins (but not present in the URL):

• A secret.
  • This prevents anyone else from generating a valid HMAC.
• A hash of the username, email, salt and the last-modified date
  • When a new password is saved (along with a new salt and modified date), used URLs will no longer be valid (without needing to store them).

Email content

The actual email should include minimal personal information, but should clearly indicate the origin of both the email and the IP of the resetter.

Subject: Rabora password reset link

  At 16:00 on Thursday 10th August 2017, someone from 10.11.12.13 (some.hostname.com) asked to reset your password.

  To reset your password, please click here:

   https://auth.rabora.com/security/resetPassword/8a8e70d0-9055-486a-9892-06a2accdcfe2/1502377423/de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9