Multi-factor authentication. How to test?

The amount of data in the digital world is increasing day by day. In the modern world people increasingly use online payment, electronic documents, signatures, and other services. But fraudsters also keep up with modern trends. Therefore, the issue of making funds, personal information, etc. secure is becoming increasingly important. This is how the need for multi-factor authentication arose.

What is multi-factor authentication?

Authentication is the process of verifying identity in the system. To enter the website, the user must have a login (username) and password. But cybercriminals seek to gain access to authentication data using various methods.

Two-factor authentication (2FA) provides an additional layer of security. It can be performed in many ways: answers to secret questions, face or voice recognition, e-mail messages, SMS or call, fingerprint, etc. Even if the login/password has been hacked, hackers cannot get access to your mobile phone. Thus, they will not get to the second level of security and will not be authorized in the system.

Two-factor authentication protects logins from phishing, social engineering, and password-guessing attacks. It also prevents attackers from logging in using weak or stolen credentials.

Two-factor authentication types

The ways in which you can confirm your identity can be divided into three types ("factors"):

• something you know (based on user knowledge). For example, a password or an answer to a secret question;
• something you have (depends on what the user has). For example, a code from a message or an answer to a call;
• something that you are (biometric data). For example, face/voice or fingerprint recognition.

How does multi-factor authentication work?

The general concept of two-factor authentication is to combine two different types of "factors". For example, having two passwords generally does not add significant security. But requiring you to keep your phone with you can improve security. After all, there are few chances that an attacker can get hold of both the credentials and the phone at the same time.

The most common two-factor authentication scheme looks like this:

1. User enters login and password.
2. The app sends a one-time code to your phone/email.
3. The user enters a one-time code in the system verification window.
4. If the code is correct, then access is granted. Otherwise, the program offers to resend the one-time code (however, the number of retries is limited).

Most implementations of two-factor authentication use the "what you have" factor, so let's take a closer look at it. There are several common implementations.

The device that generates the code. This is one of the very first implementations of two-factor authentication. A mechanism generates a code (usually a six-digit number) and you enter it on your computer to log in. The idea is that this code can only be generated by the physical device being used (and the server). If the entered code matches the one sent, it means the person logging in has access to the physical device.

A device that performs a cryptographic handshake. This implementation is more modern because it relies on greater integration with the browser or operating system. A private key is used to accept a call from the server to confirm the presence of the device. This avoids phishing problems because even if an attacker is able to intercept the password and use the security key, they still cannot use the security key response to log in to another website.

Due to its resistance to phishing and overall ease of use, the cryptographic handshake is generally the best two-factor implementation available for most applications. It can also help implement additional functions, such as authenticating certain transactions. But usually, it requires the installation of a certain application.

A code sent by another owner. Some two-factor services use an SMS or email code to verify that you have access to a phone number or email address. This is more risky because it is relatively easy to redirect SMS messages (via SS7 attacks or any other method). And email is often used for password resets (it means that an attacker with access to your email can both reset your password and bypass the 2FA request).

Push confirmation. An alternative approach to One-Time Passwords (OTPs) is to send push notifications to the user's mobile phone, which they can accept or decline. This method is less common because it requires the user to install an application-specific authenticator.

To properly assess the security of this method, the scope of testing needs to be expanded to include both the mobile app and any supporting APIs or services it uses; therefore, this means that it often goes beyond traditional web application testing.

Testing two-factor systems

Multi-factor authentication adds complexity to the functionality of the system, so it is very important that it is implemented in a correct and reliable way.To make it more convenient, we will divide the problems that the tester can detect into several categories.

Session state. Here you should check the stage when the first phase of authentication has been passed and the second has not been completed yet. After entering the password, is it possible to do anything with any state of the current session until the authentication process is complete? If so, what exactly are those actions?

A lot of systems initially used only simple authentication, and only later added support for multifactor (in other words, the application was not designed with it from scratch). Therefore, it is important to check whether the application tracks the user's partial login when he has passed only the first authentication step, before completing the second step. Therefore, it is important to check whether the application tracks the user's partial login when he has passed only the first authentication step before completing the second step. Because in some cases, this could allow an attacker to authenticate with just a password and act as if they were fully logged in.

It can be checked using the source code or using special plugins (it depends on the structure of the system itself).

Changing your password while waiting on a two-factor page. Here you should check if the waiting process on the two-factor page allows you to ignore the password change. If you log in with a username and password and proceed to the second step, some programs will simply remember that the user is partially logged in. This makes it difficult to recover a stolen password: even a password change may not prevent attackers from logging in if they opened the second authentication factor login flow before the password was changed.

It is quite easy to check. To do this, two browsers should be used. Pass the first stage of authentication and do not perform actions to pass the second stage in one of them. Fully log in and change the user's password In another browser. Then, in the first browser complete correctly the second stage of authentication and try to log in without re-entering the user's password. If everything is successful, the system is vulnerable.

«Remember this computer». Not all apps support this feature. Typically this is just a persistent cookie with a randomly generated value stored in the database, but it's important to make sure that this value is secure randomly generated, and different for each user (ideally the token will also be different for each computer).

If someone accidentally checks the "remember this computer" box on a shared computer, you should check if it can be removed later (since during its operation, a cybercriminal can copy this token and bypass two-factor authentication).

