On Fri, 17 Feb 2006 18:07:36 +0100, Mark A. Parsons <user@example.net>
wrote:

> 2 - incorporate an encryption/hash key into the source code of the proc;
> would be a little tricky ... basically something like ... generate hash
> key and/or encryption signature for source code file (eg, my_proc.sql),
> embed hash key/encryption signature in source code (as a T-SQL comment),
> load code into dataserver; (keep hash key in a secure location
> somewhere); to check the hash code, extract source from syscomments,
> remove hash key, rebuild my_proc.sql, generate new hash key, see if new
> key is same as 'old' key kept in your 'security location'; (sounds nasty
> but very doable with some scripting); 'course, how do you keep your
> master set of keys (in that 'secure location') intact, ie, how do you
> make sure they are not modified by devious dude(tte), ie, same 'problem'
> of how do you normally maintain security codes/passwords/passphrases

I don't see the need to store the hash value somewhere in the database
itself. You could as well just hash the procedure before creating it on
the database and store that hash in a secure location. Then later extract
the source code from syscomments, hash again and compare to the previously
calculated hash.

Jochen