If I am using SHA-512 hash values merely as a means to search fields that have been encrypted elsewhere, is it cryptographically secure enough to hash without salt?
For background, I have been given a non-negotiable requirement to encrypt personal data at the field level. This conflicts with another requirement to be able to search by email and phone number, but I have been told that searching by exact match is a suitable compromise.
To implement this, I remove all personal information fields from my persistence and instead persist a json that I have encrypted with a AWS KMS generated data key. I then also added two columns to my persistence: email hash and phone hash.
Would SHA-512 hashing these values without salt be considered poor security practice? Is it more appropriate to generate a random salt and store that along with the data? If the point is protecting the data at rest, and the salt is sitting in the same table with the hash, how is that more secure?
CodePudding user response：
A salt isn't necessary here, but..
Rolling your own encryption storage scheme is often the bad practise in something like this, simply because your application will need the key at some point and therefore your application will need to consider key security otherwise it won't actually add anything to your overall security and may make it substantially worse. For example, rather than the email address identifying someone, the hash does instead - a lot of dangerous information can still be derived from "anonymised" data sets if this isn't carefully managed. So, firstly, an important reminder: Use the built in features of your database engine whenever possible.
What's a salt for?
A salt has a primary purpose of ensuring uniqueness of the input to a hash function. This is why it is incredibly important that a salt is generated using high quality random number generators - that'll make sure they're not predictable. Salts are commonly used on password fields because lots of people are going to end up choosing the same low quality passwords - usually the lowest quality one imaginable (literally the word password) followed by pressing whatever keys satisfy the strength requirements. In other words, multiple people end up with the same password and thus the same hash. If you can crack one, you crack them all, simply because SHA-512("password1!") is a constant. If you prefix the text with some random value, then every input is unique and thus every hash is too.
Why isn't it needed here?
Email addresses and phone numbers are very likely to be unique for your users already, so the salt isn't strictly necessary for its purpose. You could of course take a belt and braces approach and add it anyway - i.e. just adding features because it has an appearance of making things more secure - but see paragraph #1 again :)