Using hash to search encrypted records

Question

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?

Answer 1

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. Given the intent is to search through the set, you can't compare a salted hash with an unsalted one without needing to generate and compare n hashes for n rows in your dataset, and that would likely be extremely slow. Secondly simply hashing a phone number provides little to no security on its own due to the small search space and relative ease of brute force testing all of them. You could of course attempt to do so anyway, but see paragraph #1 again - it is going to be prone to actually making your dataset less secure.

Answer 2

Hashing a phone number is mostly pointless since the search space is relatively small to begin with. There are very few (in crypto terms) options for phone numbers so almost any bad actor would be able to bruteforce your hashes. A unique salt for each user would provide some negligible additional protection, at the cost of a significant slowdown of search operations on large datasets due to the need to hash the search value for each user. Hashing phone numbers is bad design in my opinion, however for a possible solution to the general problem of searching hashed data see bloom filter.