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.
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.