I thought I would chime in here. Many are probably not aware of the new security regulations by Visa and Mastercard that are now in effect. Basically, anyone who stores or handles credit card data has to comply. If you use an online processing company such as Verisign they take care of most of it for you (you still have to have a third party do a security scan once a year on your servers), but if you handle or store the cards yourself, be prepared for some hefty fines if you get hacked or found out and have not gone through the certificate procedures.
Among the requirements, all card data must be encrypted and stored on a server that is not directly connected to the internet (NAT/PAT is acceptable but there cannot be any direct routes from the internet to the storage server), you have to employ a good firewall such as a screened subnet in conjunction with NAT/PAT, you have to use two factor authentication for all remote access, you have to have documented security policies, code reviews, etc etc.. And on top of all that you have to pay an approved third party to audit all of the above which isn't cheap. Visa/Mastercard are leaving it up to the discretion of the merchant banks as to forcing compliance. Most smaller merchant's won't be forced to go through all of this, but the stickler is that if you are hacked, all the requirements and fines still apply. Chris ----- Original Message ----- From: "mock" <[EMAIL PROTECTED]> To: "Geoffrey Young" <[EMAIL PROTECTED]> Cc: "Modperl List" <[EMAIL PROTECTED]> Sent: Tuesday, August 10, 2004 11:58 PM Subject: Re: APR::Base64 uses > On Tue, Aug 10, 2004 at 08:57:14PM -0400, Geoffrey Young wrote: > > > > >>but hiding the decryption key from technical people is generally > > >>impossible > > > > > > > > > Only if they crack your application server. Cracking the database or > > > sniffing packets would not be good enough, assuming traffic to your > > > credit card company is over SSL. > > > > oh, sure. > > > > I guess I had a different mindset with all of that - internal employees. > > for most big companies I would assume that accessing the underlying Oracle > > financials database (or some other "enterprise" solution) with _all_ the > > credit card numbers would be sufficiently difficult for outside hackers. > > I'd be much more worried about the disgruntled employee causing trouble. > > > > but you're right - crackers are a legitimate concern for this kind of thing, > > and I wasn't aware of the role that verisign is now playing (which I guess > > is the cost of having worked someplace where we built everything from > > scratch). so, thanks for the knowledge :) > > > > --Geoff > > > > -- > > Report problems: http://perl.apache.org/bugs/ > > Mail list info: http://perl.apache.org/maillist/modperl.html > > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > > > This is about to go out to CPAN, but since it seems there is some question > as to how to do this, I'll send it out a little early. Attached is a module > for safely encrypting and storing credit cards using the Business::OnlinePayment > interface. It uses a public RSA key and Crypt::OpenSSL::RSA to encrypt a > randomly generated Blowfish symetric key, which is used with Crypt::CBC to > encrypt the creditcard details. Also included is a module for reversing the > transaction given the RSA private key. This allows one to store creditcards > safely on the server, by not putting the private RSA key on the same machine. > To retrieve the cards, simply pull the data to an offline machine, and > decrypt using the RSA private key. Assuming you aren't an idiot and leave > the private key somewhere internet accessible, this should be as proof against > hackers as any other credit card processing. > > enjoy > > mock > ---------------------------------------------------------------------------- ---- > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
