ionCube Logo
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


 
Post new topic   Reply to topic    ionCube Forum Index -> ionCube PHP Encoder

storing credit cards in db

Author Message
mellymell



Joined: 19 Feb 2006
Posts: 2

PostPosted: Sun Feb 19, 2006 1:25 am    Post subject: storing credit cards in db Reply with quote

Hi.

I know that it's commonly held that you should never store credit card data on a remote server. I would, however, like opinions as to how secure the following setup would be...
  • All pages on a site that deal with credit card data are encoded with the ionCube encoder
  • Whenever a user interacts with a page that deals with credit card data, the connection is forced to use https SSL
  • When CC data is sent to server, it's encrypted using 3DES encryption and stored in a db in encrypted format
  • The mcrypt function used to encrypt and decrypt the card data is in a php file that's encoded using the Encoder and stored in a directory above the public_html directory

My thoughts are that because the file with the encrypt/decrypt function is encoded, as well as all files that reference the function in any way, shouldn't that provide some degree of security since not only will people not have access to the source of the function itself (which actually contains the encryption key), but they also won't even have a way of even knowing the NAME of the function used to encrypt/decrypt the data.

And, just for added security, the encoded "functions" file is stored above the web-level... But, even if a hacker gained access to it, it's all encoded. And doesn't this new 6.5 version offer even better security, making it that much harder to recover the encoded file, thereby keeping the encryption key secret?

And by the way, the encryption key is an md5 hash, so it's certainly not a dictionary word or anything.

Shouldn't this provide enough security to justify the storage of CC data in a webserver database? In case you're wondering why I would want to do that, it's just so that the billing aspect of my business would allow the card to be automatically charged upon renewal dates. My merchant provider's recurring billing option doesn't suffice because the rebilled price may vary from month to month.

I welcome your comments on this security scheme.
Back to top
View user's profile Send private message
johnnie2



Joined: 31 Dec 2005
Posts: 8

PostPosted: Fri Feb 24, 2006 8:44 pm    Post subject: re Reply with quote

Disclaimer, limitation of liability: don't take anything I say as doctrine. I am not responsible.

IMHO, a good way to approach analyzation of security schemes is to first identify what's really important.

Here it appears to be 3 things:
* the CC info in database
* triple DES encryption key
* use of triple DES algo

Given that the CC data must be stored in the database, we reduce the view to 1) use of triple DES, and 2) storage of the encryption key.

So then what you're really asking is: how secure is triple DES, and how secure is my storage of the encryption key?

The first you have to answer as only you have access to the exact parameters of the system. The second, *assuming* that the encryption key is kept in PHP code, is then answerable by the ionCube guys, since that PHP code is encoded by ionCube products in this scenario.
Back to top
View user's profile Send private message Visit poster's website
mellymell



Joined: 19 Feb 2006
Posts: 2

PostPosted: Fri Feb 24, 2006 9:20 pm    Post subject: Re: re Reply with quote

johnnie2 wrote:
The second, *assuming* that the encryption key is kept in PHP code, is then answerable by the ionCube guys, since that PHP code is encoded by ionCube products in this scenario.


Exactly. That's what I'm wondering. I hear that 3DES is the most secure encryption algorithm. So, just maintaining the security of the key is the real goal I would think.

For one level of security, I have the key stored above the web-viewable directory... But, this wouldn't help if someone actually hacked into the server.

For the additional level of security, having the page encoded with the ionCude encoder is what I'm hoping will make the security routine fairly sound. So, I hope to hear back from the ionCude guys on this one.
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2788

PostPosted: Sat Feb 25, 2006 3:19 am    Post subject: Reply with quote

These sound like good suggestions, and encoding scripts is sensible. In essence, the more protection the better. A potential danger for site owners with unencoded scripts is that unless they take certain precautions, PHP code could be modified by a hacker to store or forward sensitive data to other machines, and it could be some time before this was discovered. Encoding scripts so that they cannot be changed makes this much harder.
_________________
Community Admin
Back to top
View user's profile Send private message
feha



Joined: 11 Mar 2006
Posts: 28

PostPosted: Sat Mar 11, 2006 9:36 am    Post subject: Be carefull Reply with quote

I think that you should take care the encryption keys are not STORED in any constant or variable as this could be a risk.

The key should be hard coded ...
Back to top
View user's profile Send private message Visit poster's website
fluffytigger



Joined: 20 Feb 2006
Posts: 6

PostPosted: Mon Mar 13, 2006 2:23 am    Post subject: Reply with quote

Or how about remote key storage?

Have the key for encryption and decryption on a second server, whenever you need processing, have it call the 2nd sever to retrieve it from an encrypted stated there, then use it to work with your encryption on the primary site.

That way hackers would need to compromise both servers within a short period of time or without you knowing anything in order to effective use the key before you had a chance to change it.

To make things even more secure, you can have the key split into 2, but then you would need to store it in 4 different places to ensure that if one of the server goes down you'd still have a complete good copy to query.
_________________
I'm a Small Fluffy Animal
Back to top
View user's profile Send private message
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2788

PostPosted: Mon Mar 13, 2006 12:13 pm    Post subject: Reply with quote

Looking at this again, do consider whether you really need to store credit card numbers, or whether storing a hash of them is good enough. If your purpose is purely to compare credit card numbers in the future, an irreversible hash would be fine. If it's just to make it easier for the customer on future purchases, it could be one feature that you decide not to offer because of the potential security problem. However, if you need recurring billing, then you do need something.

A second machine could be a good idea, and eliminating the risk from a compromised web server due to flaws in PHP. You also need not even retrieve information. You could perform the actual processing on the second machine, never passing card information out of the machine. Lock it down as tightly as possible, non web accessible, and have a protocol between the two machines to request processing. This is going a bit far perhaps, but one could even write a custom PHP C module to handle the protocol between the two machines to make the protocol harder to figure out.
_________________
Community Admin
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ionCube Forum Index -> ionCube PHP Encoder All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum