Svetozar Angelov

We have released a patch to address this issue. Please go to AdminCP > System > Support and apply the patch from the first/top left box. If you do not see an option to install the patch, you already have the latest release.

We have taken enough measures, I ask that you now take measures and look very carefully at the code from the beginning of March, because we have not had such problems before. It is clear that precisely from this period the problems with spammers on the IPS platform started massively. I can't sit all day and clean the forum of spammers after the version is paid for and obviously the problem is yours.

This is done from your file system, not your admin CP. So you create a file in the route directory named constants.php and add this
<?php define('DISABLE_MFA', TRUE); This will disable the google authentication you are struggling with, so you can log in

@Svetozar Angelov - Sorry to see you are having issues with spam here. I just wanted to pick up on where we are here, as there appears to be a lot of confusion, and I want to clear up where we are.
We understand you have an issue with spam, and I feel you believe we are in some manner ignoring this. Let me assure you this is certainly not the case. 
You have stated there is a "Hole" here, without any evidence of this in any way. Just an assumption. While I understand the frustration, this isn't going to help your issue. We have no known security issues on the platform, and from what my colleague has seen so far, it seems the users are logging in and posting as normal, and they are standard users, who have logged in with a password.

A few things to note on that. If they have logged in with the password, then they have the password. There is no way in which to get a users password on the software. To make this very clear. If I have access to your database directly, with your database credentials, and have full FTP access, I still could not obtain what a users password is on your system, due to the way the passwords are encypted. And they are encrypted with PHP methods useds throughout the internet (not only our software). Quite simply, nobody has gained the password of a user through your software. 
  My colleague has also shown you there where to check if a user has had their details compromised on another site. Most users will use the same passwords across multiple sites. So if a site elsewhere has been hacked where their password can be identified, they have an email/password combination that may work on the site. Therefore they would simply be able to log in with those details. I'm sure you understand, thats not something we have any control over
  You can use 2 factor authentication for all users. There is unfortunately an issue with the google one at present that we are looking into, but you can use question and answers. This would force users to at least have another action to log in, meaning if someone does know the password, they may stumble at the question/answer stage  
We are more than happy to look at your settings to see what we can advise. But you do appear to be quite hostile toward people who are trying to help you. Both staff and other customers. I can only assume that is out of frustration. A frustration I can fully understand. But please do help us to help you. We are on your side, and do not like spam any more than you do 🙂 

You can disable MFA by setting the DISABLE_MFA constant to false in your constants.php file!
if you’re hosted with us, please submit a ticket and we’ll take care of this 

Our community was hit with a huge number of spam registrations in March.  See the Tsunami topic. Some of the registrations got through while most were in a pending status (we use aMember for our current 3.3.4 board - register externally and then SSO).  Whether the registration got through or sat in the pending status (awaiting email validation), we had to evaluate the domain name of each registration.  If it was xx@buildingsupplies.com, we banned that domain because we want our community to have personal email addresses.  But many of the registrations had domain extensions like me.com, gmail.com, outlook.com, hotmail.com, aol.com with real names attached.  We couldn't ban those domains so we checked the registration to see if the username and the first name and last name were all the same.  If yes, then we deleted the registration.  All this to say it was an eye opener to see just how many real personal email accounts had been obtained on the dark web.
Maybe start compiling a list of the email addresses from accounts that you are deleting, and perhaps see if they compare to the IPS banned list?  Also, notate the date of registration? These suggestions are along the lines of what the IPS staff is suggesting, that these bad apples snuck in months ago.
One thing we do that helps to verify a registration is include a few additional registration fields: Country, State, City ... so we look at that information in the real registration or the pending registration and if the fields don't agree, that's a first flag, and if needed, we check the IP address of the origin and if that IP address location doesn't agree with the Country, that's another red flag.  
If these spammers have the login access to the actual email accounts which I think is what Jim M is inferring in the quote, then there doesn't seem to be anything you can do other than to ban that specific email address.  

