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
"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.
-> > 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
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
-> 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
I am trying to motivate the use of Zope / Zcommerce, and to do this need some timing ideas - Does anyone have thoughts on how long (man hours per expertise) it took them to go from no Zope to (Zope + Steve Spickelmire and Co's EMarket) and to a successful transaction? Hopefully this will be of general interest for anyone doing a business case or planning, so if you have any thoughts on "we expected x by experienced y" it should make interesting reading. Regards Dirk
At 8:32 AM +0200 6/13/2000, D Swart wrote:
I am trying to motivate the use of Zope / Zcommerce, and to do this need some timing ideas - Does anyone have thoughts on how long (man hours per expertise) it took them to go from no Zope to (Zope + Steve Spickelmire and Co's EMarket) and to a successful transaction?
From 0 to Zope in under 6.2 seconds! :) If you are totally new (no Zope in your blood) here is what I would expect. This does take into account that you know "something" about programming and variables and really good HTML as well as some server stuff (how to set up, IP addresses, shell scripts). I have put what it would take a Zopista in parenthesis (not me though, I only play one on the web). 1 day (1 hour) - Install Zope 1 day (done) - Download, print, read all guides and "howtos" 5 Days (2 days) - To get a basic site up and running. Log in, look and feel, tested, management, feel the power of Zope 1 day (2 hours) - Set up database backend and connect 5 days (2 days) - Build catalog system, Z SQL Methods, etc 2 days (2 days) - testing, testing, testing This is very rough but should be around the amount of time. This does mean full "developing days" which are about 10-14 hours. I don't know about transactions so you might want to pad it a bit. I will say though, that once you get into developing with Zope you realize just how fast you can develop new products with it. It is an amazing working environment. J
+----[ J. Atwood ]--------------------------------------------- | | This is very rough but should be around the amount of time. This does | mean full "developing days" which are about 10-14 hours. I don't know Remind me to get paid by the hour if I ever do any work for you :-) -- 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 |akm@theinternet.com.au|
I think that the timeline J provided is unrealistically optimistic. The amount of time it will take someone to go from 0 to Zope varies wildly. We have had developers come in and in a matter of a few days they are very productive. Others take much longer. Several things affect this. Someone to show you the ropes being primary. Previous knowledge, especially in OOP and in python or pythonish language, is also crucial. So how long depends on you. If you don't have someone who knows Zope and python expect to struggle up the near vertical learning curve of Zope. After helping to train several people on Zope I would recommend not reading any Zope documentation until after you understand python. In other words, learn the basics of python first. Know what a list, dictionary and tuple are and their syntax and operations and many of the mysteries of Zope will be cleared up (i.e. when do you need tics instead of quotes etc.). After garnishing a working knowledge (you don't need to be a Zen master of python) of python ,then read the Zope documentation and start working in Zope. Just my experience working with newbies..... Dan "J. Atwood" wrote:
At 8:32 AM +0200 6/13/2000, D Swart wrote:
I am trying to motivate the use of Zope / Zcommerce, and to do this need some timing ideas - Does anyone have thoughts on how long (man hours per expertise) it took them to go from no Zope to (Zope + Steve Spickelmire and Co's EMarket) and to a successful transaction?
From 0 to Zope in under 6.2 seconds! :)
If you are totally new (no Zope in your blood) here is what I would expect. This does take into account that you know "something" about programming and variables and really good HTML as well as some server stuff (how to set up, IP addresses, shell scripts). I have put what it would take a Zopista in parenthesis (not me though, I only play one on the web).
1 day (1 hour) - Install Zope 1 day (done) - Download, print, read all guides and "howtos" 5 Days (2 days) - To get a basic site up and running. Log in, look and feel, tested, management, feel the power of Zope 1 day (2 hours) - Set up database backend and connect 5 days (2 days) - Build catalog system, Z SQL Methods, etc 2 days (2 days) - testing, testing, testing
This is very rough but should be around the amount of time. This does mean full "developing days" which are about 10-14 hours. I don't know about transactions so you might want to pad it a bit. I will say though, that once you get into developing with Zope you realize just how fast you can develop new products with it. It is an amazing working environment.
J
_______________________________________________ Zope maillist - Zope@zope.org 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 )
Well, if you added it all up I was talking about 96 hours of development (8 days x 12 hours) which is a lot to bring up a site in Zope. I agree it does depend on the person but I have had graphics people once given a 10 minute intro to Zope not only start playing around with DTML but doing quick if/then statements. OO helps, and Python can help but some of things are not exactly the same as Python and TOO much Python can hurt. I wise man once said.. "There are only three timelines for programmers: 1) Something that can be done in 20 minutes 2) Something that can be done in a day 3) Something that can be done in a year" J
From: Dan Rusch <drusch@globalcrossing.com> Date: Tue, 13 Jun 2000 10:36:16 -0500 To: "J. Atwood" <jatwood@bwanazulia.com> Cc: D Swart <dirk@vis.co.za>, zcommerce@codeit.com, zope@zope.org Subject: Re: [Zope] Costs of implementation
I think that the timeline J provided is unrealistically optimistic. The amount of time it will take someone to go from 0 to Zope varies wildly. We have had developers come in and in a matter of a few days they are very productive. Others take much longer. Several things affect this. Someone to show you the ropes being primary. Previous knowledge, especially in OOP and in python or pythonish language, is also crucial.
So how long depends on you. If you don't have someone who knows Zope and python expect to struggle up the near vertical learning curve of Zope. After helping to train several people on Zope I would recommend not reading any Zope documentation until after you understand python. In other words, learn the basics of python first. Know what a list, dictionary and tuple are and their syntax and operations and many of the mysteries of Zope will be cleared up (i.e. when do you need tics instead of quotes etc.). After garnishing a working knowledge (you don't need to be a Zen master of python) of python ,then read the Zope documentation and start working in Zope.
Just my experience working with newbies.....
Dan
"J. Atwood" wrote:
At 8:32 AM +0200 6/13/2000, D Swart wrote:
I am trying to motivate the use of Zope / Zcommerce, and to do this need some timing ideas - Does anyone have thoughts on how long (man hours per expertise) it took them to go from no Zope to (Zope + Steve Spickelmire and Co's EMarket) and to a successful transaction?
From 0 to Zope in under 6.2 seconds! :)
If you are totally new (no Zope in your blood) here is what I would expect. This does take into account that you know "something" about programming and variables and really good HTML as well as some server stuff (how to set up, IP addresses, shell scripts). I have put what it would take a Zopista in parenthesis (not me though, I only play one on the web).
1 day (1 hour) - Install Zope 1 day (done) - Download, print, read all guides and "howtos" 5 Days (2 days) - To get a basic site up and running. Log in, look and feel, tested, management, feel the power of Zope 1 day (2 hours) - Set up database backend and connect 5 days (2 days) - Build catalog system, Z SQL Methods, etc 2 days (2 days) - testing, testing, testing
This is very rough but should be around the amount of time. This does mean full "developing days" which are about 10-14 hours. I don't know about transactions so you might want to pad it a bit. I will say though, that once you get into developing with Zope you realize just how fast you can develop new products with it. It is an amazing working environment.
J
_______________________________________________ Zope maillist - Zope@zope.org 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 )
Well, I'd say that much of it relies on the kind of project you're doing, too. Sure, if all your DTML is doing is simple if/then statements, maybe a loop or two, it'll only take a few minutes to get used to the management interface itself. However, if you've got some seriously complicated things going on, it will be a lot more difficult. We've got an application framework being developed that relies very heavily on some extraordinarily tricky acquisition to get pages to render correctly. Everything is determined by the path you take to actually get to the page you want to look at, so a difference of one directory being present in the acquisition path can *drastically* alter how a page is displayed and functions (just adding the "admin" folder, for instance). Everything's automatically rendered. You basically never have to touch HTML again, because there's all these Widgets all over the place doing everything for you. Expecting someone to just jump into that kind of thing after becoming comfortable with the management interface would be insane. (Once you're into the Zen of the thing, though, it's wonderful!) If you're just putting together some relatively simple webapps, your timeline's probably all right. However, if you want a fully-functional ZCommerce site up, running, *secure,* and easily expandable, I'd say there's a lot more you've got to get through. :) Just my opinion, though. Perhaps I'm just slow. :) Happy Zoping! -CJ "J. Atwood" wrote:
Well, if you added it all up I was talking about 96 hours of development (8 days x 12 hours) which is a lot to bring up a site in Zope. I agree it does depend on the person but I have had graphics people once given a 10 minute intro to Zope not only start playing around with DTML but doing quick if/then statements. OO helps, and Python can help but some of things are not exactly the same as Python and TOO much Python can hurt.
I wise man once said..
"There are only three timelines for programmers:
1) Something that can be done in 20 minutes 2) Something that can be done in a day 3) Something that can be done in a year"
J
From: Dan Rusch <drusch@globalcrossing.com> Date: Tue, 13 Jun 2000 10:36:16 -0500 To: "J. Atwood" <jatwood@bwanazulia.com> Cc: D Swart <dirk@vis.co.za>, zcommerce@codeit.com, zope@zope.org Subject: Re: [Zope] Costs of implementation
I think that the timeline J provided is unrealistically optimistic. The amount of time it will take someone to go from 0 to Zope varies wildly. We have had developers come in and in a matter of a few days they are very productive. Others take much longer. Several things affect this. Someone to show you the ropes being primary. Previous knowledge, especially in OOP and in python or pythonish language, is also crucial.
So how long depends on you. If you don't have someone who knows Zope and python expect to struggle up the near vertical learning curve of Zope. After helping to train several people on Zope I would recommend not reading any Zope documentation until after you understand python. In other words, learn the basics of python first. Know what a list, dictionary and tuple are and their syntax and operations and many of the mysteries of Zope will be cleared up (i.e. when do you need tics instead of quotes etc.). After garnishing a working knowledge (you don't need to be a Zen master of python) of python ,then read the Zope documentation and start working in Zope.
Just my experience working with newbies.....
Dan
"J. Atwood" wrote:
At 8:32 AM +0200 6/13/2000, D Swart wrote:
I am trying to motivate the use of Zope / Zcommerce, and to do this need some timing ideas - Does anyone have thoughts on how long (man hours per expertise) it took them to go from no Zope to (Zope + Steve Spickelmire and Co's EMarket) and to a successful transaction?
From 0 to Zope in under 6.2 seconds! :)
If you are totally new (no Zope in your blood) here is what I would expect. This does take into account that you know "something" about programming and variables and really good HTML as well as some server stuff (how to set up, IP addresses, shell scripts). I have put what it would take a Zopista in parenthesis (not me though, I only play one on the web).
1 day (1 hour) - Install Zope 1 day (done) - Download, print, read all guides and "howtos" 5 Days (2 days) - To get a basic site up and running. Log in, look and feel, tested, management, feel the power of Zope 1 day (2 hours) - Set up database backend and connect 5 days (2 days) - Build catalog system, Z SQL Methods, etc 2 days (2 days) - testing, testing, testing
This is very rough but should be around the amount of time. This does mean full "developing days" which are about 10-14 hours. I don't know about transactions so you might want to pad it a bit. I will say though, that once you get into developing with Zope you realize just how fast you can develop new products with it. It is an amazing working environment.
J
"RDM" == R David Murray <bitz@bitdance.com> 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 - ZCommerce@codeit.com RDM> http://lists.codeit.com/mailman/listinfo/zcommerce
I use the int value of the datetime of the last transaction multiplied by a random number generated for each day as the key to encrypt the CC data in my RDBMS. Once the customer has identified themselves via a cookie or by entering a customer id I can retrieve the last transaction datetime and use the appropriate stored multiplier for that day to retrieve their CC info from my DB. The CC DB is a separate table in a separate location. ----- Original Message ----- From: "R. David Murray" <bitz@bitdance.com> To: <zope@zope.org> Cc: <zcommerce@codeit.com> Sent: Thursday, June 08, 2000 7:57 PM Subject: [Zope] 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 _______________________________________________ Zope maillist - Zope@zope.org 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 )
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 <ngps@post1.com> * http://www.post1.com/home/ngps
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <20000609234524.A895@madcap.dyndns.org>, Ng Pheng Siong <ngps@post1.com> writes
Take a look at ZSmime,
Hi, Any ETA on the Win32 binaries? - -- Regards, Graham Chiu gchiu<at>compkarori.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-----
On Sat, Jun 10, 2000 at 07:58:48AM +1300, Graham Chiu wrote:
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 <ngps@post1.com> * http://www.post1.com/home/ngps
participants (12)
-
Andrew Kenneth Milton -
Bill Anderson -
Christopher J. Kucera -
D Swart -
Dan Rusch -
Derek Simkowiak -
Graham Chiu -
J. Atwood -
Jim Sanford -
Ng Pheng Siong -
R. David Murray -
Steve Spicklemire