Hacker News Reader

Comment by piaste | Hacker News Reader

> Hashes should be salted. If you salt, you are fine, if you don't you aren't.

> Whether the salt can be kept indefinitely, or is rotated regularly etc is just an implementation detail, but the key with salting hashes for analytics is that the salt never leaves the client.

I think I'm missing something.

If the salt is known to the server, then it's useless for this scenario. Because given a known salt, you can generate the hashes for every IP address + that salt very quickly. (Salting passwords works because the space for passwords is big, so rainbow tables are expensive to generate.)

If the salt is unknown to the server, i.e. generated by the client and 'never leaves the client'... then why bother with hashes? Just have the client generate a UUID directly instead of a salt.

View on HN

Without a salt, you can generate the hash for every IP address once, and then permanantly have a hash->IP lookup (effectively a Rainbow table). If you have a salt, then you need to do it for each database entry, which does make it computationally more expensive.

People are obsessed with this attack from the 1970s, but in practice password cracking rigs just brute force the hashes, and that has been the practice since my career started in the 1990s and people used `crack`, into the 2000s and `jtr`, and today with `hashcat` or whatever it is the cool kids use now. "Rainbow tables" don't matter. If you're discussing the expense of attacking your scheme with or without rainbow tables, you've already lost.

> If you're discussing the expense of attacking your scheme with or without rainbow tables, you've already lost.

Can you elaborate on this or link to some info elaborating what you mean? I'd like to learn about it.

> why bother with hashes? Just have the client generate a UUID directly instead of a salt.

The reason for all this bonanza is that the ePrivacy directive requires a cookie banner, "making exceptions only for data that is "strictly necessary in order to provide a [..] service explicitly requested by the subscriber or user"*.

In the end, you only have "pinky promise" that someone isn't doing more processing on the server end, so in reality it doesn't matter much especially if the cookie lifetime is short (hours or even minutes). Actually, a cookie or other (short-lived!) client-side ID is probably better for everyone if it wasn't for the cookie banners.

ALL of the faff around cookies is the biggest security theater of the past 40 years. I remember hearing the fear-mongering in the very early 2000's about cookies in the mainstream media - it was self-evidentally a farce then, and a farce now.

Isn't in this case data is part of "strictly necessary" data (IP address)? That's all that gets collected by that magic CSS + server, no?

ePrivacy directive only applies to information stored on the client side (such as cookies).

> > the salt never leaves the client

> I think I'm missing something.

...

> If the salt is known to the server,

That's what you were missing yes

Did you miss the second half where GP asked why the client doesn't just send up a UUID, instead of generating their own salt and hash?

Reply on news.ycombinator.com