Is coreForce secure from hacking?

If a customer claims that their credit card information was compromised after entering it in a coreForce site, you can check in your merchant service portal (e.g. authorize.net) to see if there was anything unusual about the transaction. Most of the time, the issue has nothing to do with coreForce. Either the bank declined the transaction due to an overly aggressive fraud detection system or the customer's credit card was compromised by factors unrelated to coreForce (for example, keylogger malware on their computer, or a card guessing algorithm that happened to successfully guess their information).

We do not store credit card numbers in coreForce; they are sent straight to the merchant services provider, so to steal a credit card number from coreForce, a hacker would need to (a) break into the backend and introduce a malicious script into a page, which would show up in the change logs; (b) somehow intercept the data in transit between coreForce and the merchant provide, which would be a require extremely high technical skills due to both the encryption involved and the routes between servers, or (c) hack the merchant provider directly.

Here are a few more security features that are built into coreForce for protection:

1. We proactively monitor connections to the site and blacklist the IP address of any connection that matches a known hacking profile.
2. User accounts require email verification before a user can access the back end of the system; accounts are logged off automatically after a certain period of time; accounts are locked after a certain number of failed logins; and accounts that are inactive for more than 90 days are automatically deactivated and must be turned back on by an administrator to be used again.
3. All attempts to run credit card transactions through merchant services are logged, and any IP address that has multiple failed transactions in a short period of time will be automatically banned.
4. We do not install any third party server-side components into our sites.  All the code that runs coreForce is written only by Coreware.

See also the following change log post for changes that were made in August 2020 to further lockdown eCommerce from fraud:

08/17/2020

eCommerce Lockdown...

In an ongoing effort to stop hacking and ecommerce abuse on Coreware, we've added some new features today. Some of you are aware of the attacks that have taken place in the last week, using Coreware client eCommerce and donation pages to test credit cards. This is a difficult problem to solve and the hacking/attacks we've seen in the last week have been unprecedented and ingenious in their design. Some are clearly very intelligent BOTs and some are obviously people working the system. Here are the new things we've added, adding to the long list of checking we already in the system to help stop these types of attacks:

• If a user is logged in and does something to get their IP address blocked, we will also make their user account inactive. One attack we've see in this last week is a person who would create a user account, test credit cards until their IP address got blocked, then simply change their IP address and keep testing.
• A user account can no longer be created if another user account with the same email address exists and is inactive.
• There is now a preference (setup either in Orders->coreFORCE Setup or System->Preferences->Client Preferences) that will require users who create an account to confirm their account before they can use it. If this preference is set on, when the user account is created, it will be set as LOCKED and the user will be emailed with a link to unlock/confirm the account. This will stop random user accounts from being created with non-existent emails.
• We also tightened the parameters we have for locking out an IP address (and making a user inactive) because of credit card failures. Lock out will occur if there are 3 or more failed credit cards in an hour or 5 or more ecommerce failures, of any kind, in 2 hours. There is a small risk that real customers could hit this, but it is unlikely.
• We are now keeping an internal list of names that have been used as the "billing name" on credit cards that caused eCommerce failures. One attack we saw in the last week used the same name and contact information each time, but a different IP address. If a name fails more than 5 times, we simply report a credit card failure without even trying it. This tricks the BOT into thinking the credit card doesn't work.