2 Factor Authentication: The Tester’s Edition

2 Factor Authentication is a subset of the multi factor authentication service that we see mainly in FinTech Apps.

Some financial technology apps ask the user to enter a password, and MPIN, a TPIN, and finally another OTP based authentication to confirm if he/she really wants to withdraw money from their schemes. 

While 2 Factor authentication may have some vulnerabilities, using a multi factor authentication system like the above will result in users fleeing your application in pursuit of simpler systems. The challenge here is to make user transactions secure and easy at the same time. That’s when 2 Factor authentication or 2FA becomes useful. 

In a 2FA system, a user has to enter a password and an OTP or a code obtained from a different app. 

In this article, we will only discuss testing the OTP based authentication for obvious reasons. We cannot test third-party mobile apps like Twilio Authy or Google Authenticator. 

As a first step, we will understand what 2FA is, how it works, is it vulnerable to attacks? 

And then we will move on to learning how to test 2 Factor Authentication.

Finally, we will also talk about how Testsigma can help you perform automated testing for 2FA. 

See how Testsigma lets you automate 2FA live

How to test 2 Factor Authentication based systems

Definition of 2 Factor Authentication : Authentication by means of both – a password and an OTP. 

Steps

1. User goes to a workflow that requires authentication, the most common example is a login form.

2. The user enters the username or provides some other information for authentication to begin.

3. The user enters a password corresponding to the information given in step 2

4. The application prompts for an OTP that is sent to the user’s mobile number. This mobile number is usually stored by an application during user registration.

5. The OTP is fetched from an SMS received on the mobile number and is automatically inserted into the OTP input field or user enters it manually.

Challenges during test automation for 2 Factor Authentication

• For 2 Factor authentication to work, an external phone number is needed to send OTP via SMS
• Integrating an external number to an automated test is usually not feasible, thus picking up the OTP from an end user’s phone becomes a challenge
• Many organizations disable OTP authentication in all servers except production in order to run other tests. Thus, 2FA testing is skipped.

The Questions

Can you really automate the process of OTP based authentication under 2FA?

Yes

Using traditional methods, is it easy to scale the automation process for 2FA?

No

Use Cases – How should the 2 Factor Authentication feature function?

Let us understand a few use cases to test:

1. A user sends a request for OTP (via the application that requires authentication), the app sends the OTP via SMS, OTP gets verified for successful authentication

2. A user sends multiple requests for an OTP over a fixed interval of time, the app sends back the response as – ‘HTTP 429 error’  which translates to “too many requests”

3. A user sends repeated requests multiple times and the OTP generated during these successive requests is the same and also they get successfully verified

4. The user enters a wrong OTP and the authentication fails

5. Users enter the right OTP but later than the specified expiry time, authentication fails

6. Users enter the OTP after a long time (expiration time) – the authentication fails

How to break the OTP functionality for 2FA

Think like a hacker, first understand how hackers use the 2FA vulnerabilities to get access to applications. Once you know how to break it, you’ll know how to test it. 

Rate Limit Algorithm – The rate limit algorithm is used to test whether a user session (or IP address) should be limited in the number or speed of authentication attempts being sent, and under what circumstances this happens.

•  If the user has performed too many requests within a certain period of time, the web application can respond with a 429 code (too many requests) or apply a rate limit without showing errors

• The absence of a rate limit implies that there are no restrictions on the number of attempts and/or speed — it is allowed to iterate over codes any amount of times (at any speed) within the session / token validity period

It is the responsibility of the QA team to ensure that the development team sets an appropriate rate limit on the number/speed of authentication requests being sent from a user session (or IP address).

Ways in which a hacker can get access to your code:

1. A lack of rate limit – A hacker can send out multiple authentication requests and thus achieve entry into the application

2. Rate limits exist but can be bypassed – Security analysts try to pick up code using 2 or more threads to make an attack faster. With the help of manipulations, they successfully select the required code, leading to Account Takeover.

•  If the 2FA code doesn’t have a specific expiration date, then a potential hacker or a security analyst is presented with more time to work this through

•  But if the validity period is present, then the success of the attack is reduced, but the potential danger of vulnerability is still present since there is still a chance of getting in with the right code

3. The same OTP gets generated for some time 

If your application sends the same 4 digit code between 0000 to 9999 for around 5 minutes, a hacker can run a brute force algorithm to test out all 4 digit numbers within the 5 minute time period

4. Bypassing the rate limit by changing the IP Address

Many locks are based on restricting the number of requests from an IP. Thus, when an IP has sent a certain number of attempts when executing a request, the IP is restricted. To overcome this, change your IP using a VPN and continue sending requests to break the code. 

While hackers continuously find ways to achieve illegal access to applications, we at Testsigma will continue to update this document.

We have learnt about use cases, how to break the system to get illegal access/entry into apps. 

Now let’s try to understand how to test this functionality. 

How to test the OTP functionality for 2FA

The primary requirement for testing this functionality is to have an end user’s phone.

While you can connect your own phone for a single test on your computer, you will require a phone which can be accessed by your tests on the cloud to run different tests on different platforms. 

Traditionally these tests have been automated only as a POC(proof of concept). Companies hardly test the OTP functionality because

1. It is time-consuming

2. Involves third-party frameworks 

3. Involves a cost to the company

4. Testers don’t have the required programming knowledge

It comes with a monthly cost and each SMS received is charged separately. 

Have a look at the code below:

Using python packages, REST APIs and HTTP calls, these OTPs are read and used in the test. 

Do we expect our QA teams to write this code every time to test OTP functionality?

The Modern Approach to testing OTP functionality using Testsigma

Testsigma offers a simple interface to test these OTP based authentication methods. 

Testsigma comes inbuilt with mobile numbers spanning across different geographic locations. 

Using a simple NLP based approach, we help you automate the complicated use cases mentioned at the beginning of this discussion. 

Testsigma’s NLP based approach to automating the OTP request retrieval mechanism requires zero knowledge of code. It does not come with any extra costs and a tester can easily automate these functionalities within minutes. 

To read more on how exactly Testsigma does it, check the article here: 2 Factor Authentication(2FA) with Testsigma 

Testsigma’s modern approach also enables users to retrieve codes via emails.

So why wait, Join the Testsigma testing revolution!

#Smart Test Automation