Motivation

With the addition of PLFM-5356, users are blocked from changing their passwords into a password on the known, common password list. However this does not stop existing users from still using a common password if they've set it before PLFM-5356 was implemented.
In order to ensure that users are not using passwords susceptible to dictionary attacks, we must make users who are using weak passwords change their passwords.

Solutions that were ruled out

• Force every user regardless of password strength to reset password - This would not only be annoying for users who do not use common passwords, but would also not prevent an attacker from dictionary attacking an inactive user's weak password and verifying that they use this password.
• Perform dictionary attack against our own database and mark the users with common passwords - There would also be security concerns for how we would want to store the results of this investigation. We would not want to log usernames of the users w/ weak passwords. At most, this would give us a statistic on how many users are affected.

Proposed solution

Currently the reason field in ErrorResponse is reserved for a human-readable error message. We should also introduce an additional field errorCode that defines an Enum which the clients can use to decide how it would like to handle the error.
For example, in the case of the password change required:

HTTP ERROR 401
{
    "reason":"You must first change your password!"
    "errorCode": "PASSWORD_CHANGE_REQUIRED"
}

1. User logs in via the POST /login API with a username/password
2. Check that the user's password is not in our list of known, common passwords.
3. If it is, still return with HTTP 401 Unauthorized and respond with an ErrorResponse object that contains an errorCode.
4. Clients, upon seeing the errorCode, should redirect to page for changing password.

Resets should be done via the EmailResetChangePassword  option instead of oldpassword/newpassword so that the old, weak password can't be used to change the account password

API Changes

Currently, our POST /user/password takes

{
   "sessionToken": "<user session token>",
   "password": "myNewPassword"
}

This is insecure because it does not require checking the old password in order to change to a different one.

Additionally, our POST /user/password/email service, which sends a password reset email is actually just emailing a sessionToken to the user's email address. The token is NOT SCOPED and allows anyone with the token to make any API call on that user's behalf.

Instead, we should have a single API for changing the password with 2 ways to authorize the password change.

There would be an interface ChangePassword:

{
    "password": "myNewPassword"
}

UserChangePassword for a user who wants to change their password when they already know their old one

{
    "username": "AzureDiamond",
	"oldPassword": "hunter2",    
    "newPassword": "hunter3"
}

EmailResetChangePassword for changing passwords via email. This would use a token to authorize the password change.
OWASP recommends that the token be invalid after immediately after being used.

OWASP cheat sheet also recommended that during the password reset process, we should not indicate for which account the token will perform a password reset. However, we determined that this sacrifices usability (users not knowing for which account they have reset password) while providing minimal security benefits. Since we already have a "People Search" feature, it is implied that usernames and consequently userIds are public information.

If using a database for the token, only the hash of the password reset tokens should be stored. This is important should an attacker gain read-only access to the database via some mechanism such as SQL injection(we should be sufficiently secure against this specific case), they would be able to change any valid existing tokens.

Another option is to use a Password token mechanism similar to Django's PasswordResetTokenGenerator, which avoids storing any database information because the token uses a HMAC(userId, hashed password, last login timestamp, current timestamp). The information sent over email is userId + current timestamp + HMAC. This link provides a pretty good explanation of how it works.

{
	"userId": <random int>
    "authorization" : <UUID4 TOKEN>,
    "newPassword": "hunter3"
}

Email will be sent to user on successful password change regardless of which path the password change occurred.