February 9, 2012 at 5:31 am
Thanks for the question. Hoever, I got it wrong because I used this source:
http://msdn.microsoft.com/en-us/library/cc837966(SQL.100).aspx
which says:
"It is not possible to specify the salt value in SQL Server."
Can someone please expain why this is wrong? Or why I have interpreted it incorrectly. Thanks!
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
February 9, 2012 at 5:33 am
GPO (2/8/2012)
The SALE string? This confused me! 😛
Yeah, I decided SALE had to be a typo for SALT. (If that isn't want happened, someone please yell... I'm still assuming.)
February 9, 2012 at 5:39 am
ma-516002 (2/9/2012)
Find some thoughts about this topic here:
I hope no-one who reads that thread gets confused and is infected by this crazy notion that Hashbytes does internal salting! As Russel Fields points out: "HASHBYTES does not, in itself, use a salt key" - but despite that clear (and accurate) statement the OP (Dboy888) remained unconvinced.
Anyone who wants to can use the MDn or SHA1 servers available on the web to caculate some hashes, and then calculate the same hashes using hashbytes: they will find that hashbytes produces the same standard results as the things on the web - so clearly there is no salting going on in there.
Tom
February 9, 2012 at 5:51 am
Blimey - a question I could answer correctly without needing to do some reading first!
February 9, 2012 at 6:01 am
Thomas Abraham (2/9/2012)
Thanks for the question. Hoever, I got it wrong because I used this source:http://msdn.microsoft.com/en-us/library/cc837966(SQL.100).aspx
which says:
"It is not possible to specify the salt value in SQL Server."
Can someone please expain why this is wrong? Or why I have interpreted it incorrectly. Thanks!
That quote comes from a section in whch the topic is encryption and encrypted data; SQL Server encryption always uses a random salt.
Hashbytes is a hashing function, not an encryption function - so this statement about encryption doesn't apply to it. And since many common uses of the hash functions it supports require unsalted hashes (for example hashing to reduce query cost for encrypted data - see the methods of doiong this described towards the end of that paper) it can't salt behind the scenes: if your application needs salting you can do it yourself by including the salt in the string passed to the hash function; another reason it doesn't salt behind the scenes is that it wants to conform to the various standard functions that it supports (MD2, MD4, MD5, SHA, SHA1, and soon SHA2-256 and SHA2-512).
Tom
February 9, 2012 at 6:17 am
L' Eomot Inversé (2/9/2012)That quote comes from a section in whch the topic is encryption and encrypted data ...
Thanks! It's as I suspected. I took it out of context due to haste. I appreciate you taking the time to sort me out.
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
February 9, 2012 at 6:30 am
At first figured that either "you cannot add a salt", or the correct answer. Flipped a coin and well ... lost the point ... teach me not to gamble.
In all sincerity, thanks Steve for a good question, learned something
February 9, 2012 at 7:08 am
Interesting question, and an interesting bit of reading. However
That quote comes from a section in whch the topic is encryption and encrypted data; SQL Server encryption always uses a random salt.
How can SQL Server use a random salt and still have reproduceable results? Am I getting some concepts confused here?
February 9, 2012 at 7:31 am
I'm with the folks who say that concantenating two strings is @input, not a separate "parameter". We need to be using the common definition of parameter here.
February 9, 2012 at 8:02 am
The question could have been worded a bit better but a good question none the less and an interesting discussion as always.
February 9, 2012 at 8:09 am
The SALE definitely confused me as well. I couldn't force myself to believe that it would be a typo. It goes to show we are all human. I should have went with my gut instinct and chose that answer anyway.
February 9, 2012 at 8:12 am
What is a SALE string? I don't understand that terminology.
February 9, 2012 at 8:23 am
Not too many people did. Thats why a lot of people answered the question wrong.
February 9, 2012 at 8:28 am
thanks for the question.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
February 9, 2012 at 8:48 am
L' Eomot Inversé (2/9/2012)
...Hashbytes is a hashing function, not an encryption function...
I would say the question as intended is a useful learning tool, but it was written poorly.
HASHBYTES does not, and cannot, perform encryption, nor can it decrypt. I see interview candidates conflate encrypting with hashing all the time; they aren't the same. Hashing is mathematically easy to do in one direction (cleartext to hash), and mathematically difficult to do in the other direction (hash to cleartext), theoretically to the point that the only way to get the cleartext from the hash is to guess the cleartext and see if you're right*.
The SALE vs. SALT typo was also a minor issue, but that's a normal typo.
*Guessing MD5 or SHA1 can happen, on a single computer, at speeds measured in tens of billions of guesses per second, applied against dictionaries combined with rules (i.e. every word in the dictionary doubled, every word with different case settings, every word in several dialects of 1337 speak, every word with a suffix of every number from 0 to 1000, etc. etc. etc. still doesn't take very long).
Viewing 15 posts - 16 through 30 (of 64 total)
You must be logged in to reply to this topic. Login to reply