security when processing credit cards

[esthera]

Here's what I plan on doing. Please let me know if this is secure.

On a site with a secure layer I will be getting a credit card number. Then in asp I will encode the number and put the encoded number in a acess database. The administrater will be able to go in a passworded page and retrieve the credit card number (Which will be decoded in the process) to manually bill.
Is this secure?

[Ribeyed]

hi,
which country are you in? The reason i ask is because in the UK there is the Data Protection Act. This is very stricked in the way you store credit card numbers on your own system. Do be honest what you have described so far doesn't convince me that the credit card numbers will be secure enough. The facted that only admin can view them by providing a password which will possible also be stored in the database doesn't make the system every secure. You haven't mentioned anything about the security on teh system/network where you are going to store the credit card numbers.
To be honest i have research this as i develop ecommece sites proffessionally and i would suggest you ditch the manual storing of credit card numbers and opt for a third party company such as WorldPay to process your transactions real time.

[esthera]

they will be processed in the us. I will protect the page with a password from the db which I guess I should also encrypt and decrpyt.

Esther

[rdoekes]

Just to emphasize RibEyed's point: From a security standpoint, have you thought about the location of the database? Since you are using access, it is important where you store the database. Not in the same directory as your code, for instance.

Even if you protect the admin page with a password, this page also needs to be SSL'ed, to reduce the change of a package sniffer getting hold of the admin's password. Just basic NT authentication will not be enough.

[Ribeyed]

Hi,
access storing credit card numbers !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

No, no, no, no.

Access is not secure enough. You can remove the admin account from access and the guest account but even at this you can still get into access databases no matter how secure you can make them, its a design flaw in Access.

You are putting peoples credit card numbers at risk storing them in Access. Access for storing credit card numbers is a big mistake.

[rdoekes]

Let's take this a step further. Even een 'real' database like SQL server, or equivalent is a secure as the weakest link (no pun intended) in the chain: How many examples have you seen where sa without a password is mentioned in the connectionstring? A cracker worth his salt will download that database's content in no time.

But I agree that access for this type of sensitive information won't do. At least with SQL Server (or eq.) you have a lot of options authenticating access to the database.

Brings us back to RibEyed first recommendation: why re-invent the wheel when there are very secure third-party suppliers for this?

Also, Manually bill afterwards when you, in the same token, can create an invoice on the fly and email that to the customer, while the third-party takes care of the billing and collection of the invoice.

You do not have to store the cc numbers while you can focus your efforts on business.

Just my two cents...

-Rogier Doekes

[esthera]

Thanks for your resposes. I talked to my client and explained some of the above hesitations. They wanted to avoid a third party credit card company to avoid costs. They already have a credit card machine.

Are there any other options.

[rdoekes]

And what are the cost in lost revenues if it turns out that the database with all the credit card info is hijacked?
Remember, in e-commerce, if you lose a customer, he ain't coming back.

[Ribeyed]

Hi,
adding to rdoekes comments about someone hijacking the credit card numbers over the internet, but what about a not so trust worthy employee using them for their own gain? This type of thing happens all the time.
Lets look at not real time transactions, a user places an order and receives a thank for your order page, is your client willing to call the customer to tell them their credit card has been refused? What happens if that customer was requiring the goods for the next day but the staff don't process the credit card to a few hours after which then misses the posting dead line and the result is the customer recieves the goods to late. There are a lot of issues regarding the speed of the overall transaction when the credit card payment is not real time.
My argument against your client for saving costs i would say manual credit card processing will cost you more to set up that using a third party company to process real time. In the UK WorldPay is around £195 per year. One of my clients pays their bank a further one of fee of £195 to debt the transaction in my clients account within 3 days. A further £20 per month and my client has taken insurance to cover and fraud. So total running costs per year is around £415 per year.
Manually you would first have to cost of hosting your own server, on a leased line. Cost of building or buying your server, server software, hardware firewall, sql server and any further software required for a server. You are going to need yyour SSL certificate around £300 per year. Your going to need someone to maintain your in house server. Plus the extra cost for you to develop a manual transaction ecommerce site. Can't even estimate the running cost for manual credit card processing.