Introduction
Authentication is a crucial concept in information and technology security. This concept ensures that the person or system attempting to access a particular resource or information is the one who has the appropriate access rights. The authentication process verifies the validity of a user or system’s identity and authorizes access only to legitimate and authenticated entities. In an era where information security is becoming increasingly important, and cyber attacks are growing in frequency, authentication is becoming more critical as part of an effective security strategy. There are various types of authentication techniques available, and the selection of the appropriate technique depends on the type of application or system desired.
What is Authentication?
Authentication is the process of verifying the identity of a user or entity attempting to access a system or resource, typically through the use of a username and password or other authentication factors such as biometric identification. It ensures that only authorized users are granted access to the system or resource.
Authentication Factors
Some common authentication factors include:
- Something known: For example, a password or PIN that is only known by a specific user.
- Something possessed: For example, a token given to a user that contains a unique code that can be used for authentication.
- Something inherent: For example, a fingerprint or facial recognition that is unique to a specific individual.
- Something that happens: For example, the user’s location or login time that can be used to verify their identity.
Combination of the above authentication factors can be used in various types of authentication methods such as passwords, two-factor authentication, and biometrics. The selection of the appropriate authentication factor depends on the type of desired application or system, as well as the required security level to maintain authorized access.
Types of Authentication
There are various types of authentication methods, including:
- Password-based authentication: This is the most common type of authentication, where a user enters a password to access a system or application.
- Two-factor authentication (2FA): In this method, users must provide two different types of authentication, such as a password and a token, to gain access.
- Multi-factor authentication (MFA): Similar to 2FA, this method requires users to provide multiple types of authentication to access a system or application, such as a password, token, and biometric factor.
- Biometric authentication: This method uses unique physical characteristics of an individual, such as fingerprints or facial recognition, to verify their identity.
- Certificate-based authentication: This method uses digital certificates to verify the identity of a user or system.
- Token-based authentication: In this method, users are provided with a hardware or software token that generates a unique code used for authentication.
- Single sign-on (SSO) authentication: This method allows users to authenticate once to access multiple systems or applications.
The selection of the appropriate authentication method depends on the desired level of security and the type of system or application in question.
OWASP Web Appliaction Securuity Testing for Authentication Testing
OWASP provides instructions for testing authentication on web applications.
1. Testing for Credentials Transported over an Encrypted Channel
Test objectives: Assess whether any use case of the web site or application causes the server or the client to exchange credentials without encryption.
For example in the web application below, testing can be done by sending requests for login, account creation, password change, etc. using the HTTP method, whether requests can be sent via HTTP. If the request is automatically redirected using the HTTPS method then there is no problem in the test.
The difference if sending credentials over an encrypted channel
On encrypted channels there is a cookie attribute “Secure” which indicates that the cookie will only be sent over a secure and encrypted connection (HTTPS), so the data contained in the cookie will not be easily accessed or intercepted by unauthorized parties. Unlike the unencrypted channel, the cookie value “login=test%2Ftest” may indicate that the user has logged in with the username and password “test/test”.
Prevention can be done by ensuring that the web application has implemented HSTS (HTTP Strict Transport Security).
2. Testing for Default Credentials
Test objectives:
- Enumerate the applications for default credentials and validate if they still exist.
- Review and assess new user accounts and if they are created with any defaults or identifiable patterns.
Testing can be done by means of common usernames such as admin, administrator, root, system, guest, operator, or super and passwords such as password, password123, password123, admin, or guest.
For example if the password uses the default credential, with brute force testing hackers will find it easy to access the system, in this test if the experiment is successful there will be a 200 response and if it fails there will be a 302 response as shown below.
Prevention can be done by changing the default credentials on applications after the initial setup.
3. Testing for Weak Lock Out Mechanism
Test objectives:
- Evaluate the account lockout mechanism’s ability to mitigate brute force password guessing.
- Evaluate the unlock mechanism’s resistance to unauthorized account unlocking.
The test can be done with several failed login attempts or can use a brute force attack, observe if there is a response such as a locked account after several failed login attempts. In the results below it is not found that the web application has a lock mechanism.
Prevention can be done by creating a lock mechanism such as after failing 5 times to enter the password so as to avoid brute force attack.
4. Testing for Bypassing Authentication Schema
Test objectives: Ensure that authentication is applied across all services that require it.
Testing can be done by requesting pages after authentication directly such as profile pages, parameter modification, session ID prediction, SQL injection.
One of the testing techniques that can be done is with direct page requests, for example to be able to access the userinfo.php page the user must go through the authentication process first, testing is done by making a direct request to the userinfo.php page but the web application directs the user to authenticate on the login page first, meaning there is no problem in testing direct page requests.
5. Testing for Vulnerable Remember Password
Test objectives: Validate that the generated session is managed securely and do not put the user’s credentials in danger.
The test can be performed by checking whether the application stores sensitive information on the client side.
For example, in the test below, the session generated is secure because it has been encrypted so as not to jeopardize user credentials.
6. Testing for Browser Cache Weaknesses
Test objectives:
- Review if the application stores sensitive information on the client-side.
- Review if access can occur without authorization.
Testing can be done by reviewing whether the application stores sensitive information on the client side and whether access can occur without authorization.
For example, in testing the web application below, when the user is on the userinfo.php page then clicks logout after successfully logging out then clicking the userinfo.php page again, it can still be displayed again, which means that the web application has a problem in browser history, when testing is done using a proxy, the “max-age=0” value in the Cache-Control header instructs the browser to retrieve the latest version from the server and not use the cached copy. Although the browser can keep a copy of the content in the cache for a certain time, the Cache-Control:max-age=0 header ensures that every time the page is loaded, the browser must request the latest version from the server.
7. Testing for Weak Password Policy
Test objectives: Determine the resistance of the application against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse, and aging requirements of passwords.
Testing can be done by whether the web application sets the conditions for creating passwords for example such as a minimum of characters, uppercase letters, lowercase letters, symbols, etc. Whether when creating a password can be filled in with common passwords such as password, qwerty, 123456, etc.
For example, during the registration process in the web application below, the password table already has a provision about the password that must be followed, if the provision has been done then the color will turn green, when trying to fill in with the password “password” the lowercase provisions in the password are already green, if it is still forced to use the password the registration will fail and be asked to change the password according to the provisions.
8. Testing for Weak Security Question Answer
Test objectives:
- Determine the complexity and how straight-forward the questions are.
- Assess possible user answers and brute force capabilities.
Testing can be done whether the application provides weak security questions that can be publicly known such as full name, school name, favorite movie, etc.
For example, in the question table for resetting passwords, testing is done by making questions that are easy to guess, such as 1+1 = 2 and when clicking the register button, the question can be accepted, so there is a vulnerability in the security question answer.
9. Testing for Weak Password Change or Reset Functionalities
Test objectives:
- Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account.
- Determine the resistance of the passwords reset functionality against guessing or bypassing.
Tests can be conducted on what is required for password reset such as whether re-authentication is required before changing the password, whether the reset password can be sent to email without any prior inquiries, whether an old password is required, etc.
For example, in the web application below, to change the password, authentication is required by entering the current password, and if you forget the password, the user will be asked to enter the username and email used, then a password change link will be sent to the registered email, there is a vulnerability, apparently not asked for a question that was entered during registration, a password link will be sent directly to the email, when the email is opened there is immediately a password created by the system.
10. Testing for Weaker Authentication in Alternative Channel
Test objectives:
- Identify alternative authentication channels.
- Assess the security measures used and if any bypasses exists on the alternative channels.
Testing can be done by first knowing the main authentication of the web application, then test whether there are other alternatives available, whether authentication functions such as register, log in, log out, and reset password work properly.
