Well, IMHO there's only one way to make it almost secure: Don't store the cc numbers unencrypted. The user should log-in with a password. Don't store the password, just a hash-value to proof the password valid.
Encode and store the sensitive data with that password. Use a second password (don't store it either) and a second encrypted field if a second group need to see that number. Whatever happens to the data. A third person cannot read it. -- Bernd ----- Original Message ----- From: "David T-G" <[EMAIL PROTECTED]> To: "mysql users" <[EMAIL PROTECTED]> Sent: Sunday, December 01, 2002 6:42 PM Subject: protecting ccard numbers > -----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 > --------------------------------------------------------------------- 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
