The only problem here is, IP addresses are such a small space (4 billion addresses) that it's so easy to brute-force the entire database that I don't see it offering any protection. If the data is stolen it will be cracked in no time, and if the data is subpoenaed that cost will likely be ruled as insufficiently "onerous". Even IPv6 doesn't save you, since the space is sparsely populated.
No, with IP logging it's all-or-nothing. You might as well store them as uint32/uint128.
You are kinda of right, but I guess you missed some point here.
For the attacker to be able to brute-force, he would require the salt value. So it would be important to make sure it's not in plain-text. And of course if Chad wants to do that, he can easily build a rainbow file, but he can make it easier for himself by just lying about storing the ips.
Now another problem with this approach, would be the ability to change the salt. The moment it's changed, all data is lost (or meaningless). So in order to make it secure, it would be very very long, and unpredictable. Also encrypted.
Another thing, if an attacker would access the server where the code is running, if it's in the memory he would get it. So when it's in memory, it should only reside there when it's being used, and destroyed immediately. So it makes it harder to the attacker to get it, (until the moment it's used).
But come to think of it, if the attacker is that good, I think he would be interested in other things, like things that would get him more money than a list of IP addresses. :-)
It's not as clear cut as that. With suitable salt and suitable (long) hashing function, you can delay
From a security / data privacy angle, things are rarely 100% perfect or 100% broken. Just because an approach is not 100% perfect, doesn't mean that it is worthless. It can still offer protection of sensitive data.
Storing IPs in the clear in a DB means that if anyone gets any access to it (e.g. SQL injection type attack), they can have the whole lot. With salted IPs it's harder and much longer before they have any decent data.
If you tweaked a hashing algorithm to take circa 100 milliseconds to hash an IP, then "brute forcing" would be much less of a problem because it would take about 13 years to hash the whole lot.
>If you tweaked a hashing algorithm to take circa 100 milliseconds to hash an IP, then "brute forcing" would be much less of a problem because it would take about 13 years to hash the whole lot.
Or $31,000 on EC2. Are these logs per-request or per-transaction? The former could get awfully expensive.
Of course, checking a single target IP address would be trivial. Whether that matters depends on their threat model.
No, with IP logging it's all-or-nothing. You might as well store them as uint32/uint128.