I'm using the following configuration for account registration:
- Visitors can register account
- Require a verification e-mail, but let users set their password directly on the registration form.

I have a website where registered users are aware of other users' email addresses. Since the module does not allow for multiple registrations on the same email address, identity theft is not possible if an email has already been registered to a user, and this security flaw is not relevant in this case. However, I'm using this for a college website where some students are not registered with the site but their email addresses are known to other students. The security issue I found is that users can change their account email address under the "Edit" tab in the account settings page to an unregistered email without having to activate through the newly entered email. The "Change own username" permission has no effect since this problem is present with this permission disabled.

For the time being, I found several workarounds (feel free to add your own):
Alter the user account edit form
Use one of the following modules to disable profile edit permissions:
http://drupal.org/project/userprotect
http://drupal.org/project/user_readonly
http://drupal.org/project/edit_own_user_account_permission

However this is an important bug to fix and should at least be noted on the module's page.

Comments

greggles’s picture

Does http://drupal.org/project/email_confirm help?

This seems like more of a core 'bug' than it is email_registration.

mfoda’s picture

I'm using the userprotect module as I never want my users to be able to change email addresses (use this module if you want more control over profile edit permissions, including every field and role). However, I can confirm that email_confirm is working.
As for: "This seems like more of a core 'bug' than it is email_registration."
Does this mean I should move this issue?

Thanks for the quick reply.

greggles’s picture

Does this mean I should move this issue?

Maybe. I'm not sure anything should really be "fixed" in core or in email_registration. If email_registration somehow makes the situation worse than core then please explain that. If not, then I guess move this to core and we can discuss what, if anything, deserves to be fixed.

mfoda’s picture

I would consider this an important issue in general since most site administrators who adopt the email verification policy do so because they need an extra layer of security for whatever reasons.

Why this is not strictly a core issue I think is because administrators use email_registration specifically to eliminate the username scheme (from the client-side at least), making email address the only piece of information tied to a user's identity. So even though the design of allowing user email change without verification when it is required for signup is counter-intuitive in both modules, the potential damages are larger for administrators who rely on email_registration since the assumption that users shouldn't be able to do this is is even more relevant in their case.

Since this is already a well-discussed issue and has been addressed in several modules, I don't think it should necessarily be fixed. However, it can be very bad business to run a large website using this module to find out about this issue only after much damage has been done. You can't assume that all administrators will be lucky to find out about this issue and fix it during development.

I would agree that you don't need to fix this since it's already been done elsewhere, if you just add two lines to the module's page though mentioning this you can help prevent very bad situations from happening.

Maybe: *Please note that users will be able to change their email address without verification even if you choose the email verification requirement. This is also a core issue but is more important if you using email address as the only determinant of user identity. See this for a fix.

Again, thanks for a great module and for the quick replies.

mfoda’s picture

Status: Active » Closed (fixed)