Hacker News Reader

Comment by AndrewStephens | Hacker News Reader

This is a clever idea but limited in applicability. It is probably fine for a low security web app or game, but could still leak personal information if the db got hacked.

The problem is that the salt has to be the same for each record and that emails present a limited search space.

Imagine I stole the database for blackmailable-fetish.com. All the emails are hashed with the same salt so I can brute-force the following restricted space:

[top 200 first names][top 1000 surnames][digits from 0 - 999]@[top 5 email providers]

That would probably get me 75% of the emails - let the extortion games begin!

View on HN

Not sure why you're bringing this up. If you stored them in plaintext it gives hackers 100% of the emails with zero effort required.

Because it gives the false appearance of security. With this scheme, you always need to act as if the e-mail addresses are plaintext anyway. It should not be used.

True, but I maintain that if you are worried that hackers may steal your email database then a much better approach is to encrypt the emails with an external key.

You could just do that anyway. I've seen spam email trying to extort people threatening to release indecent images of them (that they don't have. supposedly, they've been captured from the victims selfie cam).

In this case, you don't have to be accurate, you're just trying to call someones bluff, in the small case they've actually done said thing (and in addition believe you can prove it AND that payment will silence them)

You could compute a very slow hash on the client, using bcrypt or argon2id. Then your attack is still possible but a bit more expensive.

If extortion is a possibility, use a separate email address. This is still a good extra layer of protection though.

Depending on the size of the user database it might be cheap enough to try all random-salts+hashed emails (if it fits in RAM it's probably cheap enough).

The salt is in config.

Reply on news.ycombinator.com