[comex]

If you mean a static salt, that could help mitigate against hacks (if the attacker has access to the database but not the code), but where adtech is concerned it's probably more realistic to assume that the datasets they're using were disclosed willingly. If you mean using a different salt for each address, that could work for some use cases, but it wouldn't work for the use case described in the blog post, since Touch Surgery needs to be able to lookup whether a given address is in the database (to see whether they've previously declined an invitation).

[aychedee]

It's really no problem to do this. We're using a variation on this: https://unix.stackexchange.com/questions/158400/etc-shadow-h.... The output of crypt (where the input is an email address) is pretty useless if we did suffer a data breach. They'd have to hash every known email address with that salt in order to figure out who had declined an invite from us.

[comex]

What is the salt based on?

[richardwhiuk]

Why is it reasonable to assume they were disclosed willingly? That sounds like a startling assumption and the reverse of the one I'd make.

Without good evidence, you must assume they were disclosed unwillingly.

[TimothyBJacobs]

Couldn't the salt be unique to the requesting account? I would assume that just because a user declined an invitation from one user, they still might want to accept an invitation from a separate user.