Confirm email address on signup and change

[pdurbin]

Most sites confirm your email address on signup and Dataverse should do the same: https://support.twitter.com/articles/97942-confirming-your-email-address

In a 2015-04-30 Dataverse User Accounts and Auth Meeting @mcrosas and I talked about where email addresses come from (institution vs. user-supplied). Perhaps we wouldn't need to confirm email addresses from institutions.

User-supplied email addresses should also be confirmed when the user changes them.

[pdurbin]

A user reported this issue today at https://help.hmdc.harvard.edu/Ticket/Display.html?id=216399

[kcondon]

Needed to prevent using other people's real email address to create fake accounts, see RT 225535

[bencomp]

Email addresses are necessary to allow communication with Dataverse users through the application or outside the application (e.g. for special announcements). It is then essential that the address belongs to the person claiming the address.

I trust the IdPs/IdFederation to provide email address(es) that indeed belong to the user, but in other cases confirmation is appreciated, because the information in Dataverse could be sensitive and needs to be handled only by authorised people. Email address confirmation is a small step to aid authentication.

[posixeleni]

We should also add upon sign-up that the user must enter their email address twice in the UI to confirm that this is entered correctly. At the moment we only enter an email once and that could allow for people to put in an incorrect email address (typos).

Cc/ @eaquigley

[posixeleni]

@eaquigley here are two examples of a Sign Up page (facebook and patreon) which ask you to re-enter your email when creating your account:

[pdurbin]

http://policy.security.harvard.edu/sa6-appropriate-user-acccess says "SA6: Users must only be permitted to access a server or application after their current business need for access has been established" and lists "Review active accounts" and "Disable account access" under "How to Comply". I'm assigned this issue to myself because @mcrosas @kcondon @whorka and I have discussed how the RCE accounts need to be renewed periodically per http://projects.iq.harvard.edu/user-services/rce-account-renewal and we might want to contact Dataverse users in a similar fashion to make sure they still need access to sensitive data. Accurate email addresses on file per user will facilitate this task, should we choose to require access to data to be periodically re-verified, so this issue is a dependency for non-Shibboleth users (local or builtin users).

[pdurbin]

@bsilverstein95 I'm assigning this issue to you to start thinking about the implementation details. I'd suggest looking at how the password reset feature was implemented in #416 in the sense that we email a user a link with a unique token in it. You can see the passwordresetdata database table at http://phoenix.dataverse.org/schemaspy/latest/tables/passwordresetdata.html

In order to support this feature we'll need to add a column or two to a user-related database table. I don't think we should use the builtinuser table, which you can see at http://phoenix.dataverse.org/schemaspy/latest/tables/builtinuser.html . Rather, I think you should use the authenticateduser instead, which you can see at http://phoenix.dataverse.org/schemaspy/latest/tables/authenticateduser.html

By using the authenticateduser table we'll open the door for making this "confirm email" feature available to both Shibboleth and local/builtin users. @bencomp mentioned at #2170 (comment) that he trusts email addresses coming from his Shibboleth Identity Provider (IdP) but over at #2937 (comment) I'm thinking about "what if the Shibboleth Identity Provider (IdP)" doesn't give us an email address? In that case, we'd need to have the Shibboleth user supply the email address, and any user-supplied email address should be verified.

To me it's an open question of what the behavior should be for a user who does not have a verified email address. (This is all users in any production installation of Dataverse at this point.) Should they not be allowed to create datasets? Should they be allowed to create datasets but not get an email notification that they created one? The latter would be easier to implement... the rule would be that email would only be sent to users with verified email addresses. See the "prevent using other people's real email address to create fake accounts" note from @kcondon at #2170 (comment)

[djbrooke]

Notes from the meeting on 7/5:

• @eaquigley is going to work with @bsilverstein95 to move this through our usual development process, that is - mockups, user testing, then development and usability testing
• We'll plan to not allow unconfirmed users to take action in Dataverse (uploading, creating, etc.) instead of intervening later in the workflow (such as blocking at the publishing step)

[pdurbin]

@bsilverstein95 helped me reproduce the math challenge bug but I don't know how to fix it. The same math challenge bug was found in the harvesting branch at in #3265 but at #3265 (comment) @scolapasta indicated, "This is not related to this release specifically. It is the math challenge for the general exception. The other math challenge issue is still open for this user case." The other open issue is #3036. So it sounds like all of these math challenge bugs will be fixed once #3036 is prioritized. The easiest way to reproduce this class of bug is to type an incorrect username and password, as mentioned at #3036 (comment)

@scolapasta do you have any idea of how to fix #3036? @djbrooke should #3036 be worked on for 4.5.1?

[kcondon]

OK, all of the above is correct and sounds like math challenge is grouped with another reported issue. So marking as closed.

[kcondon]

Please merge confirmemail.sql with the update db script.

[pdurbin]

@kcondon done in fe675b7. Passing back to QA. The script is now called "scripts/database/upgrades/upgrade_v4.5_to_v4.5.1.sql".

[kcondon]

OK, looks good, ready for merge.

[amberleahey]

HI everyone, I'd like to confirm can we run a script or API call to turn this feature on in our 4.10.1 instance? We are noticing users can sign up with fake e-mails etc. because verification of e-mail is not required at sign up. Any help or suggestions for us? We'd like to enable this as it is a security risk. Thanks in advance, best, Amber

[djbrooke]

Hi @amberleahey - implementation of the verification mail functionality and the infrastructure to track whether or not an email is verified was implemented as part of a intern project a few years ago (hi @bsilverstein), but we have not yet tied it to the permissions system. It's something we'll need to work on in the future as we move towards sensitive data support.

[amberleahey]

gotcha, okay keep us posted! We would love to see this soonish, I'll reach out if there is someone on our team who can work on this.

[pdurbin]

@amberleahey great! Please keep us posted. For now, can you please leave a comment on #3300 because we'd love to hear from you and others what the "consequences" should be of NOT confirming your email address.