Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
Salting is an integrated part of symmetric key encryption for column data in SQL Server, making column level encryption on the server non-deterministic. The salt value is also called an initialization vector or nonce, number used once. If you look at Raul Garcia's blog on the description of a cryptographic message, you will see how the salt is integrated into the result. There is one new exception, which is that in SQL Server 2016 Always Encrypted, columns can be configured for deterministic encryption, hence either no salt will be used or a consistent salt will be used in the encryption to ensure that the encrypted value is consistent for the same input.
