The different test cases for Two Factor Authentication that should be automated?
Two Factor Authentication helps us by providing two-layer security for all the digital activities we perform. This provides an additional layer of security to the user as compared to a single layer of password security. The user is expected to prove her identity two times on the application.
In Two factor authentication — the first level of authentication is mostly a username and password. However, the second level authentication can be done in multiple ways: facial recognition, email, SMS, fingerprint, digital tokens, voice recognition, etc.
Today the web and mobile applications are using two-factor authentication extensively to reduce security vulnerabilities. The reason behind this is that even if your user id/password has been compromised, the hackers cannot access your mobile phone. This way, they cannot get hold of the OTP(second layer of security) and cannot log into the application.
The most common form of 2FA can be understood as below:
- Provide the username and password.
- The application sends an OTP(One time PIN) as an SMS/email.
- Enter the OTP in the verification window of the application.
- If OTP is correct, access is provided, else we may choose to resend the OTP.
However, the retry is restricted to a finite number, to curb any sort of security threat.
Due to the involvement of an external mobile device or email application, the automation of this process is difficult to achieve. Since every time a random OTP will be generated which cannot be guessed or calculated.
Therefore, just after providing the first level of authentication the automation process should read the OTP from a physical device and feed it into the application.
Testsigma eases the process of 2FA test automation immensely. We can automate this difficult task of 2FA through just a few clicks without any prior coding knowledge or a third-party tool. A single automation tool takes care of all your testing needs!
Also, check out how to perform OTP based authentication using testsigma.
The most common test scenarios that are usually automated for testing 2FA are as below:
User registration
When a user performs a registration on an application, he provides basic information like name, email, phone number, address, etc. To verify the phone number the application will send a PIN to that number as SMS.
Use Case: The OTP is received on the phone and then the user has to key in the received PIN into the application. During automation testing, the OTP is read from the device and entered into the application. The verification is done successfully and a positive test case is executed.
This enables the user to continue the registration process further and eventually complete it.
How to break the 2FA functionality: Assume that the same OTP is generated by this application during user registration for 5 minutes. The test case can use the same OTP for registering more than one user, after providing an incorrect phone number. The registration will be successful for an incorrect phone number and this will be a negative test case.
Device authentication
Consider a scenario where we use our email application on a different device than usual.
E.g. A user uses a mobile app to access her email. One day she logs into her office’s system to access the email application.
After entering the username and password, the application recognizes the change in IP address. To rule out any possibility of a security breach, the email application sends an SMS with OTP PIN to the registered mobile number and mentions that there is a login attempt from a different device.
This message is intended to alert the user in case there is any vulnerability from the user’s side. Since it is the user herself, she can enter the OTP PIN in the application and continue accessing the emails on the system.
Use Case: The automation test enters an incorrect and random OTP and the authentication fails.
How to break the 2FA functionality: Here, if there are no restrictions on the number of attempts by the user, then an automation code can generate permutations and combinations of 4 digit OTP. The automation script will keep feeding the generated OTP until the login attempt is successful.
Banking transactions
It is the most common scenario where testing the two-factor authentication process is of utmost importance.
Banking credentials and information are always the most coveted information for hackers. Anyhow they want to access the user’s banking information and use it for their benefit through fraudulent activities. Banks are well aware of this, therefore they have introduced 2FA in all financial transactions.
Example 1: When a user initiates a bank transfer, the bank presents a two-factor authentication using an OTP via SMS or call. If the transfer is legit, the user will provide the OTP and continue with the transfer. Else if it is fraudulent activity, the transfer would not be completed as the OTP would be inaccessible.
Example 2: When we add a new beneficiary to a banking application. An OTP is sent to the user’s device to activate the newly added beneficiary. If the user successfully enters the OTP, the beneficiary is activated and the user can transfer the money.
Use Case: Automation tests send many OTP requests within a time interval. To check this a ‘Rate Limit Algorithm’ is used. A Rate Limit Algorithm verifies the speed and number of OTP attempts within a time frame.
If there is no Rate Limit check, the hackers may continue sending the OTP requests during the lifetime of the session or OTP. Which can be responded to by a ‘429 Too Many Requests’ response. Or maybe by ‘200 OK’ with an error in the response.
How to break the 2FA functionality: Automation tests can use bruteforce OTP if no rate limit algorithm is implemented.
If there is a rate limit algorithm, the sender’s IP can be changed using VPN system/ proxy servers to bypass the rate limit algorithm.
Password reset
We all are guilty of forgetting the passwords. Applications provide an easy password reset option to their users for the same. Simultaneously they want to ensure that it is not a hacking attempt.
For this purpose whenever a password reset is requested by the user, an OTP is sent to the phone number registered with the application.
The user enters the OTP PIN and then resets the password by either choosing a new one or sending the previous one on email/phone. As we know, password reset action is very common among users and therefore it should be covered in the testing activities.
Use Case: Usually, a rate limit algorithm gets activated when a certain number of attempts are made. If automation tests are performing bruteforce OTP via multiple threads, the bandwidth will get impacted due to the rate limit algorithm. Hence, during automation testing it is recommended to use only a single thread for bruteforce OTP.
How to break the 2FA functionality: If the OTP is without any expiration date, then automation tests have enough time to brute force it.
E-wallet transactions
Today e-wallets are synonymous with banking applications. We all use them profusely, due to the customer offers and ease of use they provide. These e-wallet applications require thorough testing similar to banking apps. To provide a higher level of security they’re also dependent on 2FA.
Similarly, activities such as — adding any new beneficiary, initiating a payment, changing the bank account details are under scrutiny. The application will initiate an OTP to be sent to the user’s physical device. Once the user responds by entering the received OTP in the application, then the transactions will move further.
Use case: The user enters a correct OTP after the expiration time of OTP. The authentication fails.
How to break the 2FA functionality: When a server uses an ‘X-Forwarded-For’ header to determine the IP address of the client, this can be used to steal/copy the OTP. This can be implemented by adding the ‘X-Forwarded-For’ header to the OTP check request.
Bypass two-factor authentication
Some applications allow you to bypass the 2FA by clicking the ‘remember me’ option. This saves the user from entering the PIN every time she logins. The process is to associate an IP address/ cookie to the user and make the login process easy and quick.
However, this also leaves an opportunity for the fraudsters to take advantage. Therefore, this scenario should be tested by selecting the ‘remember me’ option and changing the IP address while login. This can be done by changing the browser and trying to log in.
However, this ‘remember me’ function is not safe, but it is used by applications. So we need to test this thoroughly if the application allows this to be checked by the user.
Use Case: The ‘Remember Me’ is checked and the application saves the cookie information. To keep the cookie information safe, ‘HttpOnly’ attribute should be set, to safeguard it from XSS attacks.
How to break the 2FA functionality: Use XSS injections to steal the cookie information and then use it to gain login access to the application.
Conclusion
Two-factor authentication is here to stay, due to the immense security it provides. By integrating 2FA as a security measure in the application we can bypass the hackers and attackers. They can only access the application if they get hold of the user’s physical device which is most unlikely.
Hence, we need to properly write and run the test cases to verify the two-factor authentication. It is observed that testers face difficulty in writing automation test scripts for two-factor authentication. Then an easy route is followed i.e. disable 2FA during testing activities.
But this is quite dangerous from the user’s point of view. Also, manually enter the OTP in between the automation scripts is an impractical tactic. Therefore, we need the help of such automation tools which facilitate the 2FA automation testing, Testsigma is one of them.