You can check this by using multiple accounts.

Disabling two-factor authentication. This case checks whether you need to re-enter your password and confirm current actions before turning off two-factor authentication. It should be noted that usually, before turning off 2FA, you need to enter a password. Otherwise, an attacker who has gained access to the account will be able to enable/disable it themselves and effectively block the victim.

This functionality is checked by turning on and off two-factor authentication, and entering a password to confirm actions (or their absence - which is a danger to user data). The system must require a password and a two-factor prompt before allowing a user to disable second-step authentication for their account.

Authentication code. These checks may be applied to those two-factor authentication implementations that use a code that is sent via SMS text message or email. Email as a second factor is useful in some situations, but many programs also allow you to reset your password via email, reducing the security of your account.

It's easy to check: get the code by message or e-mail, and try to recover the password by email.

Security key. Most code-based multifactor authentication systems rely on this method. But, if the security key is not cryptographically protected or is very short, an attacker can guess it. Therefore, first of all, attention is drawn to its length and obvious randomness.

Once the black box method is used for verification, it is better to create multiple security keys for the same or different accounts. Each key must be different, non-sequential, and unpredictable. It is quite difficult to get enough security keys for testing. If a QR code is generated, it can be checked, for example, by a barcode scanner or another application (not just a standard scanner).

If it is possible to view the source code, it is important to ensure that the security key is generated from a reliable random number generator and not the default one, since the default generators in most programming languages ​​are fast but predictable. That is, attackers can find out which keys were assigned to which users. Also, they must be 20 bytes long (longer is fine, but may cause compatibility issues), shorter ones should be avoided for security reasons.

Security code reuse. The point is that an attacker who intercepts your request can reuse the code, bypassing the protection of two-factor authentication. This can only happen if a fraudster gets access to the code around the same time you use it, but it's still a likely scenario for many users.

The script should also be tested to see if you can save the old code, wait for the new code, use the new code, and then use the old code. If an attacker can see the user's code generation device, they can see the previous code that the user decided to enter (for example, the user might think that they only have a few seconds to enter the code and decide not to use it). In this case, an attacker can use older code.

To test such a scenario, two different browsers can be opened and go to the system. Next, get a valid code and use it to log in to both browsers. If it is possible to do this in both sessions, the implementation is vulnerable. Only code that is newer than the recorded timestamp for the user's last code should be current. It would also be useful to report that the code has already been used (rather than just a generic error), as this makes it possible to spot the attack.

Entering several incorrect codes in a row (guessing codes). There must be some mechanism to limit the rate (or number) of entering codes. In this case, CAPTCHA can be useful. But the user still needs to be notified in some way, as this probably means their password has been compromised. Most two-factor implementations require a valid password before the second factor is requested.

To check this, try logging in with the wrong code. Do this a few times over a short period of time. If the app starts asking for CAPTCHAs or blocks you completely, it's not vulnerable. Especially sensitive applications should carefully consider notifying the user after any failed authentication attempt since a failed attempt still means that an attacker could have obtained the user's password.

The time during which the code is valid for the current session. The period of time during which the current code is valid must be sufficient for the user to comfortably enter it. But at the same time, this interval should not be too long for a cybercriminal to intercept it and use it to his advantage. The general range of validity is about five minutes in either direction from the time set on the server, although reductions to two or three minutes are acceptable. But the main question is how many codes are valid at the same time: the validity period is divided by the time between new codes.

To test, you can generate a code and try entering after a few minutes to determine how long it takes for the code to become unavailable. If you have access to the source code, you can determine the actual value. Otherwise, you will have to try to generate future codes and test them.

Bypassing blocking via cookie or IP address. Blocking data is sometimes tracked in a session cookie or by its IP address tracking. An attacker can easily bypass this blocking mechanism. Any blocking tracking data must be associated with an account in the database and not be shared with the customer or tracked based on any customer identification, as any of these can be changed.

Try clearing cookies if you lose access to your account or if you are asked to enter a CAPTCHA. But it's best to check how the blocking information is tracked on the server, and will probably require looking at the source code.

Certificates and smart cards. Transport Layer Security (TLS) is typically used to encrypt traffic between a client and a server and to provide a mechanism for the client to verify the server's identity. However, it can also provide a mechanism for the server to verify the client's identity, known as client certificate authentication or mutual TLS (mTLS). The key principle is that the user presents a digital certificate (stored on their machine or on a smart card) that is verified by the server.

The first step in testing is to determine whether the target application restricts the Certification Authorities (CA)  that are trusted to issue certificates. This information can be obtained using various tools or by manually examining the TLS handshake. If there are no restrictions, then authentication using a certificate from another CA will be possible. If there are restrictions but they are poorly implemented, you can create a local CA with the correct name and use this new CA to sign client certificates.

If a valid certificate can be obtained, you should also verify that the certificate can only be used by the user for whom it was issued. Also, you should check the certificates to make sure they are not expired or revoked.

Conclusion

Multi-factor authentication is an important technology because it helps to better protect your personal data. Hackers who obtain authentication factors can gain unauthorized access to accounts. Common ways to do this include phishing attacks, account recovery procedures, and special software. The task of testers is to check all possible and impossible options and find all the vulnerabilities, so as not to give cybercriminals a chance to break into the system.