Salt is good for passwords, but you can’t use them for the purpose being discussed here.
Correct. You can kind of split the difference, though, by using tokens.
Devise a tokenizer function that’s a one-way map of email addresses to a random-ish token number. Can be something simple, like a 64-bit pseudo-random integer. Before you hash any email address with a well-known hashing algorithm, generate a token for that email address through the tokenizer, and hash the combination of the email address and the token.
The tokenizer doesn’t have to be as statistically rigorous or computationally intensive as a hash function. The actual hash function will give you your asymmetric, statistically uniform irreversibility. You’re just relying on the tokenizer in the same way you’d rely on a salt: as long as it’s not totally guessable, you’re probably fine.
This should be reliable given a few modest constraints:
-
You keep the tokenizer secret, of course;
-
You also protect the pipeline between the output of the tokenizer and the input to the hash function (so that people can’t reverse-engineer the tokenizer by running a bunch of inputs and seeing what tokens get tacked onto the end); and
-
You only use the tokenizer for one specific password collection.
Given those constraints - the process should be both consistent and resistant to attack. Someone would have to take one email address and try all 2^64 tokens just to figure out what token got tacked onto that one email address. As long as they can’t repeat that process for a large enough sample of email addresses to discern the tokenizer, it should remain secure.
