Securing credit card data

[Jak-S]

Hi,

I am quite experienced with colfdusion e.t.c but not so much with all the
security implications. I am currently redesigning a site for a company who have
online ordering.

Currently they use an SSL certificate on the site and the order information
(which includes credit card information) is e-mailed to them using a Digital ID
(through an ASP page which uses ASP Mail and ASP Encrypt). I am assuing this is
perfectly secure, but personally I dont really like the idea of e-mailing
credit card data, and they have recently had some problems with the site which
causes the page that sends the e-mails to time out and they never receive the
orders.

All the order data (except credit card data) is also stored in a database and
there is a backend part of the site which they can log into to check the orders
(make sure they received all of the e-mails).

What is the best way to store/send the credit card data and what i need to do
on the site and in the database to ensure that no one can get at it.

Its an Access database file stored in a folder on the server that is not
accessible publicly. The backend is simply protected by a username and password
stored in the page that logs you in.

Thanks for any help,

Jack

[s0mus]

Hey Jack, you are right to worry about sending cc info though email; it's just
a bad idea. I don't really understand why you are doing it. Why not just
leave the cc info in the database and send an email that says "check for a new
order"..then have them log into the backend?? that seems best and it's secure
enough if you authenticate by IP and user/pass and page refer. (cgi variables)

I'd move away from Access in the future.

Best - Somus

[Jak-S]

Hi Somus

Thanks for your advice, i understand access isnt idea but it works well for
the client and the hosting package they currently have doesn't give us any
other options.

I just wasnt sure about how secure the data would be, maybe im just paranoid
but if we just password protect the database and add the password to the ODBC
connection and make sure people cant get to the database folder via HTTP, is
that really secure enough, ive always assumed that it was more complicated than
that.

Would you reccomend encrypting the data baefore inserting it into the
database? If so would the built in encrypt() function be good enough?

I just want to make 100% sure i've done it all right, credit card data is
sensitive stuff.

Thanks again,

Jack

[s0mus]

Ok, yes, yes and I think so

I mean "is it good enough" is hard to answer. You can always go a bit further
by using stored procedures in addition to your other precautions and using
folder/file permissions...

[Jak-S]

Ok, thanks for all your help.

Can you reccomend any other good encryption functions/custom tags (perferably
free) that would do a better job? Im guessing you have some experience in this
field, what do you use yourself?

Thanks again, much appreciated.

Jack

[s0mus]

No, I cannot recommend anything. Jack you have to look at your risk level and
make appropriate concessions. You are asking us if the encryption which is
included in MX is sufficient protection... my question is, who is going to be
cracking 56bit encryption and why are they able to access your database?

If your client is a high profile financial institution they should get a
security professional to take responsibility for these matters.

[jamielawjen]

Hi, i dont think that joe public would be very happ to know that their card
details are being kept so loosely! Firstly, securing by ip and cgi vars is a
no no, as they can be spoofed, Secondly, if a good enough hacker wanted to,
then they could get in and get your data, Thirdly, the credit card companies
wouldnt be happy with them storing cc details with no encryption Fourthly, you
should use a pgp style encryption, which encrypts the data going into the
database using a public key, so even if someone does hack the db, they cant
decrypt the data becuase they dpnt have the decrypt 9private) key.. Then you
should have the client download the information, and un encryt with the private
key. You can have different levels of encryption, going up to 2056 bit ( i
think). This way only the client can decrypt the data Fifthly, if you are
operating in the uk (i know tyhis applies here) then you are breaking the law
by storing the persons credit card details on your server, no matter how much
encrytion you have, all cc data has to be stored by a verified financial body,
(check what the situation is by calling the cc comapnies) Do a google for pgp
encyption, and you will find some suppliers, i think there is a custom tag in
the custom tags directory on mm.com Do nto do what you have been advised by
s0mus, though his adice on not using email is sound jamo

[s0mus]

Jamie is a offbase, I never said don't use encryption. In fact I told him to
use his better judgement about his security needs and offered several
suggestions.

Storing cc numbers is not illegal in America and most importnatly the level of
encryption is not the weak point in the system.

RSA's point: 56-bit code isn't strong enough. excerpt
from:[url]http://news.com.com/2100-1023-204556.html?legacy=cnet[/url]

