¹

Having a One-Time-Password (OTP) flow for your app or website is a very common requirement nowadays.

But how does it work? What do you need to get started? What are the pitfalls and challenges you will face?

We’ve seen our clients roll out their implementations countless times, which basically is a boilerplate repeatable process that has cost companies and developers thousands of hours and dollars. GetOTP was built to ease the burden of developers and free them from this repeatable process, and also to reduce maintenance costs that come with it.

In a series of blog posts, I will attempt to explain what OTP is, why it is a common requirement and what you need to do to implement it for your own websites.

What is OTP?

OTP stands for One-Time-Password or One-Time-PIN and is a one time or single use password used to login into a computer system, commonly online. Using OTPs is commonly considered a more secure way of logging in into a system as opposed to using a saved password, because the OTPs are not vulnerable to so-called “replay attacks”. Due to its nature, different systems also will have different OTPs, so if one system was broken into, other systems would still be safe.

Is OTP more secure than normal passwords?

Generally yes.

²

Nowadays, it is common to see OTP being used as part of a 2-Factor Authentication process, also known as 2FA. With OTP being one factor as “something that you know”, 2FA adds an extra layer of security by having another factor of “something that you have”. This can be a mobile phone, an email account or a security token which you carry around. Because of these 2 factors needed, that is why it is called 2-factor authentication.

OK, so how does OTP work for my website?

If you’re reading this post, chances are you are looking to implement OTP in the context of a 2FA flow for your website. As written above, this is a very common usage of OTP, and most commonly used when registering a new customer or user to a particular website.

You can separate the implementation into 3 big parts:

• Initial preparation part on your servers
• Sending of the OTP via communication channels
• Receiving the OTP from the customer and verifying it

We’ll go through a general overview of the steps needed to implement a 2FA authentication flow using OTP for your website below.

My intention in these post is to show the logic and steps that you’ll need to take, and as much as possible I will not be using code so these steps can be understood by as many people as possible.

Initial preparations on your servers

Before we start sending one time passwords (OTP) to your end users, you’ll need to have a way to generate the OTPs that your end customers will verify with.

Generate an OTP with good user experience

This is usually a string of 4 or 6 digits which you will randomly generate. To be fair, the string doesn’t have to be digits, but digits makes it easier to input on a user interface, and it will also be possible to also use the phone to authenticate the OTP.

I would suggest a maximum of 6 digits for your OTP, which is an easy amount of digits to remember based on Miller’s Law and makes for a good user experience.

Connect your OTPs to other data

When an OTP is generated, you’ll need to tie it to the end user’s account so that you’ll know who is verified when the OTP was correctly entered. It is also a good idea to put a usable time limit on the generated OTP (also known as TOTP or Time Based One Time Password).

Be careful that you do not use the same OTP to verify multiple persons at the same time because it will be confusing to determine which person was verified with a particular OTP. You should also not recycle your OTPs because that will make them vulnerable to so-called replay attacks.

If you want to know more about the nitty gritty details of generating a secure OTP, RFC4226 published by the Internet Engineering Task Force (IETF) might be an interesting read for you.

Finally, you’ll need to get the information on where to send the OTP to, where your customers can access it. This can be an email address, a mobile number, a phone number or even a mailing address of the person you’d like to verify. You can commonly do this via a form on your website or your mobile application.

This is where you then tie the email address, phone number or mailing address, with the OTP and the customer data in your database.

This part of the process is not that particularly difficult, and usually can be done within a half-day by a decently competent developer.

Now you have the OTP to verify a customer with, the next part of the process is to decide how you would like to send the OTP out.

There are multiple channels or ways which you can send the OTP to your customer for verification. Which you use depends on the needs of your business, and also what is available for your customer. The most common ones are email, SMS and also voice calls.

What are the differences between email, SMS and voice calls?

Email as a channel

Email is the most common channel that can be used, and is also commonly used as your userid when signing up to services on the internet.

Because email is really common as a channel for communication and is also used for marketing, chances are that your service would also want to collect your customer’s email.

Pros

• If you have an internet connection, getting an email address is free and easy to do. It is safe to assume that nearly all your customers will have an email address
• Sending email address costs next to nothing.
• Asynchronous: There is some lag time when the OTP is received and needs to be used. This can be good for user experience.

Cons

• Getting an email address can be too easy because nearly all the time it does not include any verification of identification.
• Some email providers allow automated processing of their emails, which can lead to so called bot manipulating with your OTP

SMS as a channel

Short Message Service or SMS is becoming another common way for web services to register and authenticate their customers.

Pros

• Sending a SMS to a phone number impllicitly implies that the recipient has the phone number physically
• SMS, like email, are stored on the phone and can be referred to later
• There is a common understanding that one person has access to one moblie phone number, which acts as a very loose way of identifying people
• Just like email, this is an asynchronous channel and can be good for user experience.

Cons

• Sending SMS for your OTP is not free. Carrier charge for usage of their networks.
• The common understanding that one person has access to one mobile number is untrue. Some people will have more than one mobile numbers, and some might not even have one but use so-called online free SMS numbers to receive SMS.

How about voice calls?

Finally, we have voice calls. Voice calls are less common than the other two channels above, but can be the more effective way to make sure that someone actually has possesion and can be reachable at a particular number.

Pros

• Voice calls are not limited to mobile phones only. This channel can also be used for landlines to homes and offices.
• Voice calls are a synchronous medium. The authentication over voice calls must be done during the call itself, unlike email or SMS which are asynchronous. This channel can be a stronger than email or SMS way to make sure that the recipient of the OTP has physical access to the particular number.

Cons

• Because voice calls are a synchronous medium, it has lesser user experience than email or SMS. The recipient needs to be ready to accept and respond to the voice calls.

One channel I’m not covering in this post is the physical mail channel. It is also possible to include your OTP in a physical mail and send it out. The recipient will receive the mail, and input the enclosed OTP. If you business requires certainty that a particular recipient can be reachable at a particular physical address, this is the only way to do it. Some jurisdictions requires that their banks do this as part of their Know Your Customer or KYC requirements.

In my next post, I will go into the details of the actual sending of the OTP via these different channels, and verification of the OTPs.