Guest Brivtech Posted July 21, 2006 Share Posted July 21, 2006 I'm interested to know more about security issues that could come about with CubeCart using email to pass customer credit card details for later processing through a manual credit card terminal in a shop. My Email features 256-bit encryption, which is double the usual encryption used for SSL certificates. Banks only use 128-bit, so perhaps it would seem that the 256-bit encryption is overkill - Well, perhaps not. So, as I'm using a tank instead of an armoured car for my email delivery, why couldn't I be using CubeCart for passing credit card details back, instead of storing details on the server (Which is more vunerable to attack?) for later manual processing, or worse still, signing up with someone like Mal's and entrusting them with the credit card details. Has anyone got any further comments on this? I'd like to look at both the pros and cons here. I know that the official position from Devellion at the present time is not to go ahead with a manual credit card processing MOD as part of the package, and that I can understand from server vunerabilities, but isn't my 256-bit email a different animal altogether? Quote Link to comment Share on other sites More sharing options...
convict Posted July 23, 2006 Share Posted July 23, 2006 I'm interested to know more about security issues that could come about with CubeCart using email to pass customer credit card details for later processing through a manual credit card terminal in a shop. My Email features 256-bit encryption, which is double the usual encryption used for SSL certificates. Banks only use 128-bit, so perhaps it would seem that the 256-bit encryption is overkill - Well, perhaps not. So, as I'm using a tank instead of an armoured car for my email delivery, why couldn't I be using CubeCart for passing credit card details back, instead of storing details on the server (Which is more vunerable to attack?) for later manual processing, or worse still, signing up with someone like Mal's and entrusting them with the credit card details. Has anyone got any further comments on this? I'd like to look at both the pros and cons here. I know that the official position from Devellion at the present time is not to go ahead with a manual credit card processing MOD as part of the package, and that I can understand from server vunerabilities, but isn't my 256-bit email a different animal altogether?Some standard CubeCart gateways do use Credit Card details transfering - what those gateways are using? SSL. Your solution is much more secure as manual prcessing gateway stored Credit Card data on site. Your solutiion is comparable to standard used SSL via HTTP but remember - it depends to transer way. Email is NOT transfered direct to email box in most of cases. Quote Link to comment Share on other sites More sharing options...
vokf Posted July 23, 2006 Share Posted July 23, 2006 I'm interested to know more about security issues that could come about with CubeCart using email to pass customer credit card details for later processing through a manual credit card terminal in a shop. My Email features 256-bit encryption, which is double the usual encryption used for SSL certificates. Banks only use 128-bit, so perhaps it would seem that the 256-bit encryption is overkill - Well, perhaps not. So, as I'm using a tank instead of an armoured car for my email delivery, why couldn't I be using CubeCart for passing credit card details back, instead of storing details on the server (Which is more vunerable to attack?) for later manual processing, or worse still, signing up with someone like Mal's and entrusting them with the credit card details. Has anyone got any further comments on this? I'd like to look at both the pros and cons here. I know that the official position from Devellion at the present time is not to go ahead with a manual credit card processing MOD as part of the package, and that I can understand from server vunerabilities, but isn't my 256-bit email a different animal altogether? Hi Brivtech, in theory, it should be ok, but unless you're using a secure email session (TLS or SSL) you'll be sending passwords in plain text. If someone guessed or sniffed your password, they would then be able to download your emails. If they had your emails, they could try a brute-force attack on your 256-bit encryption at their lesuire... Which method of encryption are you using? Providing its an established method (AES/DES etc) and proven to be very secure, it's going to be safe. If the encryption is something you've written yourself, its not going to stand up. If someone was determined, they could spend weeks attacking the encryption, and then quietly grab any new emails. I *think* Actinic Catalog used to allow Credit Card info via email (this was a few years ago though!) An even higher level of security would be to split the CC details so that the CC database holds exp date, last 4 digits and the security code, and the email holds the remainder. Neither are much good without the other... Jason Quote Link to comment Share on other sites More sharing options...
Guest Brivtech Posted July 23, 2006 Share Posted July 23, 2006 Thanks guys for the response, that's raised some very good points... Email is NOT transfered direct to email box in most of cases. in theory, it should be ok, but unless you're using a secure email session (TLS or SSL) you'll be sending passwords in plain text. Okay, so here is a possible security flaw - I would have to ensure that any system that sends email to the mailbox uses comparable encryption. Once the email is delievered to the mailbox, it's the webmail system uses the 256-bit encryption, so delivery from the mailbox is reasonably secure. An even higher level of security would be to split the CC details so that the CC database holds exp date, last 4 digits and the security code, and the email holds the remainder. Neither are much good without the other... That's even better still. So even if the email was intercepted, only half the useable data would be there. Which method of encryption are you using? Providing its an established method (AES/DES etc) and proven to be very secure, it's going to be safe. If the encryption is something you've written yourself, its not going to stand up. Well, the 256-bit encryption refers to the webmail, and uses AES. But, it's getting the system email into the inbox that I will need to rethink. I guess there is limited security already, as the process would be automatic. Any suggestions of improving the server-side emailing security? EDIT: I've had a response back from my hosting support, confirming that "server-side scripts for sending email would not maintain SSL support" to the mailbox. So that means the email would definetly be vunerable to interception until it reaches the mailbox. Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2006 Share Posted October 11, 2006 Hello y'all, I just read this and wanted to point out some basic credit card requirements. If any card details are to be sent through the internet, they are required to be encrypted. Under no circumstances must the CVV or CVC2 number be stored after the card has been authorized and authorization needs to happen promptly (ie can't store it for a week and process a week later...). If the card details are to be stored, they must be encrypted and stored in a server that is not directly accessible from the internet (ie the database can't be on the same server as the web server)There are lots of other requirements if you are processing credit cards directly. Information on the Card Industry requirements can be found at: http://www.visa.com/cisp While currently only the high-volume merchants are getting exposure due to audits, all it would take is one stolen card from your shop and your company instantly becomes a level 1 merchant with all requirements (including paying for an audit by a visa certified company, usually minimum cost $10,000 but more likely up to 20-30k)...so please even if you don't have much traffic, keep in mind the well established guidelines provided by the card industry when you design and deploy your online stores. If you are wanting to send an email with the card details for offline processing, please examine the use of gnupg or pgp and always securely wipe any temporary files you use to create the email after it is created (ie use "wipe" or similar function, again a CISP requirement..) If you have any questions please feel free to drop me a note, I am a merchant as well as a visa qualified security professional (ie i can do audits for certified audit companies). Good luck, and remember to treat your customers info like it was your own dmz ------- [email protected] DMZ Services - Managed Servers & Security ZZ Servers - Managed and Unmanged hosting and services Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2006 Share Posted October 11, 2006 .... An even higher level of security would be to split the CC details so that the CC database holds exp date, last 4 digits and the security code, and the email holds the remainder. Neither are much good without the other... Jason According to the Card industry (Visa, Master Card, Discover, Diners Club, Amex, ....) the storage of the "Security Code" is not allowed. From the CISP security audit procedures document: 3.2.2 Do not store the card-validation code [three-digit or four-digit value printed on the front or back of a payment card (e.g., CVV2 data or CVC2 data)]. 3.2.3 Do not store the PIN Verification Value (PVV). And if you are audited they will check for this. David PS PVV is something usually only obtained if you "swipe" a card. Here is the audit procedure for 3.2.2: 3.2.2 Examine the following from the sample selected and obtain evidence that three-digit or four-digit card-validation code printed on the signature panel (CVV2/CVC2 data) is not stored under any circumstance: • Incoming transaction data • Transaction logs • History files • Several database schemas ---- David M. Zendzian [email protected] Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.