4 ms·

Salts provide resistance against bulk bruteforce by making it so that you can't identify which hashes are the same plaintext without actually computing all of t

Salts provide resistance against bulk bruteforce by making it so that you can't identify which hashes are the same plaintext without actually computing all of them. The issue is still that there are not that many IPv4 addresses and so even with very heavy algorithms it would be trivial to break.

worksonmine 3y ago
But there are infinite numbers of salts. Please explain how this could be brute-forced as long as the salt is used correctly? What am I missing?
- ericpauley 3y ago
  No matter what strategy you use to hash IPs, if you can correlate to an IP you can find the original IP by just trying all options. It doesn’t matter what you do because 4B unique possibilities is just too low to prevent brute forcing while maintaining utility. If you use a random salt, then you need to store it or else the stored value has no utility. However you implement retrieval of that salt it can just be brute forced.
  - worksonmine 3y ago
    The salt could be stored as a cookie and you can follow the session but never be able to reverse the hash yourself. Any match you get in the brute-force attempt might as well be a collision. The entropy can be in the salt, you're all making it sound way too easy. The requirement is "non-reversible". Given infinite time everything can be brute-forced, but this is the mossad/not-mossad problem. It's good enough for storing passwords, where the salt is plain-text.
    - ericpauley 3y ago
      That’s just unique identifiers with extra steps.
- 3np 3y ago
  Could you be more precise with what envision by "correctly"? If you use a shared salt for all or a significant portion of rows, then it's a realistic matter of bruteforcing to cover your entire table, given that the attacker has been able to recover the salt. Even without any cracking at all, shared salt would mean that rows can be correlated if the attacker can identify a single row and correlate that to the target. Let's say you use up the game and use per-row salts, like here: https://stackoverflow.com/questions/4159827/another-question-about-salting-passwords https://stackoverflow.com/questions/4159827/another-question... Given an attacker wanting to pull out information about a specific user, and they have on their hands your salted dataset, the salts, and a handful of IP addresses that the target is known to be associated with from other datasets, it's still trivial to brute-force. Even increasing it to a set of a few thousand IP addresses (say, a handful of /24s) it should be perfectly realistic, assuming you don't use enough rounds that your infrastructure is spending a majority of its CPU-time only performing psuedoanonymizing hashing. Oh, and if you use per-row salts, is any of that data still usable in the first place? The above is besides the point of the IPv4 address space being small enough to exhaust and shows why this is an issue for IPv6 addresses as well.
  - jameshart 3y ago
    If it's shared, it's not a salt. The term of art in that case is 'pepper'.
    - 3np 3y ago
      First time I hear this interpretation. A shared salt is still a (very poor) salt. A pepper would not be stored alongside the ciphertexts, if at all.
    - antod 3y ago
      Isn't it the other way around? Most salted hash implementations share the salt by embedding it in the hash. It's pepper that isn't shared. After rereading, I suspect by 'shared' you meant 'non unique' rather than 'public'?
      - 3y ago
- tjoff 3y ago
  You need to protect it from yourself. If you know the salt then you can trivially brute-force it yourself and now you are not GDPR-compliant. If you don't know the salt then you'll have to use a new salt for each IP and then all hashed IPs will be unique and you have no way of correlating them so it is all completely worthless.
