In this article I explain how I built the user registration system for FaxDroid. The system had several additional requirements on top of the actual registration process:

• In order to prevent fraud and duplicate accounts, users would need to verify their mobile number. This was done using Twilio Verify.
• To prevent bots and also as another measure against fraud Google ReCaptcha V3 was used to provide a risk score for each user. Users who’s risk score exceeded a certain value would not be allowed to register.
• The service was geo restricted to certain locations. This meant that both the IP address and the users mobile number country code would be checked to ensure it falls in the supported regions.
• To prevent throw away mobile numbers from being used for verification, each phone number would be cross checked with Telesigns fraud score service. High risk numbers would not be allowed to register.

Implementing this system consisted of:

• Design and Development of the UI
• Developing the back end server
• Integration with IpStack, Twilio, Telesign and Google ReCaptcha V3.

---

User flow

In this section I explain what the registration process looks like from an end users perspective. In the following section the implementation details are explained.

User Information Form

When the user decides to open an account they will first visit the user registration page. Here they would need to enter their name, email address and a password. Upon entering this information initial checks are performed:

• Is the email address well formed? Has it been taken?
• Are the passwords strong enough? Do they match?

 

Entering Mobile Number

In the next page users will be asked to provide a mobile number that will be used for text verification. A text message will be sent with a verification code. Proper warning signs are shown if the number is from an unsupported region or the number has already been taken:

Completing Mobile Verification

On the next page users are asked to enter the verification code they received on their mobile device. Special verification checks are performed on the back end to esnure throw away mobile numbers are not used:

Registration Complete

Once registration is complete the user will be logged in and provided with a greeting message.

---

Implementation

In the previous section I explained how the registration section works from a users point of view. In this section I explain how things work under the hood.

User Information Form

(Read user flow explanation)

In this stage the user provides their email address, name and password. Several different checks are performed on the provided information.

Validation on the UI: Before sending this information to the server a basic validation is performed on the UI. The following is checked:

• Missing fields
• Wrong email format
• Mismatching passwords
• Passwords that are not secure enough

The reason for performing these validations on the UI is to create a better user experience. This is in contrast to sending the response to the server, performing validation and then sending a response back to the UI letting the user know some of the provided information is invalid.

Basic validation on the server: The information is passed to the server. The same validations are repeated. The reason for repeating the validation is to prevent malicious users trying to bypass the UI verification.

Duplicate email check: The email address is checked to see if an account with that address already exists.

Geo restriction check: As the service is only available in certain regions, the users IP address is queried using Ipstack. The geolocation data of the IP address is checked to see if it matches the supported region.

If all the checks above pass the user will be redirected to the next page which requires them to enter their phone number.

---

Entering Mobile Number:

(Read user flow explanation)

In this stage users are asked to enter their mobile number. A text message will be sent out to the provided number with a verification code. There are several different verifications that happen on the backend.

Duplicate phone number check: In order to prevent users from opening multiple accounts using the same mobile number, a check is performed to see if any previous accounts were opened with this number.

Captcha score check: Google Recaptcha V3 can be used to provide a fraud score. This score is based on various factors (not all details released by google), however some of the factors include:

• Users IP reputations
• Users behavior both on and off the website

The higher the score, the less risky the user. In my experience 99.9% of legitimate users have a captcha score of 0.7+. If a user has a captcha score of less than 0.7 the user is blocked.

Geo restricted mobile numbers: As mentioned earlier the service is geo restricted. This takes into account not only the IP address of the user but also the mobile number being used to perform verification. The provided number is sent to Twilio lookup. Twilio lookup will provide two sets of information:

• Determines if the number valid
• The country code for the number

When working with phone number I generally found that it’s best not to rely on regexes but rather use an external service like Twilio to accurately determine the country code. The country code provided by Twilio is checked to see if it falls in the supported regions and only then will this check pass.

If all checks pass successfully a call is made to Twilio Verify. Twilio verify will send a one time verification code to the mobile number. Once the verification code is sent out the user is redirected to the next page which they must enter the verification code.

 

---

Completing Mobile Verification

(Read user flow explanation)
On the final page the user will enter the code they received on their phone. The code is sent to Twilio for verification. Twilio will confirm if the entered code was correct or not.

As explained in Fraud Prevention Techniques sms verification alone is not very effective. There are plenty of websites that provide throw away text numbers. In order to prevent the use of such numbers, Telesign’s phone score is used. High scores indicate the possibility of being a throw away number. If the score returned by Telesign exceeds a certain threshold the user will be notified that their number can’t be used for verification.

Also in order to prevent unnecessary API calls to Telesign an internal cache of previous lookups is created. Only if a result was not found in the cache will a call be made to Telesign. 

If all verifications pass, the user will be registered and logged in to their dashboard.

 

---

Skills

• Symfony + Php
• MySql + Doctrine
• Angular IO
• Integration with various dependencies (Google Recaptcha V3, Twilio Verify & Lookup, Telesign Fraud Score, IpStack