>IP addresses count as PII, Personally Identifiable Information.

One way hashed (that can't be rainbow tabled) are not however PII afaik however, so it's quite easy to turn an IP address into a "net location ID" or something similar that can't be tracked back to a physical IP for analytics.

You could simply enumerate all 32 bits and end up with each and every IP reversed so that trick doesn't really hold water.

No need for rainbow tables, the search space is small enough to brute force.

Enumeration through 32 bits of bcrypt doesn't sound that feasible to me.

Given a GPU farm however I'm sure it might be feasible. However at that point surely you just add a salt?

If you're going to add a unique salt every operation you just destroyed the value of that IP address for tracking purposes. Which was the whole point of the discussion to begin with. By your scheme you might as well store a random number. So, either you store the IP in such a way that you can later re-associate a new call with the previous IP or you might as well not have it.

> However at that point surely you just add a salt?

How would that work? You'd have to use the same salt for every IP (which completely negates any benefit of the salt), otherwise how do you know that bcrypt(salt_1, IP_1), which you stored in your database yesterday, refers to the same IP as bcrypt(salt_2, IP_1) that you stored a month ago?

It's enumeration through 32 bits of 0-4294967295. There are only so much IPv4 addresses.

If you add a salt, then that "net location ID" becomes of very limited use. You won't be able to grep through the logs for request from specific IP, you won't be able to tell how many distinct IPs are accessing your services, etc etc. The only use I can see is keeping it in the session to check if IP address had changed, as a security measure.