Verification is an important first step in your online relationship with a user. By verifying that a new registree on your website has the device they claim in their possession (and the provided number is accurate) you reduce spam and fraud while signaling your concern for the user's security.
Overseeing many integrations (and answering many questions), we've come up with a number of best practices and practical guidelines that can assist you while implementing verification. These best practices are also built into our Verify quickstart - we suggest running through it to see some implementation details.
Account verification is an important first step when signing up a user, but should be considered holistically in your application's registration and usage flow. Checking that a phone number is legitimate, associated with a device, and in the possession of a new registrant will cut down on spam sign-ups before you even grant a new user an account.
Our currently suggested signup and usage flow is as follows (only proceed to the next step if the previous step is successful):
- Use Verify (Account Verification) to determine if the user has the device they claim currently in possession.
- If your customer relationship will continue:
- Register the user for continuous Two-factor Authentication usage.
- Require Twilio Two-factor Authentications to protect any combination of log-ins, high-risk operations, and high-value transactions.
While Verify is a simple API, there are a few aspects you can customize.
The Verify API allows you to set the length of the verification token delivered to the new user. You can set the token to between 4 and 10 digits to hit your desired combination of security and user convenience. The API defaults to a token length of 4, and if you are using the API for new account verification, there is little reason to go beyond this number. If however you are using the API for more frequent verification of a user, you might wish to increase token length to increase the possible amount of numbers any hacker needs to guess.
There is a single message template sent out through the SMS channel. The SMS message template contains your Application name from the Twilio Console. The English example is:
Your <App Name> verification code is: 1234
and the message is automatically localized and translated for your users based on their country code. You can override the language by sending in a
locale parameter. The default code (for example, the '1234' above) is generated and validated through our service.
You are only charged for carrier delivery charges and successful customer verifications.
If you already have token validation and generation logic and would like to keep those systems in place, you can do so. We have a feature where you can submit your code to us and utilize our pre-screened message templates and localizations for both text and voice. Contact Twilio Sales and we'll help you enable this option.
There are a few timeouts and limits (and design suggestions) to be aware of when building your Verify integration.
Once generated, tokens are valid for 10 minutes. We are unable to change the timeout for token validity for your application. If your users make another request within the 10 minutes, they will receive the same token. You can poll to see the remaining valid time for a user's request.
To prevent abuse (and impatient users!), we suggest limiting verifications to 1 request per minute per phone number.
We don't guarantee API response times, but most Verify API requests will complete in under 500 milliseconds. With the 10 minute timeout, the majority of the delay you'll see during verification will be user input and not API requests.
Have additional questions about verification and our Verify API? We're very happy to talk best practices, design patterns, future-proofing and everything else that can help secure your app and cut your spam. Contact Twilio Sales and we'll help you optimize your unique Verify implementation.