Re: Obfuscated stored procedures (was Re: Oracle and Postgresql) - Mailing list pgsql-general

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@postgresql.org
> From: cshobe@bepress.com
> To: xof@thebuild.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@postgresql.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. Learn Now