[WIP] Fix: Update password should require re-authentication

[kangmingtay]

What kind of change does this PR introduce?

In case a user's authentication token is stolen, this fix prevents an attacker from updating the user's password and completely taking over the account. Password updates should now require the user to submit their current password for re-authentication.

What is the new behavior?

# PUT /user requires a new param current_password
# current_password is a compulsory field if password field is present
{
  "current_password": "current_password",
  "password": "new_password"
}

curl -X PUT "http://localhost:9999/user" -H "Authorization: Bearer access_token" -d '{"current_password": "current_password", "password": "new_password"}'

Password Update Rules

1. Current password must be provided
2. Current password provided must match password stored in db
3. New password cannot be the same as the current password
4. New password must be of a minimum length

Limitations

• This is a BREAKING CHANGE so we should probably only merge it when we decide to release a major version (potentially with other breaking changes)
• The JS and Dart libraries will need to be updated appropriately

[awalias]

Looks good but we'll need to put this check behind a new env var because of the breaking change. Which defaults to the old behavior, it will save us a huge headache rolling it out.

[awalias]

I thought of a scenario where the user may not know the "current" password, i.e. if they were a magic link signup originally, but now wish to set a password 🤔

Perhaps if REAUTHENTICATE_PASSWORD_UPDATES(?) is true then the the new password would have to be set via the admin route instead

[kangmingtay]

I thought of a scenario where the user may not know the "current" password, i.e. if they were a magic link signup originally, but now wish to set a password 🤔

yeah good point, i discussed this issue with @dthyresson and we came up with an alternative implementation:

Instead of asking a user to provide their old password, we should send a confirm_password_update_otp to the user's email or phone number. We'll also change the existing update password endpoint to accept an OTP + new password which will be used as the "reauthentication" mechanism for a password update.

The rationale behind this is because gotrue allows a developer many options to sign-in (magiclinks, password-based, oauth) and asking for the old password doesn't really make sense for magiclinks & oauth, but we can be sure that there will at least be an email or phone number associated to the user.

[nodiesBlade]

Can we get this in? it's bizarre to me this was not incorporated when designing the user API's. If on a shared computer, or if a hacker gets a token credentials, the attack blast radius is much larger. They can literally change the user's password and get full access to the account

[kangmingtay]

closing this in favour of #427