SathishK (2/10/2012)

---

Raghavendra Mudugal (2/10/2012)

---

cengland0 (2/10/2012)

---

Raghavendra Mudugal (2/10/2012)

---

cengland0 (2/10/2012)

---

Steve Jones - SSC Editor (2/9/2012)

---

SELECT HASHBYTES( 'SHA1', 'R@nd0m' + Pwd + firstname)

FROM Employees

In this case, without access to the code, it becomes hard to determine what the input values for the hash function are.

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?

just a thought - if that SP is encrypted then finding that in the TRACE is not possible (not sure if secured info are generally passed in the plane SQL statements.

So you're saying to put the query into an encrypted stored procedure to avoid the trace from getting the passwords? How do you pass parameters to that stored procedure? Wouldn't you do something like:

EXEC sp_somestoreprocedure('salt','password')

Couldn't that command be captured by the trace?

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.

Simply get the hashed(and salted) password from DB to the application. .