0

I wanted to verify phone numbers before using them for communication with registred users. However, I am unclear If I'm doing it securely. i.e

Steps I'm taking:

  1. Ask user for phone number
  2. Send SMS verification code
  3. User enters Code
  4. Code verified using SMS Service(Sinch or/Twilio)
  5. correct code triggers callback function(client side) that adds the number to backend Database
  6. Incorrect code does nothing

My concern is step 5. Should I have the success callback function perform the number save on client side or should I trigger some backend(server-side) function that performs the save operation?

jasan
  • 11,475
  • 22
  • 57
  • 97
  • The use of such a "shared secret" can usually be secured with Firebase's security rules. What process determines the verification code in step 2? – Frank van Puffelen Nov 03 '16 at 02:57
  • The correct code is never disclosed, the SMS service(Twilio / Sinch) generate the code and send it , then when the user enters the code , I call a function for the SMS service backend to verify the entered. I never have access to the code. if it does I get a success callback from the service. – jasan Nov 03 '16 at 03:05
  • Ah... so the number on step 5 is the phone number? In that it sounds like Twilio has secured the flow. What's your concern? – Frank van Puffelen Nov 03 '16 at 04:13
  • yes, the number refers to the phone number in step 5. My concern was that I do not want to allow phone number to be added to the database unless the phone number has been verified. If I set security rules to only allow write operation to phone number node ` auth.uid === $uid` then can't the logged in user still write a unverified phone number to that location? – jasan Nov 03 '16 at 04:35
  • That is correct. So indeed you should not allow that location to be written by regular users. – Frank van Puffelen Nov 03 '16 at 13:50

2 Answers2

0

So with sinch it works like this, all the steps 1 to 6 is correct on the client. side,

But step 5/6 is more like this 5 Client enters code and send it to Sinch Backend - Return to client with Success or Fail (do ui logic) - Make a callback to your server with status, take action if correct or incorrect.

So the code is never in your possession, injecting the add to database on client side not possible, since you can get Success to the client and then in the client reload you data from your backend that has been updated by the server to server method. Makes sense?

https://www.sinch.com/docs/verification/rest/#howtousetheverificationapis

cjensen
  • 2,703
  • 1
  • 16
  • 15
  • I don't understand the second paragraph. Let me confirm if I understand this: so is the verification success callback from Sinch to the client is just for the purposes of the Client side UI logic? And Not to be trusted to make a post to by applications backend with the phoneNumber? There is a separate webhook that I should use to write data to my firebase database? If so how d oI pass my users UID and other data along with ttaht webhook. – jasan Nov 03 '16 at 05:48
  • i.e: using verify(code, success, fail) --> the success callback from this function is only for client side ui logic. whereas I should configure a callback URL for verification in Sinch Dashboard?t – jasan Nov 03 '16 at 06:10
  • Yes, you should also have a backend part to secure it more – cjensen Nov 07 '16 at 19:58
0

Twilio developer evangelist here.

I'd definitely do the code verification on the server side and then if that is successful save the number to the database. Any verification and success callbacks on the client side could surely be bypassed by an attacker with knowledge of JavaScript.

Rather than using Twilio directly for this, might I suggest you check out Authy's phone verification API. Authy is part of Twilio, but is more specific to verification and two factor authentication workflows.

I'm not sure what your backend is written in, however there are tutorials for verifying a phone number with Authy on the Twilio site. We have examples in Node, Ruby, Python, .NET, PHP and Java.

I'm not sure if this helps at all. Let me know if you have any other questions.

philnash
  • 70,667
  • 10
  • 60
  • 88