使用mcrypt或GnuPG存储信用卡详细信息

Question

I have a requirement to store credit card details (not storing is NOT an option).

Using mcrypt with mcrypt_dev_random to generate init_vector takes varying ages to encrypt/decrypt but seems is the most 'secure' option. mcrypt_dev_urandom MUCH quicker but not suitable for long term storage - as I have read.

Looking at GnuPG as a possible alternative and would like some opinions/heads up on these if possible.

Answer 1

If you really want to store credit card information securely, there's a standard for it: Payment Card Industry Data Security Standard . And it's a lot more involved than using one specific encryption algorithm. It requires you to store parts of the card details on two physically separate machines, among many other things. And even if you follow the PCI standard to the letter, experts argue you're still not entirely secured. Anything less than that is pretty much not worth discussing in detail, since the overall level of security is so low that it hardly makes a difference.

Answer 2

Remember: the First Rule of Cryptography is "don't do it yourself".

MCRYPT_DEV_URANDOM is enough for robust encryption , but "managing credit card information" is a much more complicated affair than simply " encrypt 'em all and let God sort out His own ".

That "not storing is NOT an option" sounds to me as if you (or better, those above you ) Are Doing It Wrong. You should not be researching this, or be the one to propose a solution. Do not be the fall guy.

https://www.pcisecuritystandards.org/merchants/how_to_be_compliant.php

Answer 3

For you the most important question is, what you need for PCI compliance. Don't produce some homebrew encryption. Read up on what it requires, and preferable delegate the credit card stuff to a specialized payment processor.

Using mcrypt with mcrypt_dev_random to generate init_vector takes varying ages to encrypt/decrypt but seems is the most 'secure' option. mcrypt_dev_urandom MUCH quicker but not suitable for long term storage - as I have read.

This shows some misunderstandings. For one an IV doesn't need to be secret. The quality of random numbers is less important.

But even for keys, /dev/urandom is good enough, provided it was seeded with sufficient entropy initially.