[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming

storing credit card data

mike7411@gmail.com

9/5/2014 5:05:00 AM

What is the best way to store credit card data locally in an app?

You will almost certainly want to use some type of encryption, but in the most obvious way you will have the key stored in the program. This seems like a locked house where the key is right next to the door - not very secure.

Any ideas how to make this secure?
5 Answers

robertwessel2@yahoo.com

9/5/2014 6:51:00 AM

0

On Thu, 4 Sep 2014 22:05:06 -0700 (PDT), b <mike7411@gmail.com> wrote:

>What is the best way to store credit card data locally in an app?
>
>You will almost certainly want to use some type of encryption, but in the most obvious way you will have the key stored in the program. This seems like a locked house where the key is right next to the door - not very secure.
>
>Any ideas how to make this secure?


Best answer is *don't*, unless you absolutely have to. And if you
have to, follow the PCI DSS standards and advice. Start here:

https://www.pcicompliance...

https://www.pcisecuritystandards.org/pdfs/pci_fs_data_s...

This is *not* an area where you want to wing it.

Mark Carroll

9/5/2014 7:26:00 AM

0

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Thu, 4 Sep 2014 22:05:06 -0700 (PDT), b <mike7411@gmail.com> wrote:
>
>>What is the best way to store credit card data locally in an app?
>>
>>You will almost certainly want to use some type of encryption, but in the most obvious way you will have the key stored in the program. This seems like a locked house where the key is right next to the door - not very secure.
(snip)
> Best answer is *don't*, unless you absolutely have to. And if you
> have to, follow the PCI DSS standards and advice.
(snip)

Good suggestion. I worked on a project that achieved PCI compliance.
In that particular instance, the encryption key is not stored in the
program itself. Into the running program multiple users, authenticated
by their own cryptographic keys, each enter their own "part" of the
encryption key for the credit card data, and the software then combines
them and holds it in RAM only while it is actually running; also, if it
is suspected that some part of the key might have been revealed, it is
easy to generate a new key whose parts are distributed to those users,
and a re-encryption of the whole database then proceeds. (The users
interact with the program via a web interface so OWASP recommendations,
etc., were also important.)

-- Mark

Chris Uppal

9/5/2014 11:42:00 AM

0

Mark Carroll wrote:

> the encryption key is not stored in the
> program itself. Into the running program multiple users, authenticated
> by their own cryptographic keys, each enter their own "part" of the
> encryption key for the credit card data, and the software then combines
> them and holds it in RAM only while it is actually running;

Better not to keep sensitive data in RAM if possible. At minimum encrypt
(actually more like obfuscate) and scatter the data around the address space,
or better wipe it and release the memory (to be regenerated later if there is
need).

System administrator should not be able to get at the data easily (why should
sysadmin know my credit card details ?). Person pulling hard disk and reading
swap space should not. Person at other end of malicious net connection (think
Heatbleed) should not.

-- chris

Mark Carroll

9/5/2014 12:09:00 PM

0

"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> writes:

> Better not to keep sensitive data in RAM if possible. At minimum encrypt
> (actually more like obfuscate) and scatter the data around the address space,
> or better wipe it and release the memory (to be regenerated later if there is
> need).

Naturally, you can't wholly wipe the decryption key from RAM unless you
want the administrators to have to re-enter it for every new transaction
that the system has to process. Not having it lying around in RAM in
plain form is a good point though; the PCI compliance people didn't
mention the possibility of obfuscating it. Perhaps a more transient kind
of data that was of interest is the card security code used in online
transactions, especially as for compliance we were not permitted to
store those (beyond, say, as required for retrying a transaction).

This does raise the point that, especially with garbage collectors and
virtualization and suchlike, I found that many programming languages do
not make it easy to write portable code to allocate unswappable memory
that you can be sure of successfully wiping without leaving any copies.

-- Mark

Chris Uppal

9/5/2014 3:17:00 PM

0

Mark Carroll wrote:

> Perhaps a more transient kind
> of data that was of interest is the card security code used in online
> transactions, especially as for compliance we were not permitted to
> store those (beyond, say, as required for retrying a transaction).

Sounds good.


> This does raise the point that, especially with garbage collectors and
> virtualization and suchlike, I found that many programming languages do
> not make it easy to write portable code to allocate unswappable memory
> that you can be sure of successfully wiping without leaving any copies.

As far as I know /no/ language allows you to write portable software that uses
reliably unswappable memory -- Windows just doesn't have the feature in a form
that actually, always, works (unless things have changed in the last few
versions of Windows).

-- chris