41

Some services (for instance ProtonMail) claim to store hashes of phone numbers, instead of phone numbers themselves (while they don't say how they hash it). Now, given that the number of potentially valid phone numbers is very small (about 26 bits worth of information in an 8-digit phone numbers), it should be quite easy to recover a phone number from its hash.

So what's the point?

Improve this question
7
  • 20
    did you take into account the likelihood of salt and pepper?
    – TheHidden
    Mar 15, 2018 at 14:44
  • 7
    I think the hashing should be seen more as obfuscation in this context. Not irreversible, but still better than nothing.
    – Anders
    Mar 15, 2018 at 15:06
  • 27
    what gives you the idea its 8 digit? phone numbers can have between 3 and 15 digits source E.164 and thats even without the Country code and international prefix ('+'). having 18 digits would yield a lot more than 26 bits of information
    – LvB
    Mar 15, 2018 at 15:44
  • 19
    @TheHidden All the salts and peppers in the world won't change the fact that a 26-bit key space is easily brute forced (in about 67mln hashes). Using a slow hash function helps against brute force; salts and peppers do not (and are not designed to).
    – marcelm
    Mar 15, 2018 at 19:12
  • 1
    Other than preventing employees from taking a quick look at phone numbers, the purpose here is rather marketing than security. But you can’t really blame them, there is no easy solution to this problem. Given what they want to do, this is still (a little bit) better than storing in plaintext.
    – caw
    Mar 15, 2018 at 23:08

4 Answers 4

Reset to default
61

ProtonMail may request your phone number to perform a human check:

  • ProtonMail detects that you're attempting to create several accounts.
  • It requests you a phone number, to send you a token via SMS.
  • You must send that token to ProtonMail to prove you're the phone number owner.

Then, ProtonMail doesn't need your phone number anymore, but it still need to use it to prevent spammers to create multiple accounts.

Hashing the phone number allows it to not store the original number and to prevent someone to use the same number twice.

From their FAQ:

However, using the same phone number will result in obtaining the same cryptographic hash, so by comparing hashes, we can detect re-use of phone number or email addresses for human verification.

Thus ProtonMail doesn't seem to use unique salts.

We also know thanks to a tweet from Bart Butler (ProtonMail CTO) that:

  • ProtonMail regularly flushes stored hashes.
  • Stored hashes aren't linked to any account.

Bart Butler also tweeted:

We use a slow password hash (With a salt) and flush the list and rotate the salt at irregular intervals.

In conclusion: brute-forcing them is possible, but it's neither practical nor useful.

Improve this answer
21
  • 9
    I believe my comment still works with unique salts. (Unique) Salting would obviously deter bruteforcing attempts, but the search space is small enough to consider bruteforcing each entry.
    – Yuriko
    Mar 15, 2018 at 15:18
  • 11
    I think you should remove your claim that brute-forcing them isn't practical, or provide a technical justification for that claim. Based on the description here, it seems likely to me that it is practical. If each hash takes 100ms to compute (which might be an overestimate), you can still enumerate a space of 2^{26} possibilities in 77 CPU-days, which seems practical to me, given that it is trivially parallelizable. That doesn't even take into account possible speedups from GPUs.
    – D.W.
    Mar 15, 2018 at 21:22
  • 9
    @EricTowers, you pick! I can't think of any reasonable threat model where hashing adds much strength. Even a random employee can easily do 77 CPU-days of computation; that's probably a few hundred bucks on Amazon EC2 (or possibly free on their home machine if they have a nice GPU, maybe). Can you identify a non-trivial adversary (a reasonable threat model) and a security property that is achieved when ProtonMail hashes, but isn't achieved when they don't hash? Looks to me like hashing provides security only against very weak adversaries with little computation power.
    – D.W.
    Mar 15, 2018 at 23:35
  • 7
    Seems to me that's exactly the point raised in the question, and I don't see how this answer is responsive to that point. Seems to me like any security that is gained is mostly attributable to periodically flushing data and not linking the data to accounts, rather than by hashing; hashing doesn't seem to add all that much.
    – D.W.
    Mar 15, 2018 at 23:36
  • 12
    @D.W. the hash is still useful for social reasons. Putting up any barriers to viewing the real phone number will help keep honest people honest. Sure this hashing setup may not help much against a determined attacker, but it still removes immediate temptation for a random employee to abuse the system. Hashing (even a weak hash) draws a clear line in the sand for an employee for what is acceptable to view.
    – ryanyuyu
    Mar 16, 2018 at 13:13
10

The hash is useful as an indirect map, even if it's not as secure as a typical hashing setup. One of the biggest benefits is purely social. Hashing (even a weak hash) draws a clear line in the sand for an employee about what is acceptable to view. Putting up any barriers to viewing the real phone number will help keep honest people honest.

it should be quite easy to recover a phone number from its hash

Easy is a relative term. True, this hashing setup may not help much against a determined attacker who is willing to perform hash cracking. But you also have to think of the 99% of other employees with access to the data who don't even know what a hash really is, let alone how to crack them.

Improve this answer
2
  • 2
    That's a good point: even if it only adds a minor technical barrier for someone knowledgeable, it is enough of a social deterrent to be useful. Kind of like a (regular) fence.
    – BlenderBender
    Mar 17, 2018 at 0:09
  • 3
    @BlenderBender: Indeed! And that's a really important point. We hear here over and over again how security by obfuscation is useless to the point of being better omitted, yet everybody I know has a thin slice of wood around their garden. It's trivial to see over it, and provides no real privacy, and certainly no real security. But it does send a message: "this is my space and if you enter it you must have willfully violated my terms". Hashing a phone number, while maybe cryptographically useless does the same thing in the context of employees glancing at the DB. That is not entirely useless.
    – Lightness Races in Orbit
    Mar 18, 2018 at 4:25
6

The point is to not store them in plaintext.

That is probably pretty much it. As D.W. pointed out in his comments, that Benoit's answer, tells you their reason why they store phone numbers and that they hash them. ProtonMail does not tell you why they hash them. We all can only speculate about this, until an employee of ProtonMail tells us the exact reason.

The most probable reason is (in my opinion) is the following:

ProtonMail is a company whose whole business model is founded on secure products and protecting a customer's privacy. If they told you, that they saved phone numbers in plaintext, that would be pretty weird. Hashing them makes much more sense in that regard, don't you think?
On the other hand, ProtonMail doesn't link phone number hashes to user profiles, they flush the hashes regularly and as you stated yourself, there's not much to gain from a phone number.

Hashing phone numbers if they have to store them is better than not hashing them. That's why they do it.
Does it strengthen security much? No.
Is it better than storing them in plaintext? Yes.

Improve this answer
1

There are two reasons for storing hashed phone numbers, one is useful the other one is not:

1) Allow to verify the user. Here a salted slow hash is useful. While brute-forcing a phone number is faster than a password, it still provides added security.

2) Pretend to provide a more safe lookup (i.e. in several of whatsapp competitors). Here you cannot salt the hash, because you would not be able to search for the hash when only knowing the phone number. This means a rainbow table is easy to create as the search space of unsalted hashes is really small.

Note that 1) still provides an easy proof of existence when you have the database. Hash your phone number with all the salts used in the database and look it up. If it is stored in there, you will find it.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .