5 ms·

You can’t hash an ipv4 address. It’s trivial to brute force all possibilities given the limited problem space.

by bunnyfoofoo 3y ago

leononame 3y ago
But you could use a salt, right?
- Qwertious 3y ago
  A salt will render rainbow tables useless, but AIUI will not prevent brute-forcing after the fact. IPv4 has ~4 billion addresses, which would be too expensive for data analytics but could be brute-forced if someone really wants this one piece of data in particular.
  - deleted 3y ago
    [deleted]
- wyufro 3y ago
  Only if the salt is kept secret. There also needs to be a different salt value per ip, obviously. But given those conditions, it works. Of course, it would be just as simple to use the salt as-is, in that case, since you have to look it up anyway.
  - deleted 3y ago
    [deleted]
worksonmine 3y ago
That's why you use a salt, which is what I assume is meant by "non-reversibly".
- sweetjuly 3y ago
  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.
jeltz 3y ago
I have not researched it but I wonder if you can even hash IPv6 addresses. The issue I see is that allocations could be too regular so even if the full space is huge most addresses may occupy a small and predictable part of it.
- pixl97 3y ago
  Depends how you define IP in this sense. Each full individual IPv6, unlikely as most consumer devices are getting a somewhat random internal address on their network. Now, with IPv6 for most consumers the first 64 bits is generally enough to define the edge network device that would be covered by a single IPv4 these days.
  - marcosdumay 3y ago
    > the first 64 bits is generally enough to define the edge network One complication is that hashing removes this structure. If you use any good algorithm, you will need to test the entire address to recover any part of it. I am very wary of IPv6 addresses being so heavily biased into 00 or ff segments that the address space doesn't actually add much entropy. So, I'd go with no, it's not safe to hash them. But if you get some random ones, I am really not sure.
zyx321 3y ago
How about this: Server-wide salt. Randomly generated every 24h or server reboot (whichever is sooner). The salt is not saved alongside the hashed IP, it is not saved anywhere whatsoever. There is no log of previous salts. You can still track a user session across multiple page calls, but the hash can not track them across different sites.

You can’t hash an ipv4 address. It’s trivial to brute force all possibilities given the limited problem space.

leononame 3y ago

But you could use a salt, right?

Qwertious 3y ago
A salt will render rainbow tables useless, but AIUI will not prevent brute-forcing after the fact. IPv4 has ~4 billion addresses, which would be too expensive for data analytics but could be brute-forced if someone really wants this one piece of data in particular.
- deleted 3y ago
  [deleted]
wyufro 3y ago
Only if the salt is kept secret. There also needs to be a different salt value per ip, obviously. But given those conditions, it works. Of course, it would be just as simple to use the salt as-is, in that case, since you have to look it up anyway.
- deleted 3y ago
  [deleted]

worksonmine 3y ago

That's why you use a salt, which is what I assume is meant by "non-reversibly".

sweetjuly 3y ago
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.

jeltz 3y ago

I have not researched it but I wonder if you can even hash IPv6 addresses. The issue I see is that allocations could be too regular so even if the full space is huge most addresses may occupy a small and predictable part of it.

pixl97 3y ago
Depends how you define IP in this sense. Each full individual IPv6, unlikely as most consumer devices are getting a somewhat random internal address on their network. Now, with IPv6 for most consumers the first 64 bits is generally enough to define the edge network device that would be covered by a single IPv4 these days.
- marcosdumay 3y ago
  > the first 64 bits is generally enough to define the edge network One complication is that hashing removes this structure. If you use any good algorithm, you will need to test the entire address to recover any part of it. I am very wary of IPv6 addresses being so heavily biased into 00 or ff segments that the address space doesn't actually add much entropy. So, I'd go with no, it's not safe to hash them. But if you get some random ones, I am really not sure.

zyx321 3y ago

How about this: Server-wide salt. Randomly generated every 24h or server reboot (whichever is sooner). The salt is not saved alongside the hashed IP, it is not saved anywhere whatsoever. There is no log of previous salts. You can still track a user session across multiple page calls, but the hash can not track them across different sites.