Account migration

[janvanmansum]

What this PR does / why we need it: Currently, when a user logs in to a migrated builtin user account for which the password is encrypted with a legacy hash algorithm (e.g., SHA-1), Dataverse will display a password reset page that also requires the user to accept the Terms of Use again. After a new password is provided it gets encrypted with the latest and greatest algorithm.

There are several limitations and issues with the current reset page:

• The introductory message talks about an upgrade from Dataverse 4.0, which is not necessarily the case.
• There is no way to only re-encrypt the current user password, i.e. the user is forced to provide a new one. However, for example DANS would like to just require the user to accept the Terms of Use again and not change the password.

Example of the current screen:

Which issue(s) this PR closes: N/A

Special notes for your reviewer: This PR introduces the following database settings:

• :SilentPasswordAlgorithmUpdateEnabled: if set to true, the "New Password" and "Retype Password" entry fields are hidden and the existing password is automatically re-encrypted on clicking the continue button.
• :PVCustomPasswordResetAlertMessage: the text that should appear in the blue banner at the top of the passwordreset page.
• :CustomPasswordResetButton: the caption of the button to continue. (If :SilentPasswordAlgorithmUpdateEnabled is enabled you should override the default text, which is "Reset Password", with something else, for example "Continue")
• :CustomPasswordResetAlertIntro: the introductory text.

Settings have been removed at the request of @scolapasta (see #7916 and #7916)

Note that, if the password turns out not to comply with the minimal security requirements, the user is presented with the regular password reset page on clicking Continue, and will be required to provide a new password.

Suggestions on how to test this:

1. Configure the Dataverse instance to automatically reencrypt password, e.g.:

    curl -X PUT -d "true" http://localhost:8080/api/admin/settings/:SilentPasswordAlgorithmUpdateEnabled
    curl -X PUT -d '{0} Our Terms of Use have been updated:{1} Please check the box below and click Continue' \
         http://localhost:8080/api/admin/settings/:PVCustomPasswordResetAlertMessage
    curl -X PUT -d "Continue" http://localhost:8080/api/admin/settings/:CustomPasswordResetButton
    curl -X PUT -d 'Please accept our new Terms of Use.  Also, note that you can connect your account to your institutional account, or ORCID, Google or GitHub account. To do so, log out after completing this step. Log in again with one of “Log in with our institutional account”, “ORCID”, “Google” or “GitHub”. ' http://localhost:8080/api/admin/settings/:CustomPasswordResetAlertIntro

2. Create an SHA-1 password, e.g., echo -n mypassword001 | openssl dgst -binary -sha1 | openssl base64
3. Update the builtinuser table:

   UPDATE builtinuser 
   SET encryptedpassword = '<result of previous command>'
   WHERE username = '<user to edit>';
   
   UPDATE builtinuser 
   SET passwordencryptionversion = 0
   WHERE username = '<user to edit>';

4. Log in. You should see a page similar to the one below:
   

(Note: you can customize the build number with the script dataverse/scripts/custom-build-number in the Dataverse code.)

Does this PR introduce a user interface change? If mockups are available, please link/include them here: See previous item.

Is there a release notes update needed for this change?: No

Additional documentation:

[coveralls]

Coverage decreased (-0.002%) to 18.946% when pulling c04330c on DANS-KNAW:account-migration into 3f04906 on IQSS:develop.

[djbrooke]

Hi @janvanmansum, thanks for sharing this. I appreciate the simplification of the workflow here.

Just so I understand, when the user encounters this screen in the new Dataverse installation, will their passwords have already been loaded into the Dataverse installation's database? Would this only be able to be used by installations where passwords from the old system were known and transferred?

Regarding the 4.0 text, I've adjusted the text on a currently-unmerged branch so that the old version is not referenced specifically.

[djbrooke]

Hi @janvanmansum, good to see you at the community meeting last week. I'm just making sure you saw my note above. Any thoughts?

[janvanmansum]

@djbrooke : sorry for the late response. Yes, this assumes that the user password is in the database already (just not encrypted with the preferred algorithm).

[pdurbin]

@janvanmansum hi, I'm just checking if this pull request is ready for review or if you're still working on it. I noticed a new commit from a couple weeks ago.

[qqmyers]

@janvanmansum - From a slack conversation - @pdurbin notes this needs documentation of the new settings, a short release note about the password algorithm change mechanism getting updated, and to be merged with develop to get rid of the conflict.

[djbrooke]

Thanks @qqmyers for discussing, and thanks @janvanmansum for following up. I think we both missed each other a few times. :)

I want @scolapasta to weigh in before we decide the merge this because we talked in some detail (prompting my question above in #7916 (comment)) - if there's a specific security concern about implementing this, let's discuss.

[scolapasta]

Hi, sorry for the delay in getting to this! I think the idea makes sense overall, but I wonder about having these settings? i.e. when we first added this we knew that we were requiring stricter passwords which was one reason to force the new password. But since this incorporates that (i.e. it forces new password if not strict enough), let's just make this the default behavior. In that way we can save a few settings and have all installations operate this way.

In short, rather than have this provide an alternative approach, let's have that alternative be standard.

@janvanmansum would you be able to make these changes?

[janvanmansum]

@scolapasta : OK, then we will remove the settings and make the behavior the same as currently with the following values:

• SilentPasswordAlgorithmUpdateEnabled = true
• PVCustomPasswordResetAlertMessage = "Please, accept the new terms of use before continuing"
• CustomPasswordResetButton = "Continue"
• CustomPasswordResetAlertIntro = "Our terms of use have changed, please check the box below and click Continue"

[kcondon]

@janvanmansum Thanks for the update. I think @scolapasta still needs to review but I decided to do a quick test of the password complexity workflow. It appears it is not functioning correctly in your branch at the moment. What happens is if I change :PVMinLength to be 10 rather than 6 and log in with an existing account, without setting :PVCustomPasswordResetAlertMessage, I see different results:

On develop branch, I see this:

On your account migration branch, I see this:

[janvanmansum]

@kcondon the issue you described above should now be fixed. Would your retest it please?

[scolapasta]

@janvanmansum @mderuijter could one of you get the latest from develop (now that 5.8 has been released?)

[janvanmansum]

@scolapasta : done.

[janvanmansum]

@pdurbin @scolapasta : I have merged back the latest develop commits to this branch.