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.
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.
> 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’.
Try reading the rest of the Wikipedia article beyond the first paragraph. Particularly the section on ‘shared-secret pepper’ and ‘unique pepper per user’.
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.