Keep in mind that the biggest hole in any authentication/identity system is the human using it. Odds are that if that user setup several accounts around the internet with the same credentials, their email is more than likely also to be one of those. Your solution may solve the issue in some cases but odds are likely not in its favor. As the attacker, likely has access to their email as well.
Which is why using a non-email source, like a Two Factor Authentication code generation with a cell phone app, is generally more secure. As an attacker obtaining access to that 2FA source is harder.
The best case, would have been requiring it from the start of any community. That’s not always possible but the good news, you can require 2FA starting today and any new members or members who login will have it implemented.
You can also use the logout all members and change password requirements to ensure that users need to reset their password prior to logging in again. In conjunction with requirements around password difficulty, this will help hopefully change passwords for your users.
However, if you feel strongly about the code generating link to an email to login, you’re more than welcome to suggest that in our Feedback forum for further evaluation. 

ACP > Members > Force password reset

Regarding this,
They demanded money to avoid leaking my website's ID and password information. To test their capabilities, I asked if they could obtain the ID and password for three other random IPS-based websites. Within 10 minutes, they sent me the credentials for these sites, involving thousands of accounts for each.
What's most alarming is that these ID and password combinations were indeed functional on other IPS websites.
Even though it's not IPS's fault, there needs to be better login protection. The current 2FA system is insufficient for securing all accounts. Currently, members must manually register 2FA after logging into our website.
Implementing email code verification at login would be a more effective method to protect all accounts.
 
 

Yes, I am aware that ID and passwords are not stored as plaintext in the database but are encrypted. It's possible that the hacker found various IPS sites using a different ID/PW saving tool and organized this information to send to me.
However, there is a major flaw in the IPS login system. I know that 2-Factor Authentication (2FA) is available and can be enforced, but this is useless for people who have already left the website. A hacker could log in using the leaked ID and password and then register their own 2FA key.
Like many other websites, why doesn't IPS require email-based code verification when logging in? If this were possible, it could securely protect all accounts, including those of people who no longer use the website.
 

I'm afraid, this is not a security issue. However, it is a case of spammers trying to sneak under the radar and access counts they've setup in the past.. Keep in mind that a spammer can reset a password to an account if they have access to the email address tied to the account.
 

You will want to do the following Spam Prevention items mentioned in this guide: https://invisioncommunity.com/4guides/security-and-rules/spam-prevention-r9/
Looking at your registration form, you are still using CAPTCHA2. You will want to switch to hCAPTCHA to prevent more automated spam bots.
Check that your Spam Defense is configured correctly for our services in ACP -> Members -> Spam Prevention.
Configure the Flag as Spammer option to be used by you and your administrator/moderator teams to quickly remove spam posts and ban spammers.
You will also want to rotate your Question and Answer challenges frequently and ensure that they are things which you are target audience knows but is not easily Googled. This will prevent spam human users from registering.
If you are seeing spammers from a certain country that your community does not serve, you can also block them in ACP -> Members -> Spam Prevention -> Geolocation Settings.
Finally, if you believe spammers are gaining access to accounts through means of exposed credentials from the dark web. Enabling and requiring Two Factor Authentication will help prevent that.
Outside of the items mentioned above, the next steps would be to take moderation action. Require your base member group to have 1 or more posts approved by a moderator prior to them showing up to the rest of your community without being moderated. Use the automated moderation tools so that if a post is reported x times as spam, the system will automatically hide it for your team to review.
If any spammers do get through, be sure to use the Flag as Spammer option as that will report it to our system and help your fellow administrators.
I will say that no 1 spam prevention method will be 100%. However, hopefully, with all the above, it should cut enough down that you are able to not just wake up to a bunch of spam posts that plague your community. If you deploy the moderation techniques, you will not have your community publicly plagued by spammers.
Unfortunately, in the event that a spammer has dormant account(s) on your site and they have already surpassed an acceptable amount of posts (I say acceptable as some may be borderline that your moderation team may still allow) to bypass the moderation queue, the only thing that will help are successful moderation practices by humans and staying vigilant about the future with the above.

Can you please make sure that the cron is using the php8 executable? 

You're right, we've updated PHP version for this instance(fpm is used) soon, but didn't set the same php binary version for cron. It works now, thank you!