"It took a group of 4,000 teams using tens of thousands of computers linked
over the Internet 210 days to crack the code. The decrypted message read, "It
is time to move to a longer key length."

I stand by the point that if you really think 56bit is not strong enough then
you should get a security professional.

[Jak-S]

Hmmm ok.

Firstly, the company i am doing this for is a small shop which currently only
does about 2 or 3 orders online a day, so maybe not a huge risk, im not sure?

Also, although the company is in the UK, the web server is in america, would
that make a diference, i guess not.

I am currently trying to get my client to go with a seperate company for
processing their payments (like Wordpay or similar), however they really arnt
that sure at the moment and i really need to come up with a solution to storing
the CC data asap.

Thanks again for all your help both of you, it really is appreciated.

Jack

[jamielawjen]

hi there, if the company trades in the uik, then they are not allowed to
recieve cards and then put ti through their in store machne in this manner, it
is illegal, and a requirement by the card comapnies that the transaction goes
through a regsitered institution, regardless of where the server is in the uk
or usa, if you are in doubt, call the clients bank, if they are doing this, and
the card company finds out, they can be prosecuted, as well as all fraud
insurance being declared null and void. Your client will have a card machine,
which is under contract to recieve cc trabsactions from face to face
transactions, (this usually incldes over the phone aswell which is wierd) but
all electronic must be done through a third party. Firstly your client will
need a merchant bank account, from lloyds, hsbc, barcleys, and with some you
will also need a secure payment gateway such as secure trading, and you will be
loking at around 500 pounds, because they are money grabbign swines!. The
cheaper alternative is to go with worldpay, or paypal, paypal being the
cheapest at only 2.9 % (worldpay around 5%). Paypal also has a very easy to use
API allowing yout o integrate your stores checkout with the paypal payment
gateway. You will also need to worry about no cc details, as paypal stores them
all for you. let me know if you have any other questions, it is a very sticky
area in the uk, and you must be very careful to do it properly or your client
will be knocking on your door! cheers jamie

[Jak-S]

Hi jamie,

Cheers for the info, i wasnt aware of that at all, i will let my client know
ASAP. I have already sent them another e-mail trying to convince them to change
to a third party payment processing company.

Thanks again,

Jack

[Steve Sommers]

Forgive me if this has already been suggested as I did not read the entire
thread, just the first few messages. My suggestion would be to not store the CC
data on the server because of various reasons mostly related to security and
instead use an online credit card gateway. It is their business to keep the
data secure and if you are using a shared server, it will be impossible for you
to truely secure the data. Good luck.,

[jorgepino]

I agree with Steve,
You should not keep cc number in the server or email it
I think better to get it authorized and only keep the authorization number
you don't need to keep that kind of info

[Mike Greider]

Yes. Please, use a third party solution to handle credit card information
correctly if you do not have the time or expertise to secure this information.
56 bit encryption is not sufficient anymore. If you just store information in
an access database with a username/password than you must do your homework
about the ability to crack access databases. On top of that, your
username/password must be kept somewhere in order for you to access the
database right? In a config file perhaps? Well if someone can gain physical
access to your database, it's trivial to gather that config file as well. The
best solution would be to go with a third party solution that specializes in
handling this information. Short of that, use pgp or any validated software
that will let you use your public key to highly encrypt the information. Long
story short ... don't assume this risk unless you are well prepared. If you are
asking these questions, you are not prepared. Go with another third party
solution that does this for a living.

[rhellewell]

You should be aware that VISA and MC have specific requirements about how to
process and store CC info. They are getting much stricter on this. Start here:


[url]http://www.usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html?it[/url]
=l2|/business/accepting_visa/ops_risk_management/index%2Ehtml|Cardholder%20Infor
mation%20Security%20Program

...Rick....

[MattRobertson]

Rick's link is an important one to look over. As I understand it an
industry-wide initiative will go into effect in the U.S. that mandates either
these exact regs or a similar set. You either comply or get your card
processing privileges yanked.

I expect it will pretty much torpedo the use of credit-card capture, no matter
how securely its done (I use 1024-bit RSA public/private key, personally). The
compliance audit costs alone are ridiculous for a single small vendor.

--Matt--
MSB Web Systems... [url]http://mysecretbase.com[/url]
"Any time you have influence, try ordering around someone else's dog."
- The Cockle Bur