Emediate

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.

Certainly. Now you understand the application, there might be a better solution. 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.

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.

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.

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.

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?

It was a firewall issue, resolved now. Thanks.

Nevermind.

Since a recent update (can't say which exactly), the RSS Feed Imports are not working. Existing feeds are still working, but when you add a new one - no matter what you do or what feed it is, it just says: No entry is made in the System Log either. We have tested this with existing working RSS feeds by setting them up again, and get the above. We have also tested with known and checked RSS feeds - no matter what the error is the same.

Fair call. Totally the opposite of our use case sadly.

Why would allow the recipient of an invoice to cancel it? Seems backwards to me. Admin should be able to cancel an invoice, but not the other way around.

Too late! Haha. We've been preparing for 6 months now. Removing redundant plugins, redeveloping others into apps, trying to second guess what we will and won't be able to do. Overall, it's been a long overdue process for us anyway, with at one stage over 60 different plugins and various things! Our board is running all the better for it now, but bring on V5!

Liking what I see so far! 🙂

Does flagging a spammer also remove all the PMs they may have sent?

Keen to try. This is going to be a major evolution of our (large) community and I would like to contribute my input and have a say on its direction (and shape) into the future, please.