|There's more than one way to do things|
Re: Storing credit card numbers temporarily (OT)by phroggy (Monk)
|on Aug 14, 2005 at 03:23 UTC||Need Help??|
The way I see it, you've got three basic options:
If you store it server-side, you can add it to an SQL table with an expiration time, and periodically DELETE FROM Table WHERE expiration<NOW(). Since it's important for security reasons that the information actually be deleted, I'd suggest doing this from an hourly (or more frequent if you'd like) cron job. Note that if the cron job runs immediately after the user clicks Preview, that's OK, because the expiration time will be some point in the future.
In either case, you can obfuscate the number somehow, to make it non-obvious if anyone should stumble across it somehow.
Your third option would be to encrypt the number, store the encrypted form on the server as described in #1, and send the (randomly generated) decryption key to the client (via a hidden form field as described in #2). If someone hacks the server, the encrypted numbers are useless without the key, and if someone hacks the client, the key is useless by itself. I've never done something like this, but I'm sure someone else here has suggestions for implementations.
Although the cron job I suggested in #1 is still a good idea for #3, it wouldn't be absolutely required. I'd just add the delete query at the beginning of each script that accesses the database, so as long as the site is being actively used, old data is getting deleted periodically.
Do you actually have an official policy that says you won't store credit card numbers? Check the wording on that. How hard would it be to revise?
Personally, I'd recommend option #2.
perl -e '($,,@_)=("er",",\n","l Hack"," P","Just anoth"); print reverse @_;'