in reply to Re: Password required for email change
in thread Password required for email change

Naive answer: You already do. You can't get to the change option if you're not logged in.
i know that. what i was talking about was CSRF.
Cynical Answer: If someone else can get the ability to change your email, it's already compromised.
Do you know what CSRF is? I can setup a html form on a different website that has a masked button or even a javascript-submit. it will change your email address if you visit this page (and click the harmless looking button if you don't have javascript enabled).
My opinion: More trouble than it's worth in terms of real security enhancement.
well, if you knew CSRF you wouldn't say that.

with CSRF i have been able to automatically send myself a message everytime a monk visited my homenode (i tested this just to see if it worked). so if you visited my homenode i would have gotten e message by you. i could have also send out faked message to others. this is the same technique. and changing email and password is the most vulnerable kind of security hole. if you can do that you immediately can take over an account.

update: i tested it. everybody who wants to test it send me a message. be sure to open and save a form to change your user data before. otherwise your old user information will be all gone.

  • Comment on Re^2: Password required for email change

Replies are listed 'Best First'.
Re^3: Password required for email change (security)
by tye (Sage) on Apr 17, 2008 at 15:44 UTC

    That's why I surf PerlMonks via hostnames of my own design. Only me, my hosts file, and the web-server logs know for sure.

    Yes, it would be good to make quite a few improvements to PM security. And I think that I approve of your suggested change.

    I think an even better change would be to send an e-mail to the old address when a new address is set. The e-mail could even include a "recover my stolen account" link that would allow you to get back your account if the e-mail change wasn't done (intentionally) by you and had been used to get access to your account and to change your password. The e-mail would tell you what changed and encourage you to change it back and change your password (and maybe report the incident) if you didn't intend the change. Then the "recover my account" link would expire after a month, say.

    One complication to consider with your suggested proposal is that we only have two security items (password and e-mail) and it is easy to set a cookie and then to use your PerlMonks account for months/years without ever entering your password again. So one might suddenly realize that they lost their job and don't have access to their configured PerlMonks e-mail address and they also don't know their password, but they do still have a valid cookie on their home browser. With your change, they couldn't just change their e-mail. If changing one's password also requires one to enter the old password (not just have a valid cookie -- something that would make sense but that I'm not sure PerlMonks currently does but something that it certainly might do soon), then such a monk would be left with no way to recover their password nor update their e-mail address so they'd be left in a sort of limbo, praying that their one good cookie doesn't get lost somehow.

    It might be better to have four security items at PerlMonks: your password, your e-mail address, your secret token, and the answer to your "security question". Then you'd need to re-enter your password in order to be shown any of the other items or to make updates to any of them (including changing your password). You could have your password e-mailed to you with no extra hoops, like now. But you could also "recover your account" (by changing the e-mail address, which would send a notice to the old address) if you knew at least two of the other security items (or maybe knew one of them and had a valid cookie).

    Actually, I had plans for more general changes to prevent spoofed POST problems, which is where the "secret token" item came into my mind.

    And I think an equally simple and less problematic fix (compared to your proposal) would be to include a cryptographic hash of username plus IP address plus secret seed (know only to the gods) on the user edit page and require it for any changes on that page.

    So I'd prioritize the changes as follows:

    1. Add required hash to "user edit page".
    2. Send e-mail to old address when e-mail updated.
    3. Other security improvements to enable "recover my account"...

    - tye        

[reply]
      it doesn't have to be complicated. if you implement a token concept like i described in Is your web application really secure? ("CSRF") you have that technique for all actions. implement once, use it everywhere.
      about users having forgot their password and don't have access to their email address - well, i would expire the permanent cookie after a certain time. a permanent cookie means comfort, but if you have to login after, say, two months again, that's not that bad... forgetting passwords should not be encouraged.
      and to send an email with an approval link to the new and the old email address is a very common practice.
[reply]
      One thing I've done on some sites that seems to work well is to allow two different email addresses on file all the time, and to contact both in the event of a forgotten password. IT's rare that someone loses access to their work email and ISP/Yahoo/Hotmail/GMail at the same time.
[reply]

In Section Perl Monks Discussion