| Subject | Re: [firebird-support] Field level encryption with UDF? |
|---|---|
| Author | Lee Jenkins |
| Post date | 2009-05-06T16:50:41Z |
Myles Wakeham wrote:
for longer than required for essential business purposes. For instance, what we
do is run the CC trans and keep the cc number in database using strong
encryption app level. Then when we need to batch the post authorizations
(including any tips given to employees) for our sales (we use pre-auth/post-auth
model) we pull the data from the database one-by-one and decrypt it to send back
for the POS auth. At the end of each day, we automatically purge the the
encrypted credit card data from the database.
Many software middlewares (a la PCCharge) for cc processing are starting to use
reference numbers so there is no need to keep the cc number for doing "follow
on" transactions, you simply refer to the reference number of the original
transaction.
If you encrypt database level, you're still sending unencrypted credit card data
over the network and that is a no no as well. Better to use App level
encryption (easier to do, IMO) and better security.
use the credit card number. PCI says that you can store credit card numbers
indefinitely if everything but the first 4 and last 4 digits are masked. These
are what you should be using in your reporting.
HIH,
--
Warm Regards,
Lee
>First, be aware that PCI/DSS dictates that you not retain credit card numbers
>
>
> I have a Firebird 1.5 database that has a table for storing credit card
> numbers. In accordance with PCI compliance on credit card handling
> regulations, I need to restrict access to this information on a
> 'business need to know' basis. I can do most of that with user level
> security, etc.
for longer than required for essential business purposes. For instance, what we
do is run the CC trans and keep the cc number in database using strong
encryption app level. Then when we need to batch the post authorizations
(including any tips given to employees) for our sales (we use pre-auth/post-auth
model) we pull the data from the database one-by-one and decrypt it to send back
for the POS auth. At the end of each day, we automatically purge the the
encrypted credit card data from the database.
Many software middlewares (a la PCCharge) for cc processing are starting to use
reference numbers so there is no need to keep the cc number for doing "follow
on" transactions, you simply refer to the reference number of the original
transaction.
If you encrypt database level, you're still sending unencrypted credit card data
over the network and that is a no no as well. Better to use App level
encryption (easier to do, IMO) and better security.
> However I have a specific need to offer key users the ability to produceNo on should really have access to credit card numbers unless they are going to
> reports using Crystal Reports or other 3rd party reporting tools
> directly against the database tables. The data that is needed to be
> secured is (unfortunately) a part of a table that needs to be exposed
> for the reporting requirements. So I was thinking of storing the data
> in an encrypted form, so that it is only visible when run through a
> decrypter in my application.
use the credit card number. PCI says that you can store credit card numbers
indefinitely if everything but the first 4 and last 4 digits are masked. These
are what you should be using in your reporting.
HIH,
--
Warm Regards,
Lee