You can’t hash an ipv4 address. It’s trivial to brute force all possibilities given the limited problem space.
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.
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.
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.
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.
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.
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...
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.
The term of art in that case is 'pepper'.
After rereading, I suspect by 'shared' you meant 'non unique' rather than 'public'?
> In cryptography, a pepper is a secret added to an input such as a password during hashing with a cryptographic hash function. This value differs from a salt in that it is not stored alongside a password hash, but rather the pepper is kept separate in some other medium, such as a Hardware Security Module.
A salt is a unique random value added to each value when hashing. Obviously, such a salt needs to be stored alongside each value because it’s random and unique. If you don’t store it how could you possibly ever figure out what it is?
A pepper is a shared value added to lots of different things before they are hashed. It isn’t unique to each value, so it doesn’t need to be stored alongside them. Although it still needs to be stored somewhere. But hey, you could also store it alongside every value you store. This is a thing sometimes done when you do ‘per user’ pepper, where for example the pepper is itself a a username or something - so your pepper is also in the database alongside the passwords - but that doesn’t make it a salt.
If you are using the same piece of data to season multiple things before hashing, you are using ‘pepper’ not ‘salt’.
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.
for i in 0..<(1<<32):
if H(i, salt) == h:
return iThe 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.
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.