On Sun, 1 Dec 2002, David T-G wrote: > Date: Sun, 1 Dec 2002 18:42:03 -0500 > From: David T-G <[EMAIL PROTECTED]> > To: mysql users <[EMAIL PROTECTED]> > Subject: protecting ccard numbers > One way would be to encode the credit card number field using data from an external file for the key and then backup that file separately from the general backups. Then having the backups w/o the key would be relatively safte from the fourth problem. You could also programatically protect the credit cards since even if they could see the field, the information would be protected.
Protetion against hacker is another problem since with root access they could see the program, the database and the key, although they shouldn't be together. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, all -- > > I'm exploring some software for a client and I expect to need to store > credit card numbers in the system.* How to do it safely, though? > > It seems to me that we have four levels of security at hand: the local > employee who should be working with the data at all, the local employee > who shouldn't see these numbers, the remote hacker who wants to break in > and get all of the data, and the backups. > > The first should be simple; with careful grant privs, those who shouldn't > be able to access the card numbers can't, and those who should can. > We'll come back to this in a minute. > > The second should be even simpler; if you're not supposed to see any of > the data, then you don't get an account. > > The third won't be a problem immediately, since they're starting out with > just an internal server for their system. Maybe we'll never expand to a > public interface; who knows. But it would be good to plan for it. > > The fourth is something of a problem, since if you can get the backups > you can recreate the database and you have it all. My current thought is > a mysqldump through pgp with the private key somewhere else. More input > it welcome. > > So we're back to the first case: there are those who should be able to > see this data and those who can't. Would it be better (and less prone to > error or elevation hacking) to put the card numbers in a separate table > and reference it? Maybe with another table that maps customer IDs to > card IDs so that there isn't even a pointer reference in the customer > table? > > And what about the hacker problem? Should I encrypt the card numbers in > the system? If so, how can they be decrypted for those who *should* see > them without also storing the key somewhere that a hacker could get? > > This whole thing is just a concept at the moment; they're interested in > the idea of moving away from paper (yes, *paper* -- for everything!) > but neither have wads of cash to throw away nor embrace change. Here's > hoping, though ;-) Not only does the project in general have me quite > interested, though, but this aspect of it is *very* interesting. Any > pointers, tips, "we-did-it-this-way"s, or other advice (and discussion) > is very much appreciated. > > * Background: This is a spa-like studio and they take private session > reservations with a ccard and then bill the card if you fail to show, > not unlike hotels do. AFAIK they retain card numbers long-term for > customer convenience (heh -- and their own, as we all truly know) and > so I can't store them in a non-backed-up, one-time-pad table or some > such. > > > TIA & HAND > > mysql query, > :-D > - -- > David T-G * There is too much animal courage in > (play) [EMAIL PROTECTED] * society and not sufficient moral courage. > (work) [EMAIL PROTECTED] -- Mary Baker Eddy, "Science and Health" > http://www.justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg! > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (FreeBSD) > > iD8DBQE96p5LGb7uCXufRwARAqn8AKCK/0eaW101RoeoBPvEh98A3Pt2vQCg3OR1 > JmBcK1On5vqTGrBreIcRV+k= > =Qv39 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > Sincerely, William Mussatto, Senior Systems Engineer CyberStrategies, Inc ph. 909-920-9154 ext. 27 --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
