Encryption problem

I use keyword WITh ENCRYPTION to encrypt my procedures that other users can'
see them.
For example:
CREATE PROCEDURE test
WITH ENCRYPTION
AS
select 1
GO
If I click on this procedure in enterprise manager, I get message:
Error 20585:[SQL-DMO]/*****Encrypted object is not transferable,and script
can not be generated.*****/
Everything is fine so far.
But if I go to master database I can find the sintax of this procedure.
For example, if I use RedGate SQL bundle to compare 2 databases, I can see
the sintax of all procedures on some database even if they are encrypted.
Is there any way to prevent other users to see my code?
If I sell my program with my database to other company, every one who has
access to their database, can see my code and still it.
Any suggestion?
Thank you,
SimonThe WITH ENCRYPTION option only provides a trivial level of security. You ma
y
find other third-party tools that claim to do better but ultimately you
cannot stop an administrator using SQL Profiler to examine your code.
IMO you should not try to hide code in this way. Admins may have a
legitimate need to see what code is running. The best protection for your
intellectual property is a licence agreement, not phoney and obstructive
encryption. Just my opinion.
David Portas
SQL Server MVP
--|||Simon even with encryption there's plenty of tools on the web that people ca
n
use to decrypt it. All that I can say is implement physical security - ie.
Memory stick
and get your DB to sort out security issues. If you have an extra hour a day
for admin you can always use sourcesafe.
As for the code sitting in the database, your never safe. There's no IP
(Intellectual Property ) when you are working for a company, they pay you
thus they own everything you create during work hours.
You can write manual encryptions by putting your code in extended procs, and
atleast like this you remove the google junkies from your code. Just google
"sql decryption tools" .
With dlls it's a bit more difficult to see the code, although someone can
still just catch the code through profiler...
No that I think of it, if you don't have the DBA on your side your "￡$*￡$
"simon" wrote:

> I use keyword WITh ENCRYPTION to encrypt my procedures that other users ca
n'
> see them.
> For example:
> CREATE PROCEDURE test
> WITH ENCRYPTION
> AS
> select 1
> GO
>
> If I click on this procedure in enterprise manager, I get message:
> Error 20585:[SQL-DMO]/*****Encrypted object is not transferable,and script
> can not be generated.*****/
> Everything is fine so far.
> But if I go to master database I can find the sintax of this procedure.
> For example, if I use RedGate SQL bundle to compare 2 databases, I can see
> the sintax of all procedures on some database even if they are encrypted.
> Is there any way to prevent other users to see my code?
> If I sell my program with my database to other company, every one who has
> access to their database, can see my code and still it.
> Any suggestion?
> Thank you,
> Simon
>
>|||The text of encrypted procedures does not show up in SQL Profiler. That's
one of the reasons I dislike encryption, because it make debugging and
performance tuning a real hassle. But I agree with the rest of your post.
Jacco Schalkwijk
SQL Server MVP
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:C451F175-1594-4DBC-AE84-24779EC8ABFF@.microsoft.com...
> The WITH ENCRYPTION option only provides a trivial level of security. You
> may
> find other third-party tools that claim to do better but ultimately you
> cannot stop an administrator using SQL Profiler to examine your code.
> IMO you should not try to hide code in this way. Admins may have a
> legitimate need to see what code is running. The best protection for your
> intellectual property is a licence agreement, not phoney and obstructive
> encryption. Just my opinion.
> --
> David Portas
> SQL Server MVP
> --
>|||Thanks for the correction Jacco. Actually I've not even tried Profiler with
encryption -I just unwisely made an assumption. Sorry Simon. Another reason
to avoid encryption though.
David Portas
SQL Server MVP
--|||just an addition, it'd show up as *encrypted* only after you have sp3
installed. so, you'd see the entire text if you're running earlier bits.
-oj
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid> wrote
in message news:%23blcesxSFHA.3636@.TK2MSFTNGP14.phx.gbl...
> The text of encrypted procedures does not show up in SQL Profiler. That's
> one of the reasons I dislike encryption, because it make debugging and
> performance tuning a real hassle. But I agree with the rest of your post.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
> news:C451F175-1594-4DBC-AE84-24779EC8ABFF@.microsoft.com...
>|||>> No that I think of it, if you don't have the DBA on your side your "$*$
What do you mean by this?
Thanks
"Mal .mullerjannie@.hotmail.com>" <<removethis> wrote in message
news:99588A6B-5C8A-4A2A-B64C-65A5139EDD1A@.microsoft.com...
> Simon even with encryption there's plenty of tools on the web that people
> can
> use to decrypt it. All that I can say is implement physical security - ie.
> Memory stick
> and get your DB to sort out security issues. If you have an extra hour a
> day
> for admin you can always use sourcesafe.
> As for the code sitting in the database, your never safe. There's no IP
> (Intellectual Property ) when you are working for a company, they pay you
> thus they own everything you create during work hours.
> You can write manual encryptions by putting your code in extended procs,
> and
> atleast like this you remove the google junkies from your code. Just
> google
> "sql decryption tools" .
> With dlls it's a bit more difficult to see the code, although someone can
> still just catch the code through profiler...
> No that I think of it, if you don't have the DBA on your side your "$*$
> "simon" wrote:
>sql