Re: how do I protect/encrypt sensitive data in a database?

> I meant that root (or someone with root access) couldn't just connect to the > db and start doing SELECT's and stuff. Obviously I can't control every > scenario, and I agree that if people are this dishonest, I would bail. I'm > talking about normal circumstances.. for example, say someone is using > PHPMyAdmin (web based program) and accidentally clicks on the 'options' > database and sees the list or something like that. That's good. It's much easier to keep honest people honest. > Linux box, Apache, openSSL planned, but it's a switched, proxy, intranet, so > sniffers are probably unlikely. And I also won't be storing names, so people > will just be numbers -- hard to know who is who then. It sounds like all you'd need is to do a basic security audit & you'd be fine. > I guess after thinking more about this, I'm wondering if I can do something > like (pseudo - code): [...] > The documentation on the Encode/Decode() functions is vague at best and > implies it only works on strings, but doesn't expand upon what a string > _really_ is IYKWIM. Is there any reason why you don't want to use strings? It would seem to me that DECODE()/intval() would work just as well for your purposes. > > A perusal of RISKS Digest (anyone doing security should subscribe > > to BUGTRAQ and RISKS Digest) > > I'm on BUGTRAQ, what is the url/email for RISKS? And what does that list > talk about? "Forum On Risks To The Public In Computers And Related Systems" All sorts of interesting stuff is discussed there, ranging from problems caused by shortsighted design ("Oh, who'd ever try doing *that*") or restrictions (e.g. company/government policy preventing the safe choices) to disasters caused by poor design or QA. I particularly like the articles about unforeseen interactions, as it really highlights how you have to handle things you might not think are even possible. Reading RISKS for a few months should help anyone become a better systems designer just by highlighting the sorts of things that happen in the real world. Date: 13 Dec 1999 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Also, new AUSTRALIAN archives at http://mirror.aarnet.edu.au/risks/ and http://the.wiretapped.net/security/textfiles/risks-digest/ . PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .