Off topic except that I happen to be using EM for this, and there are some smart folks here.. I while back I think I posted about a credit card processing application I was writing. At the time it was for a payment gateway I worked for, now I no longer work there and am implementing an open source payment platform. One of the big challenges is how to make the application secure yet easy enough to use for someone that doesn''t have tons of resources. I''m used to working in an environment where you protect data with multiple levels of security, but that''s beyond what most people have the resources to do. So I''m working on the best compromise that I can come up with. The encryption is AES in a pkcs7 envelope. Card numbers have to be stored for two uses. The first use is storing them after authorization for use during settlement. The second use is to store card numbers long term and associate them with an id. The end user can at a later time send in just the id instead of the full card number for things like refunds or for recurring transactions, or do an update request to update the card expiration date, etc.. There are no methods exposed via external apil''s to retrieve the plaintext card number. Right now the private key is kept on disk encrypted, and when the application is run it prompts for the password, decrypts the private key, and keeps it in memory. What I''m struggling with is beyond that, how much more complexity should I add before it''s too much. For example, one extra measure that would add security is for the application that runs on an internet server to not have access to the private key. The private key is needed in 3 scenarios as follows: 1. When using the refund method, which takes an id of a previous transaction 2. When capturing authorized transactions at the end of the day 3. For running recurring billing transactions Since you can run multiple instances of the application at the same time, you could just run a script on a local secure machine that captures the daily transactions and processes the recurring billing. The refunds could be handled this way also, since refund transactions are never authorized in real time, they are just submitted with the batch to the bank. But at this point, I''m wondering if it''s getting too complicated for people. The benefit of using this whole system is that you get rid of the payment gateway and get access to the complete codebase. It''s an advantage for some, but if it''s too complicated I''m afraid the advantages will start to disappear. Thoughts? Chris
On 3/4/07, snacktime <snacktime at gmail.com> wrote:> > Off topic except that I happen to be using EM for this, and there are > some smart folks here.. > > I while back I think I posted about a credit card processing > application I was writing. At the time it was for a payment gateway I > worked for, now I no longer work there and am implementing an open > source payment platform. One of the big challenges is how to make the > application secure yet easy enough to use for someone that doesn''t > have tons of resources. I''m used to working in an environment where > you protect data with multiple levels of security, but that''s beyond > what most people have the resources to do. So I''m working on the best > compromise that I can come up with. > > The encryption is AES in a pkcs7 envelope. Card numbers have to be > stored for two uses. The first use is storing them after > authorization for use during settlement. The second use is to store > card numbers long term and associate them with an id. The end user > can at a later time send in just the id instead of the full card > number for things like refunds or for recurring transactions, or do an > update request to update the card expiration date, etc.. There are no > methods exposed via external apil''s to retrieve the plaintext card > number. > > Right now the private key is kept on disk encrypted, and when the > application is run it prompts for the password, decrypts the private > key, and keeps it in memory. What I''m struggling with is beyond that, > how much more complexity should I add before it''s too much. > > For example, one extra measure that would add security is for the > application that runs on an internet server to not have access to the > private key. The private key is needed in 3 scenarios as follows: > > 1. When using the refund method, which takes an id of a previous > transaction > 2. When capturing authorized transactions at the end of the day > 3. For running recurring billing transactions > > Since you can run multiple instances of the application at the same > time, you could just run a script on a local secure machine that > captures the daily transactions and processes the recurring billing. > The refunds could be handled this way also, since refund transactions > are never authorized in real time, they are just submitted with the > batch to the bank. But at this point, I''m wondering if it''s getting > too complicated for people. The benefit of using this whole system is > that you get rid of the payment gateway and get access to the complete > codebase. It''s an advantage for some, but if it''s too complicated I''m > afraid the advantages will start to disappear.Seems to me, as a security practitioner, that the entire process space which runs these applications is security sensitive and there''s no simple way to make it more resistant to compromise, without isolating it from internal and external networks, and from theft. (I''m sure it occurred to you that holding a private key in RAM means it can get swapped out to disk. We build highly-secure machines without any swap space, among other things.) Are you building an application that''s going to be deployed on arbitrary hardware and OSs in retail establishments? Can you consider running this as an internet-based service and sidestep the whole issue? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/ebece757/attachment.html
Almost every problem you can have here is going to be in the details, not the design --- how you generate keys, how you turn passphrases into key-encrypting keys, how you keep cleartext and key matter out of insecure memory, when/where you decrypt keys, whether you can keep seperate keys/cleartext for seperate capabilities (and thus keep payment card data for dispute resolution segregated from payment card data for one-click shopping). The other comment I will make, and you won''t like, is that if you''re doing any kind of persistent storage of secrets, you should be using GPG absent a really strong security reason not to: there are a zillion things you can get wrong with a system like this, and there''s no public tool outside of GPG that has been audited for them. For what it''s worth, swap bugs me a lot less than having keys in memory on machines that support ptrace, kmem, ReadProcessMemory, firewire, device drivers, the C programming language, turing completeness, information storage, etc. On 3/4/07, snacktime <snacktime at gmail.com> wrote:> Off topic except that I happen to be using EM for this, and there are > some smart folks here.. > > I while back I think I posted about a credit card processing > application I was writing. At the time it was for a payment gateway I > worked for, now I no longer work there and am implementing an open > source payment platform. One of the big challenges is how to make the > application secure yet easy enough to use for someone that doesn''t > have tons of resources. I''m used to working in an environment where > you protect data with multiple levels of security, but that''s beyond > what most people have the resources to do. So I''m working on the best > compromise that I can come up with. > > The encryption is AES in a pkcs7 envelope. Card numbers have to be > stored for two uses. The first use is storing them after > authorization for use during settlement. The second use is to store > card numbers long term and associate them with an id. The end user > can at a later time send in just the id instead of the full card > number for things like refunds or for recurring transactions, or do an > update request to update the card expiration date, etc.. There are no > methods exposed via external apil''s to retrieve the plaintext card > number. > > Right now the private key is kept on disk encrypted, and when the > application is run it prompts for the password, decrypts the private > key, and keeps it in memory. What I''m struggling with is beyond that, > how much more complexity should I add before it''s too much. > > For example, one extra measure that would add security is for the > application that runs on an internet server to not have access to the > private key. The private key is needed in 3 scenarios as follows: > > 1. When using the refund method, which takes an id of a previous transaction > 2. When capturing authorized transactions at the end of the day > 3. For running recurring billing transactions > > Since you can run multiple instances of the application at the same > time, you could just run a script on a local secure machine that > captures the daily transactions and processes the recurring billing. > The refunds could be handled this way also, since refund transactions > are never authorized in real time, they are just submitted with the > batch to the bank. But at this point, I''m wondering if it''s getting > too complicated for people. The benefit of using this whole system is > that you get rid of the payment gateway and get access to the complete > codebase. It''s an advantage for some, but if it''s too complicated I''m > afraid the advantages will start to disappear. > > Thoughts? > > Chris > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >
> > Are you building an application that''s going to be deployed on arbitrary > hardware and OSs in retail establishments? Can you consider running this as > an internet-based service and sidestep the whole issue?If by internet based service you mean a commercial service, then yes part of the plan is to use the application as the platform for a commercial payment gateway for smaller companies that wouldn''t want to run it in house. The whole thing would be open source though for companies that want to run it in house. The basic gateway is done as of now with working links to Vital and Firstdata, I just need to find the time to do the certifications before I can release it. I''ve done them half a dozen times before and worked with the same protocols for years, so the first version should be fairly robust. The commercial service is a ways off though, probably a good 8-10 months. Chris
Since this is a bit off topic and area I sort of got stuck in without wanting to be, I will throw in my 2 pesos. The struggle I have always had with encryption-based software has been in the overall design of where the keys are and how long they persist, etc. Most of the time you want to ensure any type of transaction will be available in memory for a very short of amount of time (hopefully quantified down to clock cycles), because at some point in the process everything is unencrypted, even if for a blink of an eye. Also, if you are required to actually retain the credit card numbers and owner information, you are now bound to an enormous amount of regulatory issues. You should look up this: "Payment Card Industry Data Security Standards (PCI DSS)" which is a guideline about handling credit card info, etc.. It''s a good thing to understand prior to building out any software that deals with credit card processing. I know this is even further off topic, but I wanted to make you aware of some of the things you may run into or be asked about in the future. -----Original Message--- Almost every problem you can have here is going to be in the details, not the design --- how you generate keys, how you turn passphrases From: eventmachine-talk-bounces at rubyforge.org [mailto:eventmachine-talk-bounces at rubyforge.org] On Behalf Of Thomas Ptacek Sent: Sunday, March 04, 2007 10:12 PM To: eventmachine-talk at rubyforge.org Subject: Re: [Eventmachine-talk] OT: key protection methods into key-encrypting keys, how you keep cleartext and key matter out of insecure memory, when/where you decrypt keys, whether you can keep seperate keys/cleartext for seperate capabilities (and thus keep payment card data for dispute resolution segregated from payment card data for one-click shopping). The other comment I will make, and you won''t like, is that if you''re doing any kind of persistent storage of secrets, you should be using GPG absent a really strong security reason not to: there are a zillion things you can get wrong with a system like this, and there''s no public tool outside of GPG that has been audited for them. For what it''s worth, swap bugs me a lot less than having keys in memory on machines that support ptrace, kmem, ReadProcessMemory, firewire, device drivers, the C programming language, turing completeness, information storage, etc. On 3/4/07, snacktime <snacktime at gmail.com> wrote:> Off topic except that I happen to be using EM for this, and there are > some smart folks here.. > > I while back I think I posted about a credit card processing > application I was writing. At the time it was for a payment gateway I > worked for, now I no longer work there and am implementing an open > source payment platform. One of the big challenges is how to make the > application secure yet easy enough to use for someone that doesn''t > have tons of resources. I''m used to working in an environment where > you protect data with multiple levels of security, but that''s beyond > what most people have the resources to do. So I''m working on the best > compromise that I can come up with. > > The encryption is AES in a pkcs7 envelope. Card numbers have to be > stored for two uses. The first use is storing them after > authorization for use during settlement. The second use is to store > card numbers long term and associate them with an id. The end user > can at a later time send in just the id instead of the full card > number for things like refunds or for recurring transactions, or do an > update request to update the card expiration date, etc.. There are no > methods exposed via external apil''s to retrieve the plaintext card > number. > > Right now the private key is kept on disk encrypted, and when the > application is run it prompts for the password, decrypts the private > key, and keeps it in memory. What I''m struggling with is beyond that, > how much more complexity should I add before it''s too much. > > For example, one extra measure that would add security is for the > application that runs on an internet server to not have access to the > private key. The private key is needed in 3 scenarios as follows: > > 1. When using the refund method, which takes an id of a previoustransaction> 2. When capturing authorized transactions at the end of the day > 3. For running recurring billing transactions > > Since you can run multiple instances of the application at the same > time, you could just run a script on a local secure machine that > captures the daily transactions and processes the recurring billing. > The refunds could be handled this way also, since refund transactions > are never authorized in real time, they are just submitted with the > batch to the bank. But at this point, I''m wondering if it''s getting > too complicated for people. The benefit of using this whole system is > that you get rid of the payment gateway and get access to the complete > codebase. It''s an advantage for some, but if it''s too complicated I''m > afraid the advantages will start to disappear. > > Thoughts? > > Chris > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >_______________________________________________ Eventmachine-talk mailing list Eventmachine-talk at rubyforge.org http://rubyforge.org/mailman/listinfo/eventmachine-talk
On 3/4/07, Roland Cozzolino <roland at bayshorenetworks.com> wrote:> Since this is a bit off topic and area I sort of got stuck in without > wanting to be, I will throw in my 2 pesos. > > The struggle I have always had with encryption-based software has been in > the overall design of where the keys are and how long they persist, etc. > Most of the time you want to ensure any type of transaction will be > available in memory for a very short of amount of time (hopefully quantified > down to clock cycles), because at some point in the process everything is > unencrypted, even if for a blink of an eye. Also, if you are required to > actually retain the credit card numbers and owner information, you are nowu> bound to an enormous amount of regulatory issues. You should look up this:> "Payment Card Industry Data Security Standards (PCI DSS)" which is a > guideline about handling credit card info, etc.. It''s a good thing to > understand prior to building out any software that deals with credit card > processing. > > I know this is even further off topic, but I wanted to make you aware of > some of the things you may run into or be asked about in the future.I should have prefaced this. I''ve worked in the payments industry for about 12 years and have created a good portion of the code in two commercial payment gateways, as well as managed several PCI audits. I''ll admit I don''t have any easy answers yet as to how to make an application like this both simple and secure. Most of the security is in the surrounding environment and the layers of firewalls that it normally goes behind. My personal goal though is to make as much of it as accessible as possible. I''ve already planned on having to host some of it via a commercial service, but the goal is to minimize that as much as possible and have most of the system run on your own webserver if you don''t want to create a secure environment to run the whole thing in. Chris Chris