- sweetjuly 3y ago
  The salt is stored in plaintext alongside the hash and simply concatenated. If your scheme, for example, is h := H(ip, salt) := sha256(ip :: salt), bruteforcing is simply a matter of trying all values of ip: for i in 0..<(1<<32): if H(i, salt) == h: return i
  - worksonmine 3y ago
    The salt doesn't have to be plain-text, that's an implementation detail in the common password hashing algorithms for obvious reasons. The requirement was that the hash should be non-reversible. Store the salt in a (http-only) session cookie and concatenate it to the IP before the hashing rounds. Put your entropy in the salt and any brute-force attempt is theoretical. For every session you need to compute the exact combination of IP + salt (which isn't even known to the server).
    - 3np 3y ago
      At that point, what value does the salted+hashed IP address give you over a randomly generated number (say, a UUID) per session?
      - worksonmine 3y ago
        None, I'm not arguing for the solution. Proxying through a PHP script just to keep using Google Analytics is overkill when private self-hosted solutions exist. I'm simply showing how you can anonymize IPs even from yourself, if the goal is to anonymize from only Google and not the server it could be useful across sessions. The solution being overkill does not mean my first comment 'That's why you use a salt, which is what I assume is meant by "non-reversibly"' is wrong.

worksonmine 3y ago

But there are infinite numbers of salts. Please explain how this could be brute-forced as long as the salt is used correctly? What am I missing?

ericpauley 3y ago
No matter what strategy you use to hash IPs, if you can correlate to an IP you can find the original IP by just trying all options. It doesn’t matter what you do because 4B unique possibilities is just too low to prevent brute forcing while maintaining utility. If you use a random salt, then you need to store it or else the stored value has no utility. However you implement retrieval of that salt it can just be brute forced.
- worksonmine 3y ago
  The salt could be stored as a cookie and you can follow the session but never be able to reverse the hash yourself. Any match you get in the brute-force attempt might as well be a collision. The entropy can be in the salt, you're all making it sound way too easy. The requirement is "non-reversible". Given infinite time everything can be brute-forced, but this is the mossad/not-mossad problem. It's good enough for storing passwords, where the salt is plain-text.
  - ericpauley 3y ago
    That’s just unique identifiers with extra steps.
3np 3y ago
Could you be more precise with what envision by "correctly"? If you use a shared salt for all or a significant portion of rows, then it's a realistic matter of bruteforcing to cover your entire table, given that the attacker has been able to recover the salt. Even without any cracking at all, shared salt would mean that rows can be correlated if the attacker can identify a single row and correlate that to the target. Let's say you use up the game and use per-row salts, like here: https://stackoverflow.com/questions/4159827/another-question-about-salting-passwords https://stackoverflow.com/questions/4159827/another-question... Given an attacker wanting to pull out information about a specific user, and they have on their hands your salted dataset, the salts, and a handful of IP addresses that the target is known to be associated with from other datasets, it's still trivial to brute-force. Even increasing it to a set of a few thousand IP addresses (say, a handful of /24s) it should be perfectly realistic, assuming you don't use enough rounds that your infrastructure is spending a majority of its CPU-time only performing psuedoanonymizing hashing. Oh, and if you use per-row salts, is any of that data still usable in the first place? The above is besides the point of the IPv4 address space being small enough to exhaust and shows why this is an issue for IPv6 addresses as well.
- jameshart 3y ago
  If it's shared, it's not a salt. The term of art in that case is 'pepper'.
  - 3np 3y ago
    First time I hear this interpretation. A shared salt is still a (very poor) salt. A pepper would not be stored alongside the ciphertexts, if at all.
  - antod 3y ago
    Isn't it the other way around? Most salted hash implementations share the salt by embedding it in the hash. It's pepper that isn't shared. After rereading, I suspect by 'shared' you meant 'non unique' rather than 'public'?
    - 3y ago
tjoff 3y ago
You need to protect it from yourself. If you know the salt then you can trivially brute-force it yourself and now you are not GDPR-compliant. If you don't know the salt then you'll have to use a new salt for each IP and then all hashed IPs will be unique and you have no way of correlating them so it is all completely worthless.
sweetjuly 3y ago
The salt is stored in plaintext alongside the hash and simply concatenated. If your scheme, for example, is h := H(ip, salt) := sha256(ip :: salt), bruteforcing is simply a matter of trying all values of ip: for i in 0..<(1<<32): if H(i, salt) == h: return i
- worksonmine 3y ago
  The salt doesn't have to be plain-text, that's an implementation detail in the common password hashing algorithms for obvious reasons. The requirement was that the hash should be non-reversible. Store the salt in a (http-only) session cookie and concatenate it to the IP before the hashing rounds. Put your entropy in the salt and any brute-force attempt is theoretical. For every session you need to compute the exact combination of IP + salt (which isn't even known to the server).
  - 3np 3y ago
    At that point, what value does the salted+hashed IP address give you over a randomly generated number (say, a UUID) per session?
    - worksonmine 3y ago
      None, I'm not arguing for the solution. Proxying through a PHP script just to keep using Google Analytics is overkill when private self-hosted solutions exist. I'm simply showing how you can anonymize IPs even from yourself, if the goal is to anonymize from only Google and not the server it could be useful across sessions. The solution being overkill does not mean my first comment 'That's why you use a salt, which is what I assume is meant by "non-reversibly"' is wrong.