Hello:

I'm posting here in hopes to hear a answer from people who have third hand experience with open source technologies - PHP/MySQL in particular. I'm beginning to develop using PHP & MySQL, coming from a .net background using SQL Server & ASP.net. And most other major databases: DB2 & Sybase. I'm planning to store credit card numbers into a MySQL table, and need to know what is the most secure way of doing so. I read that PHP comes with an extension called: Mcrypt. Which is popular with most *Nix distributions. PHP has a function called: Mcrypt_Encrypt & Mcrypt_Decrypt. Is this probably the method to use? Is there a better way? Teach me some basics at least. I don't know MySQL very well.

Thank you!

Credit card numbers are tricky.

Mcrypt should be able to do it just fine provided you use a secure encryption alogrythm such as TripleDES or something similar.

Also, make sure you use a secure encryption key. The best encryption key will be random letters and numbers in the longest combination possible.

Thanks! for the reply back. Do you happen to have any examples that i can look at? like a PHP script that connects to a MySQL table and then encrypts it with the TripleDES system?

Thanks!

PHP.net site concerning mcrypt (http://us2.php.net/mcrypt)

Sharing encrypted token between .net and php (http://forums.devarticles.com/t3980/s.html)

Basic security article (http://www.squatty.com/article.php/20040307105837840)

Security site (http://www.rsasecurity.com/rsalabs/node.asp?id=2231)

For more information,using php.net to bounce around from subject to subject is faster and easier, and in the comments, you usually see pretty good coding examples, including your needs for the database connections.

I am also assuming that you have already checked with your cc processor to make sure this does not violate your terms and conditions of using their services? By storing credit cards, I have heard some cc processors have a scale of frowning on it, up to blacklisting you for services in their companies.

Just figured I'd throw that out there...hope this post helps!
--jim

mcrypt works pretty good, but if you don't have mcrypt extension, you could use either Crypt_Blowfish ( http://pear.php.net/package/Crypt_Blowfish ) or Crypt_RC4 ( http://pear.php.net/package/Crypt_Blowfish ) which work pretty good, and do not require any PHP extensions

Matt:

Thanks! for the reply. To help me understand this better... is the pear package script like raw PHP code? it's not a .dll extension you have to register on the server?

yes, the pear package is a php file.

The functions within it are stored within a class, so you'll have to learn how to initiate classes and call functions within them.

Originally posted by erod84
Matt:

Thanks! for the reply. To help me understand this better... is the pear package script like raw PHP code? it's not a .dll extension you have to register on the server?

Yeah, PEAR packages are all PHP classes, pure PHP code. There are many many useful packages in PEAR ( http://pear.php.net )

PECL packages, are PHP extensions, which are .dll or .so files. They are found on http://pecl.php.net

An example of how using encryption with Crypt_Blowfish
require_once 'Crypt/Blowfish.php';
$b = new Crypt_Blowfish()
$encrypted = $b->encrypt('test');
$decrypted = $b->decrypt($encrypted);

Thanks! to all the replies i got back here. I downloaded all the packages everybody mentioned. I'm already coding some sample tests, for internal test use. Thanks! to Matt as well for supplying the code example, that one was quite useful for me. I do understand the logic behind development; it's mainly the syntax that gets me every time when i try to learn a new language.

I'm using PHP 4.3.10 with IIS 5.1 on Windows XP Professional.

Just so you all know for reference, that IIS 5.1 that comes with Windows XP Professional doesn't allow more than (1) domain hosted on it. I'm using an ISAPI filter to add more domains to it, i've found a way around this in case anybody is interested. This is mainly a selling point seems to get you hooked on IIS to purchase the Server software.

Thanks! for the wonderful help & tips you all supplied to me.

Why not just use apache instead? What is the reason for coupling php, IIS, and mysql? Seems like a strange combo :)

I should also mention - be very careful here. Using symmetric encryption to store CC numbers is likely not a great idea - why? You still have to keep the key stored on the server. If someone can get in as the web user, chances are they can read the key pretty easily as well. Food for thought.

You may want to rethink your need for storing credit card numbers. Obviously you cannot make the decryption key available to any public server so I do not see what you gain by saving the number.

One thing you might consider doing is using GPG to encrypt the data, at least that would give you the benefits of asymmetric encryption, and you wouldnt have to keep the private key on the server.

Best thing to do probably though is to either not store it at all, or store it offline, preferably using GPG as the transport mechanism for the transfer from the server to an offline mechanism.

Wow! thanks for all the insight here. I'm reading up on public keys. I do have a question. How do web hosting corporations bill their clients on a monthly basis? do they typically store sensitive financial information such as credit cards in a database? or some other means?

Thanks! very much.

Originally posted by erod84
Wow! thanks for all the insight here. I'm reading up on public keys. I do have a question. How do web hosting corporations bill their clients on a monthly basis? do they typically store sensitive financial information such as credit cards in a database? or some other means?

Thanks! very much.

They store them in a database, or let a 3rd party processor take care of it.

Any smart web host that actually stores numbers in the database, would not store the key on the server as well.

Pheaton:

Thanks! for the reply back. I thought they stored them in a database table. Would you recommend using GPG like Innova suggested? seems you don't have to store a key on the server for that.

What you recommend? if you have to bill clients on a monthly basis?

I saw you run a hosting business yourself. Thought you would have some advice for me. If a database system is a option, which database server if the most efficient for this investment wise?

Thanks!

Well, without getting into the big bucks, I would recommend MySQL, which should already be preinstalled on most unix systems.

MySQL in conjunction with mcrypt using TripleDES encryption system and NOT storing the key on the server would be a fairly secure system.

Now if you're loaded with cash and have lots to spend, that would be a whole different story.

TripleDES is still symmetric though..you need a way to get the data to the offline database server. A feasible, though slightly less secure solution would be have a server dedicated to holding the credit card information, which is heavily firewalled and accepts no traffic from the general internet, but will accept WRITE ONLY requests to the CC database from the web server. On a write, it can subsequently encrypt the credit card data and store it. All billing etc. should be scheduled and performed from this server only.

Originally posted by error404
TripleDES is still symmetric though..you need a way to get the data to the offline database server. A feasible, though slightly less secure solution would be have a server dedicated to holding the credit card information, which is heavily firewalled and accepts no traffic from the general internet, but will accept WRITE ONLY requests to the CC database from the web server. On a write, it can subsequently encrypt the credit card data and store it. All billing etc. should be scheduled and performed from this server only.


Yes, it is. But if you code it correctly, it will still require you to enter a decryption key in order to get you data back.

Pheaton:

Thanks! again for replying.

"Now if you're loaded with cash and have lots to spend, that would be a whole different story."

Can you elaborate a bit more on this? what are my options? do you mean a more secure database such as Oracle?

Thanks!

Pheaton,

You dont understand symmetric encryption, and you are confusing the poster.

MySQL in conjunction with mcrypt using TripleDES encryption system and NOT storing the key on the server would be a fairly secure system.

Any smart web host that actually stores numbers in the database, would not store the key on the server as well....if you code it correctly, it will still require you to enter a decryption key in order to get you data back.

Look, its as simple as this. Any data you want to encrypt with 3DES requires you to keep your secret key on the server. Otherwise, it cannot encrypt it (duh).

Therefore, to decrypt, you MUST have the same key ON THE SERVER. There is no way I am aware of that would allow you to magically encrypt something and not store the key on the server using symmetric encryption, which 3DES is. Please enlighten us.

Error404's idea is a lot more secure than having both on a shared server, but web server compromise may still lead to the eventual loss of confidential data (although it would be significantly harder using his way).

Now if you're loaded with cash and have lots to spend, that would be a whole different story.

We are all wondering what you mean by this. Are you implying that mysql is not secure? Whats your evidence?

What I meant by not storing the key on server is not storing it at all. You would ofcourse have to encrypt and decrypt the data by inputing the key yourself, much like most of the billing scripts out on the market.

Another way is you could store the key on the server inside an ioncube or zend encrypted file, and then have a short access hash to decrypt the data. Modernbill uses this in their LEK logic.

Im not implying that mysql is not secure, Im implying that there are better (and much more expensive) solutions out there that would suit larger companies. One example of this would be to use oracle instead of mysql.

I really wouldn't trust creditcard information to one of those lame PHP encoders. It would be fairly trivial to get the key if the hacker wasn't discovered...just attach a debugger to PHP and watch the memory. I also don't believe those things are really all that secure, it's just not worth the effort to bother trying to break them for some PHP you could hack together yourself in a day or two. Credit card numbers are another story. Symmetric encryption in general is a bad idea in this case; it's only really useful for protecting from eavesdropping, not protecting data from someone who has access to the servers in question.

The best easily implemented solution is to use asymetric encryption like PGP, and store only the public key on the server. Then have a completely isolated box with the private key that does but one thing..sends your CC processor all the necessary billing requests, and creates your invoices.

What I meant by not storing the key on server is not storing it at all. You would ofcourse have to encrypt and decrypt the data by inputing the key yourself, much like most of the billing scripts out on the market.

Well that would preclude you from accepting credit cards online. This is probably NOT how most billing scripts work. I am not sure why any billing script would purposely work this way.

Another way is you could store the key on the server inside an ioncube or zend encrypted file, and then have a short access hash to decrypt the data. Modernbill uses this in their LEK logic.

That would be a better way to go. Keep in mind though, literal strings are not encrypted, so code like this will reveal your key, encrypted or not (see below).

Do NOT just assign your encrypt key to a variable.. Doing so allows anyone halfway familiar with PHP to pull the info by looking through the GLOBAL variable... Example


include("configfile.php.enc");
while (list ($key, $val) = each ($_GLOBAL)) {
echo "$key => $val<br />\n";
}


Oh look theres a variable called CRYPTKEY I wonder that that is. :)

Im not implying that mysql is not secure, Im implying that there are better (and much more expensive) solutions out there that would suit larger companies. One example of this would be to use oracle instead of mysql.

Why? What does Oracle do that Mysql doesnt? Obviously, things like stored procedures, triggers, etc, none of which are REQUIRED for simple ecommerce. I fail to see how spending money on Oracle will bring benefit to the poster of this discussion.

MySQL also has a fairly good 2-way encryption function. AES_ENCRYPT() AES_DECRYPT().

Takes 2 parameters, first being what to cipher and second being the key.

Following example uses a weak key, but it's good for minimal security incase somebody hacks in DB and views around.

UPDATE resident SET ssn = AES_ENCRYPT(ssn, (residentId*5.45));

SELECT AES_DECRYPT(ssn, (residentId*5.45)) FROM resident;

Encryption is 128bit, so use varchar lengths of that size.

I really wouldn't trust creditcard information to one of those lame PHP encoders. It would be fairly trivial to get the key if the hacker wasn't discovered...just attach a debugger to PHP and watch the memory.

I dont really agree with you here. I dont think it would be trivial at all. I dont have any real evidence for you, except that there seems to be no news of break-ins by exploiting either Zend or Ioncube. There has been a rash of information theft lately, but it usually comes by way of people not storing things securely at all, or social engineering.

For credit card information, I think the million dollar question is this: Will the encryption and/or script encoding scheme last longer than the credit card numbers are retained for?

I wouldnt consider it sufficient for national security, where secrets must be protected for 50+ years. However, I think by doing some of the practices discussed here, you are covered MUCH better than most people do things and would be reasonably safe.

Then again, I would prefer to use GPG and keep all that data offline and manually run the billing once monthly, but that may not be feasible for some, and by using security in layers they can achieve similar levels of protection.

We should put together some sample scripts and have a hacking challenge :)

If you were using a PHP encoder, the key would have to be in memory in the clear at some point to ever execute the encryption/decryption. If you knew what you were doing, and gained root on the box, it would be fairly trivial to get the string by creating a core file, or by attaching a debugger to the process. Far from a pedestrian task, but not anything I would call real security either. PHP also has basic introspection features, and from my understanding of these encoders, you could create your own encoded PHP file that includes all the rest of them, and gather information about the script's internals. Enough to get the function name of the function that gives you the clear key, and there you go, that's all you need. When we're talking 100's or 1000's of credit card numbers, and when it's absolutely possible to create a much more secure situation, that's simply not acceptable. This is a very dangerous situation for credit card numbers to be released under...chances are that you'll never even find out. The credit card company may be smart enough to realise that everyone complaining of stolen #'s has run transactions through your company, but they may not. And should that happen, they're definitely going to reevaluate where they stand with your security policies, and if it was my many-thousands to millions of dollars on the line, I certainly wouldn't trust that sort of a scheme.

Symmetric encryption works well for data transmission, ie. between a POS terminal and a bank, where the point of the encryption is to protect the information in transit, and where a physical security break of the device (say, patching some sort of PIN logging device onto it) is as good to someone attacking the device as logical one is (snooping the connection, decrypting the contents, and getting PINs that way). Both reach the same goal, the key does you no good once you have unfettered access to the device. On top of that, the key is encoded in the hardware, and cannot be changed or read without destroying the device itself. However, in this case, the entire point of the encryption is to protect the data in the case of a break in the security of the box. That means that any data on the internet accessible box is available to any attacker. Since the script that updates the database needs the key somehow in a symmetric scheme, it will always be possible for an attacker to break this. Though it may not be easy, there is no real protection other than that of obscurity, which really isn't any protection at all, assuming a knowledgable attacker.

In any case, you really must consult your CC processor about their policies regarding storing credit card information. As far as I know, this is strictly shunned throughout the industry, without strict security guidelines (which I'm almost positive such a weak scheme would violate) and you may lose your merchant account over it if they find out and aren't aware of it.

IMO, security is not something you can take lightly when concerning information like this, and on the whole the industry does do just that. All the time we hear of information theft problems, from such big institutions as universities...merely because their servers got cracked. And I really hope most e-commerce doesn't run on such flaky security premises as are being proposed here. There are many secure ways to store this information, but mere symmetric encryption with an obscured key, on a publicly reachable box is just not enough.

Thank you! all so much for taking the time to reply to my thread.

Innova, i do appreciate you standing up for me. Pheaton was confusing me there a bit. Money is not so much of the issue, if i have a will there will be a way. I don't really see how Oracle is more secure than Open Source databases? of course i'm not an OCP "Oracle Certified Professional" either. I have had thoughts about setting my ordering process, so that it'll encrypt a email message using GPG and then storing the private key on my drive (Which Will Not Allow Outside Connections) and then decrypt it using Outlook 2003. So i can manually enter the billing information into a program such as Intuit Quickbooks.
My bank does not appear to have the option to setup automatic monthly billing. By using this scenerio, nothing will be stored on the server related to Credit Card information.

I'll wait and see what you all have to say about this.

Thanks! a lot. I do very much appreciate your advice, as i'm seriously taking all your suggestions into plan.

I have had thoughts about setting my ordering process, so that it'll encrypt a email message using GPG
You need to implement intrusion detection, encrypting without is just a small bump no hacker will feel, since it will be very easy to replace your GPG with compromised one or just replace your scripts that take CC and send hacker a copy. If you serious about security look up

http://samhain.sourceforge.net - Samhain
http://osiris.shmoo.com - Osiris
http://aide.sourceforge.net - AIDE
http://www.tripwire.org - tripwire


and then storing the private key on my drive (Which Will Not Allow Outside Connections)
you download email from the server that could be easily seeded with trojans and then decrypt it using Outlook 2003. Outlook had been compromised many times

So i can manually enter the billing information into a program such as Intuit Quickbooks.

Trojan augments your TCP stack so next time you download email it will find your password protected Quickbooks file and while email is being downloaded to your computer will email to the hacker your Quickbooks database. Cracking Quickbooks takes no time.

Better take AlphaOne's recommended course of action and find a way to make it 100% secure, less than 1e-40 chance of a breakin. Make it impossible for terrorists and 'evil-doers' to haxor your box!

Might as well unplug the Lan cable and stop doing business online.

In case you didn't notice, this is a tinge sarcastic, please do a search on 'alphaone' for another thread we were discussing :)