cengland0 (2/10/2012)
Someone mentioned in another article that all you need to do is run a trace and you can get all this information. So, should the hashing be done on the application side to prevent this type of password retrieval with trace on?
In general, you simply have to choose how hard you want which potential adversaries to work using which means.
I would say hashing should be done on the application side at this point, because
A) SQL Server does not provide us modern hash algorithms (i.e. the SHA-2 family; SHA-512, SHA-256, SHA-384, Whirlpool, the SHA-3 finalists, etc.)
B) SQL Server does not provide us with an implementation of PBKDF2; even the SHA-1 only version the .NET framework gives us
C) Conditional: When a single SQL Server instance is serving multiple client machines, loading SQL Server up with hundreds of thousands (or more) of hash iterations in order to allow a reasonable measure of security for users who use passphrases/passwords with a smaller total keyspace may end up putting more load on the CPU of the SQL box than is desirable
C1) Do you really want to try to use GPGPU computation on a SQL Server instance from inside SQL?
Raghavendra Mudugal (2/10/2012)
I thought SALT is fixed static string in the encrypted SP... you dont need to expose the SALT string as open parameter value, that needs to be kept safe. and on the password use the same concept what you are using now... SALT'ing is just added feature to HASH'ing. Let DB things remain on the DB side, if you want use something more on UI level, you can use any encryption concept besides HASH'ing.
Adding a salt in and of itself is merely a device to 1) prevent the trivial identification of the same cleartext (i.e. hash A5BC is present in rows 5, 15, 33, and 114; they have the same cleartext value!) and 2) render more difficult precomputed dictionaries.
Using a fixed static string completely precludes reason 1) as the same cleartext + the same salt = the same hash, and nearly completely undermines reason 2), since once an attacker figures out the fixed single salt, they can proceed with precomputing a massive dictionary, and the result takes up the same space (and takes the same amount of time) as it would have without any salt at all.
Salts need to be significantly long and completely random; feel free to add _more_ content, but the useful core of it is a set of random bytes of significant length.