Jump to content

Email Change Validation for Existing Members


Emediate

Recommended Posts

Scammers are an increasing problem for community managers. Most of our moderation efforts (daily) now revolve around security rather than moderating actual discussions, which for a community of over 100,000 members is a nice problem to have, I guess.

However, the biggest issue we see these days is hijacked accounts. Not new accounts.

Their account has been compromised in an external data breach, and of course, because too many people use the same password everywhere, they eventually get into our community after monitoring their victim's email inbox for a while.

The first thing they do once they get access to a user's account is change their email address to one of their own so as to not alert the owner of the account. Sure, the system emails the original email address to let them know that it has been changed, but by then it can be way too late (as we have seen first hand).

Now I understand we can change the settings to require Admin Validation of email addresses, but that applies to New Member Registrations AND existing members. We don't want to have to approve every new member (we'd need a full time staff member just to do that daily). But we want to Admin Approve email CHANGE requests for Existing Members. That functionality doesn't seem to exist presently?

Link to comment
Share on other sites

Hypothetically, let's say we turned that on today. Of 100,000 users, some are not very active. 

So a hijacker can simply log in and will then be prompted to enable 2FA, and do so on the hijacked account.

We had this happen just last week. We use 2FA (Verify), but it is not yet mandatory. With large communities you can't just make major changes quickly.

Link to comment
Share on other sites

Forcing users to reset passwords on large communities, in my experience, should be saved only for when absolutely necessary (an actual security compromise or breach).

We did this once, and we caused massive distrust within the community about whether we had been compromised. The support tickets lit up in the hundreds. 

Appreciate your input, but still not the solution I am seeking.

The solution is a simple setting in IPS to require Admin Validation of email changes for existing members, not tied to the registration process.

Link to comment
Share on other sites

While I am not a software developer, nor the author of Invision, so I don't have all the answers - I'm just reporting the problem (which is increasing) 🙂

But, 1. The process would trigger me to look at the account. The then obvious giveaway is an IP shift from say, their typical location of Australia, no Nigeria or United States. That's the first sign. 

Secondly, there's a trend we have seen with these hijackers in the structure of a gmail email address. We are learning what to look for.

Yes, it requires manual intervention, but we are OK with that. It's the new role of the Community Adminstrator, the way I see it.

Link to comment
Share on other sites

Thank you for the answer. Its interesting to see what people would use these things for. The reason being, often you may be asking for the wrong things. Just from the above, you arent actually looking to validate all accounts. What you are actually looking for is to flag those 2 scenarios. 

The first one for example, might be worth a different suggestion, as what you are actually asking for there, is to have it flag when a user starts showing from a different country. 

The second, you should already be able to do. If there is a pattern in the structure of an email address, you can simply ban that structure of email address

Link to comment
Share on other sites

1 minute ago, Marc said:

The first one for example, might be worth a different suggestion, as what you are actually asking for there, is to have it flag when a user starts showing from a different country. 

 

Certainly. Now you understand the application, there might be a better solution.

1 minute ago, Marc said:

The second, you should already be able to do. If there is a pattern in the structure of an email address, you can simply ban that structure of email address

There's no pattern that I believe a "system" could pick up on, but just something I have noticed that I can recognise.

The first flag is probably the most important one here.

I'm not sure if this problem is more prevalent here in AU as a result of a major recent data breach, which is what we suspect, but I imagine this is a growing problem for all community owners with large databases of members now, around the world.

Link to comment
Share on other sites

Hi @Emediate,

That breach is one of many that has originated from Australia. Others include Latitude, Canva, Medibank and Service NSW to name a few. Unfortunately, we have no control over these companies or entities, but you do have functions built into Invision Community to mitigate the amount of spam, bots, “hackers”, etc, accessing accounts and taking advantage of them on your community.

I’m sure you are already aware, but there is an announcement from Google advising that inactive and/or unused Gmail accounts (not accessed within two years) would be permanently deleted. This action started on 1 December 2023 so hopefully it will prevent new accounts being taken over and manipulated. Existing accounts would have to be monitored and action taken accordingly or as they pop up.

Edited by Gary
Link to comment
Share on other sites

Posted (edited)

All understood, thanks @Gary - and you are correct in your suggest that Gmail plays a bit role in this. Most of the hijacked accounts (90% have been gmail), though many of the hijackings are accounts on our board that were either active, or only inactive for a number of months in some cases. 

The first thing they do once they gain access to our board is to simply change the email. My suggestion of Admin Approval for email change requests would allow us to intercept many of these.

Edited by Emediate
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...