Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I was attending a database encryption session at a developers conference. The presenter (who was a published author on the subject) said that MS SQL Server did not support salted hashes in the database, but it does support salting with encryption. This was the first I heard of salting in encryption. I asked for clarification to make sure that was what he was saying.

Is this something anyone else has heard of before? Is this an important practice that I have just never heard of before?

share|improve this question
    
"Is there a standard for OpenSSL-interoperable AES encryption?" implies that salted encryption (or at least salted AES encryption) is common. –  David Cary Oct 2 '12 at 16:28

2 Answers 2

up vote 10 down vote accepted

Looking at the MSDN link given by Tangurena, they use the word salt in this paragraph (and the following ones):

To prevent discovery of plain text content by comparing encrypted values (the second attack), most encryption algorithms include a salt value. Specifying a different salt value generates a very different encrypted output. When using the .NET cryptography classes, you can specify the salt as the initialization vector argument. In SQL Server, a random salt value is always applied to the encryption.

A block cipher (given the same key) always maps the same plaintext to the same ciphertext.

When constructing a stream cipher from a block cipher, we usually use one of the secure cipher modes to avoid that same input blocks give the same output, which would be a point of attack. (See the ECB example image mentioned there.)

A database encryption works a bit different than a stream encryption: you normally want to have access on each record individually without having to decrypt the whole table/database. But we still want to avoid same records/fields giving the same ciphertext.

To do this, we use the same trick as for the stream ciphers: for each block of data to encrypt, we generate some random initialization vector. But here it is saved together with the data instead of derived from the previous block(s) like in a stream cipher. This is input into the block cipher, as well as the key and the plaintext, for both encryption and decryption.

share|improve this answer
    
I asked him if he was referring to the initialization vector, and that is what it sounds like from that explanation. Thanks! –  Jim McKeeth Jul 13 '11 at 3:38

I think you misunderstood what they were saying. But then, reading the MSDN topic on Cryptography in SQL Server, they make a vaguely similar claim to what you said you heard.

SQL Server 2008 supports encrypting entire databases. It is a bit complicated to set up, but protects the mdfs and backups if stolen.

There is a function called HashBytes which takes a VARCHAR input and returns a VARBINARY. You could use it as part of your own Login stored procedure, adding the salt to the input password to check if they match.

The purpose of adding "salt" to a password before checking it is an old mechanism used to make dictionary attacks much harder. The traditional attack on a website would be to download the database with the users table, and then use a number of techniques to guess passwords (most people use very easy to guess passwords, so hashing a dictionary and comparing those hashes to what is in a hashed {but not salted} table will probably get you 5-20% of the user's passwords right away). Adding a unique salt per user makes it so that if 2 users share the same password, you can't tell with a simple dictionary attack.

share|improve this answer
    
I thought I misunderstood too, which is why I asked for clarification. –  Jim McKeeth Jul 12 '11 at 22:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.