Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)

i would recommend
dont publish in HTML/JS as with a simple View Page Source any browser client can figure out what is doing what
also i would shy from Scripting macro languages as they are not compiled modules and anyone with a text editor can easily see your code
Functions and procedure are another story as one would need DB access to view..so someone who is doing
a simple query with Toad or sqlplus suddenly sees this interesting procedure hmm..

can the more proprietary routines be placed in a compiled language like Java and then use PL/Java packaging to pull in the packages you need?
?
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.

> CC: pgsql-general(at)postgresql(dot)org
> From: cshobe(at)bepress(dot)com
> To: xof(at)thebuild(dot)com
> Subject: Re: Obfuscated stored procedures (was Re: [GENERAL] Oracle and Postgresql)
> Date: Thu, 25 Sep 2008 16:38:18 -0700
>
> On Sep 25, 2008, at 1:16 PM, Christophe wrote:
> > Without getting into the argument as to the level of security
> > provided, it strikes me that a reasonable approach would be a non-
> > core pluggable language which accepts encrypted strings as
> > functions, decrypts them (using a key compiled into the language
> > module), and passes them on to PL/pgSQL for execution.
>
> The only way this could work is if the key is set at compile time.
> Using a single key is impossible in an open source product as Greg
> pointed out, and very stupid in any other. Now I'll ignore the fact
> that you can reverse engineer the key out of compiled code, as you
> already acknowledged that - this is still problematic for another
> reason.
>
> Let's consider the original goal of "I want to keep customers, with
> full control of the server machine, from being able to see clearly
> what a function does". In cases where you just want to keep database
> users from seeing a function code, the implementation should be easy,
> and that's the only form I see any value in adding, really.
>
> You could add encryption properly by storing the key in an external
> file with very restrictive permissions, and that would solve the goal
> of "I don't want people to be able to read function code in pg_dump
> output", etc., so it takes things a step farther. But of course on
> customer-controlled boxes, they can read any file they want, defeating
> the encryption.
>
> So you think "ah I'll just compile it in by requiring ./configure --
> key=whatever to compile the thing. Well, now you suddenly have to
> build every release of PostgreSQL for every single one of those
> customers - they cannot upgrade or rebuild themselves, without losing
> all the encrypted functions. Maybe that's something you can accept,
> but I would say that most people who want to hide code from customers
> want nothing to do with setting up the database for the customer. In
> cases where you fully dictate the PostgreSQL build and upgrade policy
> and mandate it for your clients, this could work, but I'm guessing
> that's a pretty esoteric corner case.
>
> Cheers,
> --
> Casey Allen Shobe
> Database Architect, The Berkeley Electronic Press
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

_________________________________________________________________
Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie.
http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008