Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Mark Carroll Newsgroups: comp.programming Subject: Re: storing credit card data Date: Fri, 05 Sep 2014 13:08:47 +0100 Organization: none Lines: 22 Message-ID: <87ppfab774.fsf@ixod.org> References: <9854dc17-9c12-403f-8115-409a7bcdc77e@googlegroups.com> <87r3zqmstj.fsf@ixod.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx05.eternal-september.org; posting-host="1b3e5cba9e4d07a53741e6f3d1717925"; logging-data="12301"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/h+EdRKpXjZ8IaM9TiTIMd" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Cancel-Lock: sha1:lPn2/QP3vt2uIy4KiKJcdB1USQI= sha1:IXEFXDDA4ftQzqix3aMRwc25GsM= Xref: csiph.com comp.programming:4750 "Chris Uppal" 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