While a secret salt is effective in the short term, it's an un-rotatable value. Which means, if the salt gets leaked, you are screwed (or rebuilding the entire table by brute forcing it, or adding another layer of salting - not great!).

For a company operating at Facebook's scale, with their kind of scrutiny around handling PII, this is unfortunately functionally useless.

For some data types where hashing isn't super effective, and where associative identifying information is attached (such as a user id), a more effective mechanism might be to encrypt the data with a strong random value appended, and decrypt to do the lookup. This would require a correctly provisioned HSM to do properly - the private key secrets should NEVER be exported.

While hashing seems like a good idea, it's actually particularly and deceptively tricky for these kinds of use cases.

If you salt, then either you can't lookup a number, or you've only changed the problem to: iterate over all the possible phone numbers, _add the salt_ and hash them. No big difference.

The salt doesn't buy you anything, given that Facebook also knows the salt.

There are only about 3 billion valid US phone numbers. How many hashes can your GPU compute per second?

How could I match an incoming unhashed value to an existing salted hash?