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 additonal 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_REQUIIRED"
}

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 Unauthourized and respond with an ErrorResponse object that contains an errorCode
4. clients, upon seeing the errorCode, should redirect to page for changing 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 signed token to authorize the password change

{
    "authourization" : {
         "username": "AzureDiamond"
         "expiresOn": 12345678,
         "signature": "<HMAC signature>"
    },
    "newPassword": "hunter3"
}