Using WITH ENCRYPTION

  • Anyone have any idea of the performance overhead of having all stored procedures and triggers created with the "WITH ENCRYPTION" option? We've got close to 1000 stored procedures per database on production (SQL7, SP4 envirionment).

    I'm sure there's got to be some overhead associated with this, but I'd really like to determine how much.

    Thanks in advance.

  • Haven't got a clue about performance.

    But I suppose that SQL Server cashes the (decrypted) SP in memory.

    If performance is an issue for you, remove the WITH ENCRYPTION option. As stated before all around, the encryption is very weak and a bunch of tools exist to decrypt the stuff.

    If there is anyone who has access to the server and has the intent to get to the procedure, they will surely know how to break it.

  • Thanks for the reply.

    Yup, I know that encryption is easily breakable, however it does provide a "front line" against the casual observer going in an messing with it. When we deploy our software, these stored procedures/triggers are a pretty core piece of our code base. Supporting the beast can become a nightmare, even more so, if I've got customers "fixing" or "testing changes" in the code (it's a lot easier to change something through EM than it is to DECRYPT and then re-rerun the oject against the db)

    I'm not gonna prevent someone that is DETERMINED to get in there, but a small defense on the front side goes a long way.

    But, if this small defense is causing a bottleneck in our systems, then I may have to trade evils...

  • That's the reason the WITH ENCRYPTION is provided, I guess. Tried some queries on google, but couldn't come up with anything useful.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply