06 Jan 2023
2FA is an additional layer of security used to ensure that only authenticated users gain access to an online account. Initially, a user will enter their username and password as usual. Then, rather than gaining access straight away, they will be required to provide additional information.
This second factor could come from one of the following categories:
Something you own:
A code from an Authenticator app on your phone, or a code sent by SMS to your phone.
Something you are:
A biometric indicator, like your fingerprint (Touch ID) or facial recognition (Face ID).
So why is it necessary for systems to have this kind of extra layer of security? From time to time you hear news stories about high-profile data breaches and password leaks. People think that this only happens to those with outdated systems or poor security. Is this the case though?
Here are some worrying facts about this traditional security measure:
With 2FA, a potential compromise of one of these factors will not compromise the account itself. So, even if your password is taken or your phone is astray, the chances of someone else having access to both factors are not likely.
Our company accounts require 2FA for the login processes even for the test environments. While implementing automated tests this becomes a challenge for the QA. Standard login procedures can be automated easily, but things get a bit complicated when 2FA comes into play. Although Selenium highly suggests disabling it for the test environments there is a way for grabbing the verification code by test script to pass the Google Authentication 2FA step.
AeroGear OTP API allows you to create the 2FA code for Google Authentication. It is an old API but it still works without an issue. It sounds cool, right? We thought so. We’ve implemented it into our automation codebase and have run it successfully. It worked like a charm for the moment, for our local machines.
In the meantime, besides the 2FA challenge, we were planning to run our tests on GCP for CI/CD purposes. After running our first tests on the virtual machine we’ve seen that it was not that easy to trick Google Authentication. There was an unforeseen consequence of 2FA. The mighty CAPTCHA. (Completely Automated Public Turing test to tell Computers and Humans Apart). CAPTCHA is a type of security measure known as challenge-response authentication. CAPTCHA helps protect systems from spam and password decryption by asking users to complete a simple test that proves they are human and not a computer trying to break into a password-protected account.
A CAPTCHA test is made up of two simple parts: a randomly generated sequence of letters and/or numbers that appear as a distorted image, and a text box. To pass the test and prove your human identity, simply type the characters you see in the image into the text box.
It wasn’t appearing on our local machines but that doesn’t mean that CAPTCHA doesn’t exist. When we ran the tests on a virtual machine, CAPTCHA was waiting for us to say “You shall not pass” like Gandalf.
So is it possible to bypass CAPTCHA? There are some tricks to do that but there is no way to be sure that trick is going to work for any length of time. Eventually, it will be blocked by Google. So as a QA team, we need to come up with a better solution.
After trying every solution that we could find as a QA and couldn’t figure out what to do, we asked for help from our developers. After a meeting with the whole development (Front-end, Back-end, DevOps) team, an excellent idea showed up. A while ago, the Development team implemented the Firebase Custom Token login for the product for another feature. Basically, If we implement the firebase custom token generation to our automation codebase we would be able to generate and use that token to log in to the product without any 2FA code — even without a username or password required. This approach eliminates the security risks because the login system for the product remains the same. Also, the custom tokens expire after a time limit so even if they leak they will be useless to anyone who wants to use them to log in to the product.
I can hear the questions from those who read this as a tester: “What about testing the login process?” “It is not automated and so it is not going to be tested?” It would be nice to handle that with automation but we’re testing it every day by using the product with at least two different testers. So we moved on and implemented the Firebase Custom Token generation into our automation codebase. Does it work now? Yes, it works flawlessly.
Dealing with 2FA while writing automation tests can be a challenging but ultimately rewarding experience. By using techniques such as mocking, token management, and bypassing 2FA when running tests, it is possible to successfully incorporate 2FA into the testing workflow while still maintaining the security benefits of this important authentication method. It is important to carefully consider the trade-offs of each approach and choose the one that best fits the needs of the testing environment. As a QA while working through these challenges, we will likely discover new ways to improve the security and reliability of our tests. By staying up-to-date with the latest testing best practices and continuously seeking out new solutions, we can ensure that your automation tests are both effective and secure. With the right tools and strategies, you can effectively test your systems while still maintaining the security benefits of 2FA.
Semih has 5 years of experience with full system development life cycle experience including designing, developing and implementing multiple test cases and plans in software and web applications, working in various fields including cyber security, webRTC and real estate. He currently holds the Senior QA Engineer position at Recognyte.
