Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Phone number verify] Is it mandatory to implement both hashedPhoneNumber and plain text phoneNumber? #155

Open
trehman-gsma opened this issue Nov 6, 2024 · 5 comments
Labels
documentation Improvements or additions to documentation

Comments

@trehman-gsma
Copy link
Collaborator

Problem description
The NumberVerificationRequestBody can accept one of phoneNumber or hashedPhoneNumber. Is it mandatory for API implementations to support both?

For example, could an implementation only support hashedPhoneNumber?

Expected action
Clarify the documentation with more definitive language. We have encountered at least one operator who interpreted the specification as only requiring support for one of the options.

@trehman-gsma trehman-gsma added the documentation Improvements or additions to documentation label Nov 6, 2024
@bigludo7
Copy link
Collaborator

bigludo7 commented Nov 6, 2024

My understanding is that we have to provide both but happy to hear from other.

I'm generally not confortable to provide partial implementation to avoid developer deception... except when local regulation prevent us to provide complete implementation.

@trehman-gsma trehman-gsma changed the title Is it mandatory to implement both hashedPhoneNumber and plain text phoneNumber? [Phone number verify] Is it mandatory to implement both hashedPhoneNumber and plain text phoneNumber? Nov 6, 2024
@fernandopradocabrillo
Copy link
Collaborator

fernandopradocabrillo commented Nov 7, 2024

I'm with @bigludo7 here. In TEF we support both and from the WG we should promote full implementation of the APIs

@mhfoo
Copy link
Collaborator

mhfoo commented Dec 5, 2024

In the following discussion: 158, simple SHA-256 is used.

The phoneNumber is a fixed length pattern: '^+[1-9][0-9]{4,14}$'
In Singapore, there is a numbering plan governed by the regulators, where the Singapore mobile numbers are allocated the following ranges (prefixed with country code for completeness, 8-digit phone number):

  • +659xxxxxxx
  • +658xxxxxxx

Based on the above ranges and using simple SHA-256, a rainbow table can be generated to "decode" and determine the actual phone number.

This does not give us any benefit to implement hashing.

@eric-murray
Copy link

This does not give us any benefit to implement hashing

This was discussed before in the context of simplifying the hashing requirements. It was generally agreed that hashing these days provides no real privacy benefit from a determined hacker, but as removing the hashing option completely was not the purpose of that issue, that was never progressed.

As long as the hashing option exists, there is an expectation that it is supported. From a privacy point of view, it is still preferred as it prevents casual inspection of any HTTP logs (e.g. inside the organisation). This is a minor benefit, but a benefit nonetheless.

@AxelNennker
Copy link
Collaborator

In the following discussion: 158, simple SHA-256 is used.

The phoneNumber is a fixed length pattern: '^+[1-9][0-9]{4,14}$' In Singapore, there is a numbering plan governed by the regulators, where the Singapore mobile numbers are allocated the following ranges (prefixed with country code for completeness, 8-digit phone number):

* +659xxxxxxx

* +658xxxxxxx

Based on the above ranges and using simple SHA-256, a rainbow table can be generated to "decode" and determine the actual phone number.

This does not give us any benefit to implement hashing.

The usual answer to rainbow table is to include a salt.

hashedPhoneNumber = salt:HASH(salt | phoneNumber)

The enduser enters their phoneNumber into the API consumers mobile application (acma): +659012345
// The mobile application gets an operator token using sim-based authentication
The acma create a random salt: 0qnMSnqgiuQZJmuaGINEDltEq1M0ion2
The acma computes the hash: b23c5ac457e289880548fe9eed7c09e9689b349152a59d8e67ad08bb131f657d = SHA256(0qnMSnqgiuQZJmuaGINEDltEq1M0ion2+659012345)
The acma sends the NumberVerification request with hashedPhoneNumber =
0qnMSnqgiuQZJmuaGINEDltEq1M0ion2:b23c5ac457e289880548fe9eed7c09e9689b349152a59d8e67ad08bb131f657d
The MNO splits hashedPhoneNumber at ':' and gets

  • salt = 0qnMSnqgiuQZJmuaGINEDltEq1M0ion2
  • hash = b23c5ac457e289880548fe9eed7c09e9689b349152a59d8e67ad08bb131f657d
    The MNO knows the MSISDN of the requesting device: +659012345
    The MNO computes b23c5ac457e289880548fe9eed7c09e9689b349152a59d8e67ad08bb131f657d = SHA256(0qnMSnqgiuQZJmuaGINEDltEq1M0ion2+659012345)
    The MNO compares the input hashedPhoneNumber to the computed hash and returns the result.

Computing rainbow tables now does not make sense because the random salt is always different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

6 participants