-
Notifications
You must be signed in to change notification settings - Fork 21
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
Comments
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. |
I'm with @bigludo7 here. In TEF we support both and from the WG we should promote full implementation of the APIs |
In the following discussion: 158, simple SHA-256 is used. The phoneNumber is a fixed length pattern: '^+[1-9][0-9]{4,14}$'
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. |
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. |
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
Computing rainbow tables now does not make sense because the random salt is always different. |
Problem description
The NumberVerificationRequestBody can accept one of
phoneNumber
orhashedPhoneNumber
. 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.
The text was updated successfully, but these errors were encountered: