PHP-Extension - [PHP's] mcrypt_encrypt() vulnerabilities

I have someone that wants to start storing the BIN (Bank Identification Number) which is the first 6 digits of their customer's encrypted credit card number. They want the BIN unencrypted though for quick lookups with fraud detection services.

However, I have read that certain encryption schemes are vulnerable if the first few chars of the encrypted string are available to allow analysis of the encrypted string. To top it off, in another part of the database they already store the last four digits unencrypted so that they can do quick lookups of past transactions.

Separate of storing the full number, these are not a security risk, but I do not want to put my client's customer's at risk by using the wrong encryption scheme that could be easily hacked by making available the first 6 and last 4 numbers of the encrypted string.

Currently they are using MCRYPT_BLOWFISH with MCRYPT_MODE_CBC. Should I recommend they re-encrypt under something else?

Storing any credit card information on a web server, is extremely risky. Doing so actually violates the agreement for vendors to offer credit card payment. The major credit card companies have rules in place, that expose the vendor to massive fines and liability if they violate the terms for handling such data as set forth in the agreement.

For one, they do not a allow storing of credit card information encrypted or not on any computer directly connected to the internet.

The amount of money we are talking about here is more than you are likely to see in your entire lifetime, especially if there is a security breach. To say that it's not recommended is putting it lightly.

If that were the case then why does Amazon.com openly show that they store credit card details from past purchases. You can even select which past card you want charged without even entering the card number again. It's not just them. I have seen dozens of major sites that do this. How is it they are not being fined for such blatant storage?

According to Visa and MasterCard's PCI Data Security Standard Compliance requirements you can in fact store credit card numbers so long as they are stored under strong encryption or in a truncated format.

In fact, if you check further you will find that even as of last year major credit card companies required that those numbers be stored! It is only recent that the allowance of storing those numbers in truncated form was added to the compliance standards.

There are even services available from third parties you can also pay to store the credit card data to drastically reduce your liability should something go wrong. But, regrettably, the company I am doing this work for doesn't use one of those services soooo....I still need to know what encryption method is best.

I'm pretty certain that amazon breaks the rules on purpose, But they have the money to pay the fines, and its worth it to them.

Amazon has their own servers and their own security staff to handle the technical requirements.



The network requirements as set forth in section 1.1 of PCI are beyond what you could get with any hosting plan even with a dedicated machine. It isn't just the machine itself but the network, the password maintenance and the manpower to administer it.



A payment gateway is a much better solution. Suit yourself but even the developer of an application that causes theft will be liable.

Thread moved from PHP to Security/Cryptography ... while you're using PHP's mcrypt_encrypt, you're generally talking about security practices and the vulnerability of Blowfish, which is not PHP specific.

A PHP related question would generally discuss the syntactic use of mcrypt_encrypt, so please feel free to start another thread in the PHP forum and reference this one as background information when you get to that point.


My opinion on the subject ... the larger companies like Amazon probably have a database security specialist, a web server / operating system specialist, and a network security specialist (at least) to handle their security, so you're in over you're head unless you're all of these things. So find these people and employ them contractually for this project and pass the costs on to your customer. If you're customer's not willing to pay for this expertise, then they have no business storing this information.

You can be sure that Amazon has several networking specialists and several serious security folks. Its a cost of doing business for them.

Storing any of the PAN (personal account number, aka credit card number) on a server on the Internet is a really bad idea. Encrypted or not.

It makes your server have valuable data, which makes you more likely to be attacked. This is not about virus and spam, its about money.

Storing the leading digits only is less dangerous, but still not a good idea.

If you store any valuable data enciphered, where do you store the key? The answer to this is far more important than which cipher you use, DES, AES, Blowfish, etc.

If you store the key on a disk in your server, the bad guys will find it and all of your security is gone. You would be amazed at the number of folks who should, and sometimes even do, know better than store the key somewhere safe like /etc or /var

Please explain.

I know the current configuration re-encrypts everything using a key the administrator has to manually enter each time, so it isn't stored except in that person's head. The data is therefore only encrypted with a locatable key on the server for the 6 or so hours until the new key is entered for re-encryption by one of their corporate officers. I also know they wipe the card data entirely at regular intervals when all potential charges to the card holder are complete. There just isn't any need to hold onto the data outside of the transaction id after that point according to their business needs.

Oh, if this setup requires a human to enter a key every time the server starts, that is much better. Most sites don't want to do that, especially if the server is in a lights-out data center without 24x7 staffing.

For the paranoid, VeriSign and RSA offer key fob devices that let you enter different keys each time, so that you are safe from replay attacks.