Is it easy to crack a hashed phone number?

Question

I want to SHA256 hash phone numbers in order to hide them. Is this a good idea? Are there any other ways I could make this safe?

Answer 1

No, it is not a good idea to hash phone numbers. There are only a limited number of phone numbers, so it is pretty easy for an adversary to try and hash all of them. Then you can simply compare the hash of each with the stored hash. Generally you don't have to deal with all telephone numbers, only a subsection of phone numbers anyway (for a specific country or other group that is logically distinct).

You could use a slow password hash with salt and work factor, but that's only going to mean that time time required is multiplied by a large, constant value. It won't change the order of operations. If the subset is small enough it may not deter an adversary to perform all necessary calculations.

In this case you will probably need to encrypt the phone numbers instead. Or use a keyed hash such as HMAC. For both options you need to perform key management on the secret key though; it's not as easy as just hashing the number.

Answer 2

In the general sense, The problem is known as the small input space on the hash functions, and in short simple hashing won't be secure.

If you hash data ( here a phone number) and an attacker tries to find an input value that matches the hash value is called the pre-image attack. In a secure Cryptographic hash functions pre-image attack requires $\mathcal{O}(2^n)$-time where the $n$ is the output size of the hash function and in SHA256 $n=256$

If the input space is small, this gives an attacker a huge boost, that is they can only brute force the small space. If 10 digit phone numbers are stored then the attackers need to search only $\approx 2^{34}$-space and if 15 that can make only $\approx 2^{50}$. Even the last space is highly achievable with a good GPU, see the hashcat performance. Therefore one needs either a way to slow the attacker or make it harder.

• To make the attack slower, slow and memory-hard hash functions can be preferred like the Scrypt or Argon2id. This amount can be adjusted according to the target's capabilities. For example, using 100K iteration will slow the attacker time 100K or will reduce their search space capabilities within a limited time approx by $2^{16}$. As upper computing power, the collective power of the Bitcoin miners can reach $\approx 2^{92}$ double SHA256 in a year. If your enemy has this power slowing will not help much.

  Another choice is using salt per data as stated in the answers together with slow and memory-hard hash functions. This will only slow the attack time and prevent pre-computed tables like the rainbow tables. The attacker's execution time will increase by the number of the target hashes.

• To make it harder, HMAC can be preferred, This is a keyed hash function and can be initialized with SHA256, too. The attacker without the key has no luck to attack the hash value. Another way is encryption. Although the phone numbers are should be unique, if one uses ECB mode that can be used to mount some attack to identify the number. The attackers can register and enter a target phone number as their phone number to identify the target position on the database. Therefore, an Ind-CPA secure mode should be preferred like CBC or CTR.

Both HMAC and Encryption have an additional problem to be solved. The storage of the keys. For this Hardware Secure Modules (HSM) can be preferred. The keys cannot be extracted from the modules and the HMAC and Encryption can be performed over these devices. If the attackers access the application server that uses the HSM the only hope is that they have limited access to use the HSM as a slave.

Conclusion: Use encryption or HMAC. If one fears of the loss or access of the keys use HSM to store and execute the Encryption/HMAC on HSMs.

Answer 3

It is always a bad idea to hash data that has a limited set of length or characters.

A phone number in Germany for example has normally no more than 12 digits. The first digit is always a 0 and the vast majority of numbers is longer as 3 digits, as those are normally reserved for emergency services.

This effectively leaves us with 10^11-10^3 possible combinations. The amount of time required for brute forcing this amount of combinations greatly depends on the used algorithm.

When using MD5 which is absolutely insecure to use nowadays, cracked by 8x Nvidia GTX 1080's and Hashcat, this is done in less than 10 minutes. Unfortunately, according to my experience, there are still thousands if not millions of services, hashing even passwords with insecure algorithms.

E.g. when using bcrypt, you could slow this down by a factor of more than 2000, however, this would still be incredibly insecure. And normally, the cost needs to be set according to the backend perfomance requirements as well. If an attacker could guess the location of the phone numbers to crack, it would be a matter of seconds.

You have the same problem when trying to hash IP addresses, it's also not a secure way to hide the plaintext.

Answer 4

As an alternative, you can salt the phone numbers to avoid pre-calculation attacks.

A known salt will help against an adversary who has already done a hash of all possible phone numbers but just adds one order of magnitude of work (the adversary just has to recalculate all the hashs with the salted phone numbers).

If you can keep the salt private raises the bar on brute force attacks (essentially you are adding the salt's bits of entropy to the entropy inherent in the phone numbers).

Answer 5

An alternative is to encrypt the phone number as proposed in the previous answers. For example, Mobile connect identity service encrypts the MSISDN (aka phone number) using a specific algorithm.

This GSMA specification gives information about decoding the payload :

Following are the example of encrypted MSISDN passed:

• with URL encoding:

    login_hint=ENCR_MSISDN%3A0bb3020c7758f34e012da3f0bf13dc7674b3a9527
    6e804388d5aae4a034fe442a65e03027d0651da3b0646df6c11d3c5d6f46879480b
    623bd5024d9e0879727f46fbd1e8f5383a115678ea638a4ba5399a2dd37138246e
    db06718bb44be98f5331a1331902d6333993642e2f25197961ee0b0a14ddf66083
    4d49f7f385d82cad5a12003cd8aa235a92b71589110d76df382eab80b12a8dfa6d0
    5b4ca548538ac4b09a2868448957604eb52b1ceecc89dfe836e7113e51645c2a14f
    ff900228a8475983435647e88552a96eb692685b12abfc7ae0ad2bc23d30b3c8d82
    8ca101e186455b4d618a8c9022662ee1c5b8ffea40defdb92a20dce39bdbedcbf78
    5a2e
  

• The serving operator recognises the input of the encrypted MSISDN and decodes the base64 encoded data.

• The serving operator applies their private key to decode the RSA coded data.

• The decrypted string looks like 441234567890|dasd23231139dskdeirirewr0234043ekewrwe4034c.

• The serving operator then extracts the initial (numeric) portion of the decrypted data as the MSISDN separated by (|) pipe and uses this for any relevant purpose in API services/user sign-in.

In this case, it uses RSA encryption, and the private key is only known by the Mobile Network Operator

So an implementation would be :

base64(encrypt(44123456789|randomString))