Credit Card Security
Moderator: General Moderators
- tecktalkcm0391
- DevNet Resident
- Posts: 1030
- Joined: Fri May 26, 2006 9:25 am
- Location: Florida
Credit Card Security
What type of "security" would be best for storing credit card information?
- MrPotatoes
- Forum Regular
- Posts: 617
- Joined: Wed May 24, 2006 6:42 am
- dull1554
- Forum Regular
- Posts: 680
- Joined: Sat Nov 22, 2003 11:26 am
- Location: 42:21:35.359N, 76:02:20.688W
if u store your credit card information... anywhere.... any sensible minded person will never use your service.
larger companies have the ability to store this information because of the precautions, hardware, and overall management that they employ. any individual or small busisness should simply state that any return customers will have to re provide their information due to security reasons.
larger companies have the ability to store this information because of the precautions, hardware, and overall management that they employ. any individual or small busisness should simply state that any return customers will have to re provide their information due to security reasons.
- tecktalkcm0391
- DevNet Resident
- Posts: 1030
- Joined: Fri May 26, 2006 9:25 am
- Location: Florida
-
jamiel
- Forum Contributor
- Posts: 276
- Joined: Wed Feb 22, 2006 5:17 am
- Location: London, United Kingdom
There are alot of extra's involved in storing the card details. You will need a lawyer to check that your Terms and Conditions are in order, you will want a renowed Hosting company looking after your server in a locked up cage, and you will want to make sure someone other than you (eg. your boss) will take the fall if things go pear shaped.
For the sake of open discussion, alot of companies choose to PGP the card details.
Unless your companies paper work is in order, don't take on the responsibility of storing card details.
For the sake of open discussion, alot of companies choose to PGP the card details.
Unless your companies paper work is in order, don't take on the responsibility of storing card details.
As an academic exercise, lets consider the risks.
First, there is the risk of compromise in transit. To properly protect against that possibility, we need to use SSL on our site, which will encrypt the data in transit.
Next, there is the risk of compromise locally (on the server). To properly protect against that possibility, we need to encrypt the data. Since we need to pull it back up for reprocessing in the future, it will have to be a method that allows decryption.
Since we are allowing decryption from the server in realtime, we have to assume an attacker that compromises the box can do so as well. As such, we need to reduce the likelihood of the server being compromised. That means external audits of our security, a dedicated server, physically secured, tight access controls (including account limitations - no logging in as root/Administrator), and more.
Even then, if the system is compromised, the data is still at risk, so I need insurance that covers loss of customer data. The loss of customer data in some jurisdictions is covered by extremely specific legislation that in some cases requires customer notification within 48 hours of breach - so I will probably need a lawyer to clarify my responsibilities.
To be able to get insurance, I have to do business as a company, which means a business license, taxes, possibly an accountant, and more.
All of this leads me to the simple conclusion that its not worth all of THAT to allow customers to not have to type in their CC info each time they purchase.
Better, I could use PayPal, or Google Purchase to allow them to still do so, without any additional risk for me.
First, there is the risk of compromise in transit. To properly protect against that possibility, we need to use SSL on our site, which will encrypt the data in transit.
Next, there is the risk of compromise locally (on the server). To properly protect against that possibility, we need to encrypt the data. Since we need to pull it back up for reprocessing in the future, it will have to be a method that allows decryption.
Since we are allowing decryption from the server in realtime, we have to assume an attacker that compromises the box can do so as well. As such, we need to reduce the likelihood of the server being compromised. That means external audits of our security, a dedicated server, physically secured, tight access controls (including account limitations - no logging in as root/Administrator), and more.
Even then, if the system is compromised, the data is still at risk, so I need insurance that covers loss of customer data. The loss of customer data in some jurisdictions is covered by extremely specific legislation that in some cases requires customer notification within 48 hours of breach - so I will probably need a lawyer to clarify my responsibilities.
To be able to get insurance, I have to do business as a company, which means a business license, taxes, possibly an accountant, and more.
All of this leads me to the simple conclusion that its not worth all of THAT to allow customers to not have to type in their CC info each time they purchase.
Better, I could use PayPal, or Google Purchase to allow them to still do so, without any additional risk for me.
I strongly suggest using PayPal. If they have a CC they can use it, it's just alot safer and easier for everyone involved. Most small 'home built' sites like I expect yours is use Paypal.tecktalkcm0391 wrote:So pretty much just ask them for it everytime I need to charge them? See I am doing something were you have to pay for a post on my website, and I was just thinking about keeping there CCN then just billing it when the submit the form.
- tecktalkcm0391
- DevNet Resident
- Posts: 1030
- Joined: Fri May 26, 2006 9:25 am
- Location: Florida
I've been down this road so many times with people and the logistics, resources and capital required to build a system for storing credit card details PROPERLY, is just huge.
The way i've got round it is to use a company called Secpay (http://www.secpay.co.uk) probably only suitable if you're in the UK.
They offer an API to their payment processing systems so as long as you have an SSL cert you can transparently process payments.
The feature that seperates Secpay from some of the other providers is that they allow you to process repeat payments against a card you've previously used. All you need to do is provide a previous transaction reference, therefore completely bypassing the need to store the actual card number.
The way i've got round it is to use a company called Secpay (http://www.secpay.co.uk) probably only suitable if you're in the UK.
They offer an API to their payment processing systems so as long as you have an SSL cert you can transparently process payments.
The feature that seperates Secpay from some of the other providers is that they allow you to process repeat payments against a card you've previously used. All you need to do is provide a previous transaction reference, therefore completely bypassing the need to store the actual card number.
I always store the last 4 digits, for order archiving. For example, you could look at an order and see that it was paid with a Visa with last 4 digits 4011, expiration 01/07.
If you want customer's information remembered, you can save everything else (name, address, phone, etc). I don't think most customers will mind having to re-enter their credit card number every time they checkout.
If you want customer's information remembered, you can save everything else (name, address, phone, etc). I don't think most customers will mind having to re-enter their credit card number every time they checkout.
Easy solution if users are to be constantly purchasing stuff. Give them an online credit amount. So just like your current system would be how if they don't have credits in their account they are sent to a page to buy credits. Have an option for them to buy extra credits. That way they can order as much as they need and you can put the money earnt into a high interest savings account. Have the PHP script keep track of how much money you can take out and keep the unspent credit money in the savings account incase the user wants a refund.tecktalkcm0391 wrote:OK, well I was almost always going to use Paypal. I was just going to store the information paypal needed to complete the transaction, but I guess they will just have to enter it everytime.
Really I just need to see a lawyer about the credit card storage if I was to store them.
That way you earn the interest of their money while its sitting in your system. Get a few hundred users on that and your doing good.