"It is virtually impossible to deduce the original input from a hash if a strong hashing algorithm is used."
That's just not true when the "original input" is constrained enough, like, for example, a phone number.
It really makes no difference what algorithm you use - if it's fast enough for you to hash all the phone numbers in my contact list on my phone, I can have a set of rainbow tables for every possible phone number. There's just not enough entropy in 10 digit numbers for that to be an effective solution.
You have a valid point, given such a constrained space makes it easier to recover that stuff. For what it's worth, we used salted SHA-1 hashes, which would make it harder if somebody were to get a hold of the data, but of course, it wouldn't prevent us from doing the hash reversal ourselves if we were to turn "evil" some day.
1) you're using a "common salt" across all the hashes, which means I might need to generate my own rainbow tales with your common salt - but for only 10 digits worth of phone-number-space that's probably only a few bucks worth of EC2 time and S3 space to store it.
or 2) you're using a random salt for each phonenumber/hash, in which case you cant identify matching phone numbers.
That's just not true when the "original input" is constrained enough, like, for example, a phone number.
It really makes no difference what algorithm you use - if it's fast enough for you to hash all the phone numbers in my contact list on my phone, I can have a set of rainbow tables for every possible phone number. There's just not enough entropy in 10 digit numbers for that to be an effective solution.