Hacker News Reader

Comment by comex | Hacker News Reader

Or even if ShadyAdtechCo just knows what the hashing function is, and has a list of plaintext email addresses to test against – perhaps obtained from one of the datasets they're joining against, or even from crawling the web.

View on HN

Hashing should be done with salt for precisely that reason.

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).

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.

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.

What is the salt based on?

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.

Reply on news.ycombinator.com