I want to hash email addresses so that they are anonymous but still unique in my database. I was thinking of using scrypt for this and creating the salt as a sha256 of some secret stored on the server + their email address. Implementation in Node.js looks like this:

const crypto = require("crypto");
const secret = "secret123";
const email = "[email protected]";
const salt = crypto
  .update(secret + email)

const hashedEmail = crypto.scryptSync(email, salt, 64);

In the event of a data leak a hacker might be interested to know if [email protected] is in the database or not. Assuming they did not know the secret this would make it impossible. Also I need something that produces the same hash each time for database lookup purposes.

Does this sound like a good approach? Keen to hear this group's thoughts.

  • 1
    How are you storing the secret in a way that it is not accessible in the event of a data breach?
    – msanford
    Commented May 26, 2022 at 16:28
  • This looks like XY problem. Why use email and try to make it not recoverable and have overhead with using and protecting secret instead of just using UID?
    – mentallurg
    Commented May 26, 2022 at 17:56
  • When you hash the email addresses you will no longer be able to use them for sending email. Why are you storing them in the first place?
    – Jeff
    Commented May 26, 2022 at 17:58
  • For login. Assume secret can be kept secret.
    – fire
    Commented May 26, 2022 at 18:20
  • Is there any reason to mix the email address into the salt, rather than using a constant (secret) salt? Also, why use a slow hash instead of a fast keyed hash, like HMAC? Commented May 26, 2022 at 21:49

1 Answer 1


This can be an appropriate defense in depth measure if the secret is managed suitably. (A rather big “if”.)

However, security is multidimensional. You say that you want to use the hashed email addresses for log-in purposes, which will make it impossible to send emails to these people. That might run against some security goals, such as the ability to notify account holders in case you suffer a data breach.

I would not implement a scheme like this, unless there would be very good reasons to deviate from industry standard approaches. And if you had unusually strong security/privacy requirements, there might be better alternative approaches – such as allowing a freely chosen username instead of the email address as a user ID.

You must log in to answer this question.

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