[Zope] Re: [ZCommerce] Secure storage of credit card info
+[ Curtis Maloney ]- | On Fri, 30 Jun 2000, Andrew Kenneth Milton wrote: | > Just to make those people who think "It will never happen to me" think | > twice, the Australian Government Treasury site was hacked and lots of | > banking details about lots of small businesses was released. | > | > The Australian Treasury was very happy with their security too. Until | > yesterday. | | Whilst I agree that "It will never happen to me" is a stupid stance, the ATO | web site was not 'hacked'. As an example, the Federal Police and the | government are NOT doing anything to the person. Last night I heard they were still looking for him. Of course ringing JJJ first wasn't exactly a smart idea. | What happened was somebody noticed that a number in the URL for a page of | their details matched their ID number, and tried some others. Upon finding | they worked, he wrote a script to try numbers, munge the page, and e-mail | people their details. And the site is down 'indefinitely'. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [ZCommerce] Secure storage of credit card info
On Fri, 30 Jun 2000, Andrew Kenneth Milton wrote: > Just to make those people who think "It will never happen to me" think > twice, the Australian Government Treasury site was hacked and lots of > banking details about lots of small businesses was released. > > The Australian Treasury was very happy with their security too. Until > yesterday. Whilst I agree that "It will never happen to me" is a stupid stance, the ATO web site was not 'hacked'. As an example, the Federal Police and the government are NOT doing anything to the person. What happened was somebody noticed that a number in the URL for a page of their details matched their ID number, and tried some others. Upon finding they worked, he wrote a script to try numbers, munge the page, and e-mail people their details. This showed a serious flaw in the design of the site, but it was not 'hacked'. Perhaps the lesson to learn here is: Crackers are NOT the only people you need to protect yourself from. Have a better one, Curtis Maloney. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [ZCommerce] Secure storage of credit card info
On Sat, Jun 10, 2000 at 07:58:48AM +1300, Graham Chiu wrote: > >http://www.post1.com/home/ngps/zope/zsmime > > Any ETA on the Win32 binaries? Real Soon Now! ;-) Seriously, I've just compiled M2Crypto with Borland's BC++ 5.5 free compiler suite and linked with MSVC-built Python and OpenSSL. It works! I'm preparing a binary package of my latest snapshot. It should be up on my site tomorrow this time. I expect further progress on M2Crypto to be slow in the next few weeks, this being Euro 2000 month. ;-) Germany vs Romania just started, gotta go! Cheers. -- Ng Pheng Siong <[EMAIL PROTECTED]> * http://www.post1.com/home/ngps ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [ZCommerce] Secure storage of credit card info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In article <[EMAIL PROTECTED]>, Ng Pheng Siong <[EMAIL PROTECTED]> writes >Take a look at ZSmime, > >http://www.post1.com/home/ngps/zope/zsmime > Hi, Any ETA on the Win32 binaries? - -- Regards, Graham Chiu gchiucompkarori.co.nz http://www.compkarori.co.nz/index.php Powered by Interbase and Zope -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBOUCjubTRdIWzaLpMEQKpMACgnwmcR4sNmRpNk0g4Nm6RLq9O6lsAoIi3 PMOYM6R69bu0DbW8IBgScTwE =1D+1 -END PGP SIGNATURE- ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] RE: [ZCommerce] Secure storage of credit card info
Hi there, I know your post indicates you've thought about this, but you may want to reconsider storing CC info at all. It's a trade off on convenience for the customer and security precautions on your site. If you don't have the numbers, that's one less thing an intruder could do with your information when they do break in. If you do store CC info, you should probably offer the option to not store the CC#. I know I don't like my CC info in a merchant database, encrypted or not. Scott -Original Message- From: R. David Murray [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 08, 2000 5:57 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [ZCommerce] Secure storage of credit card info OK, any of you out there who have thought about ecommerce, cryptography, and zope, I've got a design question for you. Actually, this question is independent of zope, but I need to solve it in a zope context. You have a ZCommerce site. You accept credit cards, and securely communicate with a CC processor to verify the transacton. Now, you want to save the CC# and other info in case something needs to be done with it later, and probably store the CC# so this customer doesn't have to type it in again later. Regardless of whether you are storing this info in a relational database or in the ZODB, how do you secure that information? Ideally I'd like it to be encrypted on disk. Now, storing it in a database probably makes it pretty hard to grep out even if a hacker manages to snarf the database file, but I'd like to encrypt it. But if I encrypt it, I have to have a decryption key somewhere. Where do I store the decryption key so that the cracker who snarfs the database file can't get it (just in memory somewhere?), and yet have the system be able to boot itself, including having the key, without human intervention? It seems to me like this is a Hard Problem, but I'm not up on the current cyrptography practice. So if there is a well known general solution, I'd love to hear about it. Otherwise, does anyone know what current Best Practice is? --RDM ___ ZCommerce Mailing List - [EMAIL PROTECTED] http://lists.codeit.com/mailman/listinfo/zcommerce ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [ZCommerce] Secure storage of credit card info
On Thu, Jun 08, 2000 at 08:57:17PM -0400, R. David Murray wrote: > You have a ZCommerce site. You accept credit cards, and securely > communicate with a CC processor to verify the transacton. Now, > you want to save the CC# and other info in case something needs > to be done with it later Hi, Take a look at ZSmime, http://www.post1.com/home/ngps/zope/zsmime Here's the blurb: ZSmime enables Zope to generate S/MIME-signed/encrypted messages. ZSmime is useful where Zope accepts confidential information over the web, e.g., credit card numbers, Swiss bank account instructions, etc. Such information can be protected by ZSmime and relayed off-site immediately. This reduces the value of the information carried on-site and in turn reduces the impact of a successful attack against the site. Even if the S/MIME-protected information remains on-site, it is now encrypted - this introduces additional cost in defeating the protection and may mitigate the effect of a successful site penetration. ZSmime adds a DTML tag "dtml-smime" to Zope. -- Ng Pheng Siong <[EMAIL PROTECTED]> * http://www.post1.com/home/ngps ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [ZCommerce] Secure storage of credit card info
> "RDM" == R David Murray <[EMAIL PROTECTED]> writes: RDM> On Thu, 8 Jun 2000, Bill Anderson wrote: >> Personally, I would store the actual data on a seperate server, >> not accessible to the public. RDM> Mmm. Yes, that makes it more secure. Still leaves the RDM> question of encryption/decryption of the data and key RDM> management, but it makes the cracking a lot less likely. And RDM> Steve's EMarket product is designed for that scenario. RDM> I'd like to also have a one-box solution, though. Based on RDM> some comments by one of the eTailor folks I'm now trying to RDM> see if I can structure the user/merchant interface so that RDM> the server doesn't need to decrypt the stuff without human RDM> intervention. When I was originally setting up EMarket I wanted to do a 'two-box' solution, but I only had one box handy at the moment. I set up a second Zope instance on the same box to handle transactions (behind apache-ssl) and it worked pretty well for testing. Of course if you have only one box for production, you could use the same setup. So there's no reason to make a solution 'one box' or 'two box', but it could be 'one box.. two Zopes!'. ;-) -steve RDM> --RDM RDM> ___ ZCommerce RDM> Mailing List - [EMAIL PROTECTED] RDM> http://lists.codeit.com/mailman/listinfo/zcommerce ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [ZCommerce] Secure storage of credit card info
> -> > You have a ZCommerce site. You accept credit cards, and securely > -> > communicate with a CC processor to verify the transacton. Now, > > Besides Bill's suggestion, keep all your servers behind a good > firewall. One option is to use Linux IP Masquerading, having your > webserver *and* database server use 192.168.0.??? IP Addresses. Then, > turn on port forwarding on your Masq server, so that all incoming requests > on port 80 go to (something like) port 8080 on your webserver, which then > responds to the request. > > You could just use an encrypted filesystem on the database server, > although that may be too slow (and possibly overkill?). At that point > --assuming your firewall is secured-- you'd more or less need physical > access to your internal network to see those CC#s. The only real danger > left is a misconfiguration (or bad code) in your webserver software. > (read: don't use IIS :) > I would work from the assumption that, worst case, your web server machines may get rooted, either from external attacks or from internal "human engineering". And that people can modify your software and install sniffers. [1] Especially if you have a lot of people modifying content on that machine. That's why you get the best protection with a separate machine, firewalled off, with limited access, plus Public key encryption. If you get rooted and you don't know about, you've lost the game. If you get rooted and you find out, you've only lost those CC numbers that were processed while you were compromised. My 2 cents. I'd be interested to hear alternate viewpoints. -- cary (who worries alot) [1] Which is why switches (rather than dumb hubs) are nice. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [ZCommerce] Secure storage of credit card info
-> I'd like to also have a one-box solution, though. Ooh, that's bad JuJu. Keeping CC#s on the same box as your webserver? a) Pray there are no overflows/misconfigurations/etc. on the webserver daemon. b) Turn off EVERY other service on that box (even ssh has had a buffer overflow). This means no remote system management (i.e. buy another keyboard and monitor). c) [After the Fact]: Wonder why you didn't choose to spend another mere $1200 for a separate (Linux Oracle) server In short, if you're worried enough to encrypt the database files on disk, you're worried enough to have a separate database server. --Derek ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [ZCommerce] Secure storage of credit card info
-> > You have a ZCommerce site. You accept credit cards, and securely -> > communicate with a CC processor to verify the transacton. Now, Besides Bill's suggestion, keep all your servers behind a good firewall. One option is to use Linux IP Masquerading, having your webserver *and* database server use 192.168.0.??? IP Addresses. Then, turn on port forwarding on your Masq server, so that all incoming requests on port 80 go to (something like) port 8080 on your webserver, which then responds to the request. You could just use an encrypted filesystem on the database server, although that may be too slow (and possibly overkill?). At that point --assuming your firewall is secured-- you'd more or less need physical access to your internal network to see those CC#s. The only real danger left is a misconfiguration (or bad code) in your webserver software. (read: don't use IIS :) --Derek ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: [ZCommerce] Secure storage of credit card info
On Thu, 8 Jun 2000, Bill Anderson wrote: > Personally, I would store the actual data on a seperate server, not > accessible to the public. Mmm. Yes, that makes it more secure. Still leaves the question of encryption/decryption of the data and key management, but it makes the cracking a lot less likely. And Steve's EMarket product is designed for that scenario. I'd like to also have a one-box solution, though. Based on some comments by one of the eTailor folks I'm now trying to see if I can structure the user/merchant interface so that the server doesn't need to decrypt the stuff without human intervention. --RDM ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: [ZCommerce] Secure storage of credit card info
"R. David Murray" wrote: > > OK, any of you out there who have thought about ecommerce, cryptography, > and zope, I've got a design question for you. Actually, this question > is independent of zope, but I need to solve it in a zope context. > > You have a ZCommerce site. You accept credit cards, and securely > communicate with a CC processor to verify the transacton. Now, > you want to save the CC# and other info in case something needs > to be done with it later, and probably store the CC# so this > customer doesn't have to type it in again later. Regardless > of whether you are storing this info in a relational database > or in the ZODB, how do you secure that information? Step one, prepare for a fight with Amazon <0.5 wink> Personally, I would store the actual data on a seperate server, not accessible to the public. When you need to place the order/verify funds/etc, your ZopeApp talks to the private server, which returns either the data needed, or a yes or no result. I prefer the latter, since the actual processing with the CC clearinghouse can be done from there, thus largeley eliminating the threat (though not destroying it entirely of couse) at the webserver. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
