August 29, 2001 at 8:56 am
I am writing some stored procedures and want to encrypt the code. I am using the "With Encryption" command. Are there any available tools that would allow prying eyes to decrypt and see the code?
August 29, 2001 at 9:08 am
i've not heard of any "tools" as such but the encryption algorithm for version 7 and 6.5 are pretty straightforward to crack. 2000 uses a different encryption algorithm and has not been cracked as yet , but i think its just a matter of time before thats done
hope that answers your questions
August 29, 2001 at 5:56 pm
I'd agree with that - encrypting is only going to deter the casual snoopers. To me thats usually more than good enough. One of the reasons stored procs are so valuable is that you can adjust them without recompiling an app - using encryption prevents that. I'd have a hard time buying an app that used this. If you've got super proprietary logic, I'd think a better place would be a middle tier COM piece.
Andy
September 5, 2001 at 6:52 am
Actually there is a app that will decrypt sql2000 goto http://www.geocities.com/d0mn4r/
Rob
September 5, 2001 at 10:29 am
I've had a sproc that will decrypt SPs, triggers, views, etc.
It is a deterrent, but not follproof. A good DBA and compentent Internet snooper will crack the code.
Steve Jones
September 5, 2001 at 7:42 pm
Robert,
I took a look at the util you referenced - it successfully decrypted a proc encrypted in SQL2K. According to the help file, encryption is stronger in SQL 2000 than in SQL 7 owing to how the key is created and that you have to be a member of sysadmins. I didn't test further. Clean install, single exe.
Andy
December 8, 2002 at 4:52 pm
quote:
I am writing some stored procedures and want to encrypt the code. I am using the "With Encryption" command. Are there any available tools that would allow prying eyes to decrypt and see the code?
There are scripts posted on this site that allow you decrypted encrypted views and procs. You should consider "with encryption" basically one line of defense in your security arsenal. Controlling who has access to all the 'sys..' tables and objects is another. You might want to lock down the system tables and the master, msdb and temp databases against prying "eyes."
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply