coreFORCE Website: Security Measures
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 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, key logger 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:
We proactively monitor connections to the site and blacklist the IP address of any connection that matches a known hacking profile.
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.
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.
We do not install any third party server-side components into our sites. All the code that runs coreForce is written only by Coreware.
Additional Security Meausres
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.
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.
An internal list of names that have been used as the "billing name" on credit cards that caused eCommerce failures is now maintained. 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.
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:
We proactively monitor connections to the site and blacklist the IP address of any connection that matches a known hacking profile.
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.
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.
We do not install any third party server-side components into our sites. All the code that runs coreForce is written only by Coreware.
Additional Security Meausres
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.
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.
An internal list of names that have been used as the "billing name" on credit cards that caused eCommerce failures is now maintained. 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.
Updated on: 08/03/2024
Thank you!