This sounds great until something doesn't work properly.
Bet it's difficult to toubleshoot. Has this setup given you any problems in that regard? Jared On Tuesday 18 December 2001 16:25, Austin, Steve S wrote: > What we do is have the application manage the encryption keys. The DBA > therefore only has access to the encrypted data. Being the DBA in this > equation, I am exonerated from having easy access to the keys, and > therefore exonerated when it comes time to hunt down perpetrators (well, > nearly!) :). I further suggested that they split the key into parts and > allow the DBA, root, and the application owner to put in parts to derive > the actual key that is not stored anywhere, but exists only in the memory > of the app. This did not go over well. :) We're also looking at > procedures to change the keys, since any set of encrypted data is a target, > and if you change the keys, it's a "moving" target. > > hope this is interesting if not amusing. > sa > > -----Original Message----- > Sent: Tuesday, December 18, 2001 3:55 PM > To: Multiple recipients of list ORACLE-L > > > Believe it or not Jared, one of your script gave me following idea (the > wrapper sql for decrypt/encrypt on your site). > > 1. I have a system users table, I can add a column to store user's key in a > column that only that user has access to. > 2. Create a DBA owned package to handle encryption/decryption. > 3. The key will be picked up in this package and used (maybe I'll use user > key is used to derive the actual key). > 4. The package will be deployed as 'wrapped' in production, so by looking > at dba_source you won't find much. > > I'll have to test this though but I think this will make it a bit more > secure. > > The question is "Can I trust myself?" The answer is 'Yes". > > Can someone see any drawbacks? > > Raj > ______________________________________________________ > Rajendra Jamadagni MIS, ESPN Inc. > Rajendra dot Jamadagni at ESPN dot com > Any opinion expressed here is personal and doesn't reflect that of ESPN > Inc. > > QOTD: Any clod can have facts, but having an opinion is an art! -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
