Hash phone number

[oscarb]

To allow the user to see which contacts are also users of Flowlist contact phone numbers needs to be stored on the backend along with a user id.

To respect user privacy and avoid leaking sensitive data, the phone number of a user should not be stored in a readable format on the back-end. A solution would be to hash the phone number.

However, as phone numbers follow a limited pattern, lookup tables can easily be generated.

How can phone numbers be hashed to reduce the risk of an attacker resolving the phone number behind the hash?

[oscarb]

Similar topics:

• Don't use phone number hashes in JID · Issue #497 · kontalk/androidclient

[oscarb]

Using a salt would increase the "strength" of the hash. However there are two situations where the phone number is used in different contexts:

• As Adam signs up for the service, his phone number is hashed, sent and stored on the back-end with a user ID.
• When Eve wants to share a link using the app, the app will have to go through Eve's contacts to display other users of Flowlist. For each contact the app will have to hash the phone number and then check if it exists in the back-end.

Therefore, a salt needs to be based on information available to both Adam and Eve. In this case, other than the phone number the name of the user could be shared. However, if Eve has named Adam something else in her phonebook, e.g. "Adam at Work", then a common salt can not be generated.

[oscarb]

A secret salt could be stored on the server to increase the strength of the hash. Then every phone number would be hashed like

phoneNumberHash = hashFunction(SECRET_SALT + phoneNumber)

This solution would be as secure as the salt is secret.

[oscarb]

Another solution would be to base the salt on information about the phone number (as the phone number of Adam is the only information available to both Adam and Eve).

For example, if the country code of the phone number can be retrieved, the salt could be based on that.

phoneNumber = "+46123456789"
countryCode = getCountryCode(phoneNumber) // +46
individualSalt = getCountryName(countryCode) // Sweden
phoneNumberHash = hashFunction(individualSalt + phoneNumber)

This could then be combined with a secret salt, e.g:

phoneNumberHash(individualSalt + SECRET_SALT + phoneNumber)

Would this approach make it difficult enough to generate lookup tables so that the hashes can be stored on the back-end without the risk of exposing users phone numbers?

[dbosk]

If you base the salt on a part of the phone number (e.g. country code), then it is no better than just the phone number. To add any value, it must be independent from the phone number, e.g. the name (which causes problems as you mentioned above).

You can have a secret salt (one salt per phone number, same as for passwords), then you'd protect the list of registered phone numbers. But each user must submit the contact list in plaintext, as it's only the server who has the salts required for the hashing.

This is not an easily solved problem, see Difficulty of Private Contact Discovery. But we're working on it ;-)

[dbosk]

Just to try to think of other solutions: why do you want to allow anyone with your phone number to send stuff to your reading lists? Do you want anyone with your email address to put emails in your inbox? (I'm thinking of all those emails that you now have to filter to your spam folder, which is a bad solution already from the start.)

A solution for this would be a secure and usable identity manager which is fully decentralized. I think that one of the main problems facing Signal (in the above article) is that it's a centralized solution. The same applies to your thinking above, it's a centralized solution. I'll get back to you with a suggestion.

[dbosk]

You can probably change the title of this issue to "contact discovery".

[oscarb]

Note to self - look into this for hashing: https://github.com/jdconley/pwhaas

[dbosk]

I looked at this one only quickly. Interesting idea, but I'm not entirely comfortable with it yet.

On Sun 04 Jun 2017 14:37:16 GMT, Oscar Björkman wrote:

Note to self - look into this for hashing: https://github.com/jdconley/pwhaas

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/oscarb/flowlist/issues/7#issuecomment-306068749

[dbosk]

And it will not help you for the case of phone numbers: there are too few of them, so brute force works.

[oscarb]

https://github.com/SilentCircle/contact-discovery

Interesting read, needs further investigation if this would be suitable for Flowlist.

[oscarb]

Solution

The solution I will move forward with is to not hash the phone numbers of users. Instead Flowlist will limit the phone numbers that are transferred from the contact book to only those necessary. Any transfer of phone numbers is done over HTTPS.

Discussion

Pros

• The solution is future-proof in that sense that while a better solution might turn up later, this solution keeps the phone numbers available in plain text on the backend so it is easy to manipulate and convert it to whatever a better solution might require. Converting the phone numbers to something irreversible at this point might turn out to be a bad idea unless the approach is fully thought out.
• Statistics regarding where users use the app can be extracted from the phones country number
• The phone number of a sender can be made available to the client so that a user might see what phone number a link originated from whenever that phone number is not among the users contacts
• It makes everything easier - no need to traverse through the a users contact book to create mappings from raw phone numbers to whatever they're represented as in the backend
• Flowlist will securely transmit only the phone numbers of the users the user is sharing links with
  • Privacy for all contacts not using Flowlist is therefore considered
  • Less data usage

Cons

• A users phone number is still available in raw plain text in the database

Flow

Sign up

• When Adam uses Flowlist for the first time, Adams phone number is verified and stored in the backend database.
  • No other personal or identifying information is stored for Adam
  • The phone number is securely transmitted from the verifying server to the Flowlist backend during sign up.

Sharing links

• Adam selects contacts in his contact book to share a link with
• The app will then check for these numbers, and these only, if they are users of Flowlist.
  • Any contacts available on Flowlist is added to a local list that appears first in the contact picker when sharing links
  • For any contact that is not a user of Flowlist, Adam can choose to either
  • share the link and it will be stored along that phone number until the person signs up and the phone number is converted to that persons username. Needs to investigate further if it's a good or bad idea to have links waiting for a person.
  • not share the link.

Getting links

• If the received link is from a user that Adam has already shared a link with, then the user id of the sending user can be mapped to a contact in Adams contact book using a local list
• If not then Adam will get the phone number to verify the identity of the sending user using Adams contact book
  • If the user is not among Adams contacts, the app should either not display the link at all or display the senders phone number (this needs to be discussed further)

Flowlist Web

At first Adam should be able to login and see his lists by verifying his phone number. Photos and names will not be available for the senders of the links, neither will Adam be able to send links using the web version.

Adam should be able to either

• login with Facebook and opt in so that phone numbers of senders can be matched with Adams Facebook contacts. Names and photos of the senders can then be displayed in the web version.
• in the Flowlist app choose to sync names and photos of people he has shared links with to the Flowlist backend.