Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #4746 > unrolled thread

storing credit card data

Back to article view | Back to comp.programming

Contents

  storing credit card data b <mike7411@gmail.com> - 2014-09-04 22:05 -0700
    Re: storing credit card data Robert Wessel <robertwessel2@yahoo.com> - 2014-09-05 01:51 -0500
      Re: storing credit card data Mark Carroll <mtbc@bcs.org> - 2014-09-05 08:26 +0100
        Re: storing credit card data "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-05 12:41 +0100
          Re: storing credit card data Mark Carroll <mtbc@bcs.org> - 2014-09-05 13:08 +0100
            Re: storing credit card data "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-05 16:16 +0100

#4746 — storing credit card data

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?

[toc] | [next] | [standalone]

#4747

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.pcicomplianceguide.org/

https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf

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

[toc] | [prev] | [next] | [standalone]

#4748

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

[toc] | [prev] | [next] | [standalone]

#4749

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

[toc] | [prev] | [next] | [standalone]

#4750

"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

[toc] | [prev] | [next] | [standalone]

#4751

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 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web