I am building an application where one user (User A) can store a "query" of another user (User B) that may or may not exist in the system. This query can be done by email address.

The general workflow is as follows:

  1. User A is already authenticated with the application, whereas User B is not.
  2. User A creates a query using User B's email address. This is stored as a hash.
  3. When User B authenticates with the application, they can provide and confirm an email address.
  4. Once the email of User B is confirmed, a query is performed with their email address' hash to see if there are any outstanding queries made by another existing user referencing it.
  5. If a match is made, the two users are connected and are at once known to one another.

The email is not used for contact purposes and is only used to identify. As such, I am simply looking for a way to store this identity in a way that I can easily query the database via SQL to see if it exists.

I first considered using MD5, but after further reading, my impression is that this is not recommended.

I do have access to Pbkdf2 hashing, but each generated hash is different and it is unclear to me how I would be able to query it using a SQL query to match input and confirmation.

Most of the information I am reading and finding is related to passwords, and that is not my case. In my case, I want an efficient, consistent identifier that I can use and store in a secure way to see if it exists in the system.

What is the best-recommended way of doing this?

  • 2
    You might want to consider using the SHA256 hash function. SHA256 is a one-way hash function (like MD5), but considered to be more secure than MD5.
    – mti2935
    Nov 4, 2021 at 11:01
  • What are the risks?
    – kelalaka
    Nov 4, 2021 at 12:39
  • Why do you need to hash the email? Why not store it in clear?
    – ThoriumBR
    Nov 4, 2021 at 12:58
  • 2
    someone@(google|msn|...|yahoo|).com so we have the same problem : Is it easy to crack a hashed phone number?. HMAC with the key is protected with HSM can be a solution.
    – kelalaka
    Nov 4, 2021 at 16:21
  • 1
    Also good to know, @kelalaka. I appreciate the feedback and have a good collection here if I need to revisit. Upon everyone's feedback, I have decided on using SHA256 hashes that are encrypted at the server level with SQL Server Encrypted Columns. I feel this is more than sufficient for a v1 solution. Thank you all again for providing your feedback. It is very much appreciated!
    – Mike-E
    Nov 5, 2021 at 10:35

1 Answer 1


You are correct that MD5 is not a good solution. If you want to stop offline brute force attacks, PBKDF2 or similar is a much better choice. But, as you have noted, there is a problem: Each generated hash is different. This is because of the salt, that is picked at random for each hash.

In the case of passwords, you look up the right row with the help of an identifier such as a username. You can then lookup the salt, and hash the provided password only once with that salt. In your application, the hashed value is the identifier. If you hash it with a unique salt, it can not be used for look ups.

To get around this, you will have to use no salt at all or a constant salt (i.e. a pepper, preferably not stored in the database). This severely weakens the security of the hashes - they will be easier to brute force. Still, it is better than no hashing at all. If it is good enough depends on how high your security requirements are.

Disclaimar: There may be some clever way to solve this problem other than eliminating the salt, but I can't think of one.

  • Excellent @Anders I am glad to hear that I didn't ask something way too obvious. :) As far as how high my security requirements are, my primary fear is that a bunch of users start saving a bunch of these queries, I somehow get compromised, and then all these email addresses are sold on the dark web without the owners having any say in it. ATM I am leaning on using SHA256 hashes as they seem to be more secure than MD5. Ultimately for v2 I think the answer is to have aliased emails that are offloaded and forwarded somehow (e.g. burnermail.io)
    – Mike-E
    Nov 4, 2021 at 15:35
  • I'm going to mark this as the answer. What I have landed on is using SHA256 hashes stored in encrypted SQL Server columns. I think this is more than sufficient for a v1 product. I appreciate everyone taking the time to provide feedback and validating/verifying my understanding of this problem.
    – Mike-E
    Nov 5, 2021 at 10:34
  • 1
    @Mike-E, I think you solution sounds good. Many would just store it in plain text, and your method is a big step up. If you want to increase security further you could use many iterations of SHA256, or use some other slow hash function, to make brute force harder. But I think you are good to go as you are.
    – Anders
    Nov 5, 2021 at 12:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .