From the readme.txt:


"This module uses hook_user to intercept when a user is
updating their user account. If the email address is
being changed then two emails are generated and sent
to both the user's original email address and their new
email address. The user must click a confirmation link
in the email sent to their new email address in order
for the change in their account email address to be
confirmed. The link in the confirmation email expires
after 24 hours."

It would be practical to include some light features for how to deal with potential account hijacking.

Lets say a user gets access to an account, and tries to change its emai address, for example if someone has forgotten to log out from an internet cafe computer, or the like:

- if emails are sent to both email accounts, and the new account is confirmed before the real owner discovers the email sent to the original email account, could this module offer some simple handling of this?

My suggestion is fairly simple:
- provide a way to reset the password by sending an email from the _ORIGINAL_ email account. This could be through using the original email field that already exist in the database. Not changing it, but allowing requests for a password reset to be emailed ONLY to that orignal account.

The idea is to make this possible without administrator intervention, and to be done at moment where the true account holder is in fact blocked out of his account if the hijacker has then also changed the password.

Of course, as core works now, a hijacker could reset the password directly without changing the email, but this module could offer a function to both automatically send password change notifications to the original account and to the currently registered email. That way, if a hijacker subsequently changes the email address with success before the original account holder reacts, then it is possible for the true account owner to resolve this on his/her own, without needing to bother the admins.

Alternatively, if the use of the original email is not adviseable;

- add extra fields to handle a "reference" email that can be set by the user, which stays throughout subsequent address changes, and which always gets notified upon address and/or password changes, and it would only be possible to change that reference email by clicking on a link send to THAT address, not to the currently active email.
That is obviously a bit more work, though.

The alternative could possibly be added to the mailalias module instead.
(I actually wonder if not these two modules should merge.)

Ref.:
http://drupal.org/project/mailalias
Core issue: http://drupal.org/node/85494

Comments

Taxoman’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
FreeFox’s picture

Hi all,

This is an old issue but I just wanted to suggest (feature request) something like that. The problem is described well but I have a slightly other and maybe simpler solution.

Why not send a "Do Not Change my e-mail" link sent in the mail to the original e-mail address?

This link would overrule the "confirm change" link (sent to new e-mail) so it would disable the "confirm change" link and in case the address has already changed, reset the e-mail address back to it's original value.

In case the password was changed too by the "Hijacker" a reset password could be performed by the user because it would be sent to the correct e-mail address.

Hope you like this one.

shrop’s picture

I did some checking and Twitter implements email account changes like Email Change Confirmation does. So there does seem to be a standard pattern at play here.

If I am following correctly, a user could hijack an account like this:

  1. Having access to a users session, request an email account change (note: they can't change the password without the original password at this point)
  2. Accept the change confirmation emailed to their email address (the one that requested the change for)
  3. Use forget/password process to email a one time URL to reset the account's password and they now have full access to the account

Does the above state the issue at hand?

I would suggest we find patterns already in use that address this hijacking scenario before coming up with new ones that may have issues. Does anyone know of such existing patterns where the old email address might have something like a cancel the request?

Also, I did notice that Twitter offers to cancel the email address change in the UI. This would be a nice related improvement.

Example from Twitter in the account settings UI:

Check your email (user@example.com) to confirm your new address. Until you confirm, notifications will continue to be sent to your current email address.
Resend confirmation · Cancel this change