Module 3
Authentication
Last updated on: 28 November 2024
Edit this page on GitHubModule 3
Last updated on: 28 November 2024
Edit this page on GitHubIn any website that has user logins, it’s important that the site protects user accounts from unauthorized access, and also that the account credentials themselves are protected. This subtopic outlines the most common areas of authentication where web application flaws appear.
After completing this subtopic, practitioners should be able to do the following:
Authentication is the process by which a user of a system proves that they are who they claim they are. It is the foundation upon which access control is built. Typically, a user will supply a piece of information that identifies them (username, email address, phone number, etc.) and a piece of secret information that validates that identity (commonly a password or passphrase, though alternative or additional methods such as a security keys, WebAuthn, and Passkeys are gaining popularity). This subtopic will cover a few vulnerability classes that are common and high-impact in web applications.
If users are to log in to a site with a username and a password, the site must be able to validate that the user entered the correct password. Passwords must furthermore be stored securely in the application’s authentication database, because that database might be compromised due to SQL injection, lost backups, or even malicious or compromised members of the organization running the site. There are several approaches to storing passwords:
Special password storage algorithms
The problem with cryptographic hashes is that they are designed to be fast and efficient. Most of their use is in verifying that data hasn’t been tampered with. This problem had been addressed as early as 1976, with a Unix crypt function that salted and encrypted the password multiple times to slow down brute-forcing. Unsurprisingly, this algorithm will not stand up to modern computing resources, but the general idea is still used today with special algorithms that are designed to store password derivatives. These algorithms are designed to take tunable CPU and memory resources, to make a good tradeoff between performance and brute-force resistance. Good password handling algorithms include (in decreasing order of preference) scrypt, argon2, bcrypt, and PBKDF2. As a defense-in-depth measure, it’s a good practice to combine the user’s password with a secret that’s not stored in the database itself. For example, the secret can be hard-coded in the application itself. This will likely prevent password recovery if only the password database is lost.
Log into your DVWA and make sure the security level is set to low. Navigate to the SQL Injection section, and enter the following into the text box:999' union all select user, password from users where '1'='1
This will return the first and last names of all users who have a userid
of 999 (there are none), and also the username and password hash for all users. Use an online hash lookup site (e.g. https://www.whatsmyip.org/hash-lookup/) to look up the admin user’s password hash. What kind of hash is used to store the DVWA users’ passwords? What is the password of the user named “1337”?
For more information on password handling, see the OWASP password storage cheat sheet.
If the user on a website forgets their password, most sites provide an automated way for the user to verify their identity in order to set a new password. Ideally, these methods are approximately as secure as the standard password verification process in which the user types in a secret password they know into a webpage, but are significantly less convenient.
Most sites will assume that the user’s email account is reasonably secure and email the user a link that will allow them to reset their password. This assumption is probably correct for the vast majority of user accounts on the vast majority of websites. Password reset links (and, additionally, “magic login” links) should have the following properties in order to minimize user risk:
Reset links may also be sent via SMS. SMS is less likely to be intercepted than email by normal hackers, but is vulnerable to interception by governments in the country that the user is in. If a shorter token (e.g. a PIN) is sent via SMS, then it is important to have strong brute-force protection on the page that accepts the PIN, e.g. a 10 minute PIN lifetime and rate-limiting. Note as well that there are both money-making and simple DoS attacks that involve causing a server to send SMS messages to a phone number of an attacker’s choosing. By performing a large number of SMS password resets, an attacker can incur high costs for the website operator, potentially making money for themselves in the process.
An alternate method of performing password resets involves asking the user questions that both the website and user know the answers to, but that an attacker might not. These tend to be extremely weak, or extremely strong methods of verifying the user’s identity. Standard “secret questions” like asking where the user was born, their mother’s maiden name, the make of their first car, etc. are quite weak. First off, an attacker may be able to easily find the answer to those questions. Secondly, most of them are impossible to change, so in the event that an attacker does discover an answer (even by compromising another website), they will be able to use them again and again. Lastly, most of these questions only have a handful of common answers. For example, if you ask a Korean person their mother’s maiden name, a significant proportion of the answers will be “Kim” or “Lee”. The other, more secure type of secret question involves offline communications between the website and the user. Examples of this are things like utility bills and bank statements. For the user to reset their password, they would enter, for instance, the amounts of 3rd and 5th transactions in their bank statement. The user would only be allowed a few tries, and then would need to perform an even less convenient reset process with customer service. This reset process can be very secure, though in the days of online statements, it’s probably less secure than emailing a token.
For a bit more on secure password reset, see the OWASP cheat sheet on Forgot Password. For an in-depth exploration of authentication and authorization vulnerabilities, see the Web Application Security Assessment learning path.
Most web applications use passwords for authentication, though techniques like WebAuthentication using security keys and extremely long lived authentication sessions combined with login links via email are gaining popularity. If a website uses passwords, it’s important that those passwords be strong. However, the definition of a “strong” password has shifted over the years. There are three primary methods that attackers uses to directly attack user passwords:
Of these attacks, the online attacks are much more common. Ideally, applications would not be vulnerable to SQL injections, insiders would not get compromised or act maliciously, and database backups would never be lost. However, it would be irresponsible to ignore the possibility of an offline attack. Given this, the priorities of a web application should be (in order):
Of course, these priorities must be balanced against the requirements of the user to either use a password manager or to remember their password. Also, passwords as an authentication method are fairly problematic; the next section covers multifactor authentication and password alternatives.
For more information on password strength, see this summary of the US Government’s NIST authentication guidelines.
As you may have surmised from the previous section, password security is very difficult. It gets worse when you consider social engineering attacks such as phishing.
Phishing is one of a class of social engineering attacks that attackers use to attack individuals. Although phishing can have many aims (such as convincing users to install malware on their computer or transfer money to attackers), the goal we care about is stealing users’ passwords. Although phishing usually refers to attacks launched via email, similar techniques can be used over a variety of communications mediums, such as SMS, WhatsApp, Signal, and even QR codes.
In a typical credential phishing campaign, attackers will send emails to their victims purporting to be sent from a legitimate website. The email will contain a call to action (such as requiring a password change or acknowledging a notification) with a link to an attacker-controlled website that has a legitimate-looking login page. If a victim clicks the link, and then enters their password on the website, the site sends their password to the attacker. (For much more on phishing, see the Investigating Malicious Infrastructure Learning Path.)
Phishing attacks are extremely low cost for attackers, and tend to be extremely effective. Once the attacker has the victim’s password, they can log into the target website as the victim. With preparation, the attacker can use automation to immediately perform actions on the victim’s account, including changing the user’s email address and password to lock the victim out of their own account.
Given the danger of phishing attacks, and the complete inability to password authentication to stop phishing, any multifactor authentication scheme should be evaluated against its phishing resistance.
Traditionally, there are three types of things (called factors) that can be used for authentication:
MFA (multifactor authentication) combines two or more of these factors together to strengthen a system’s authentication system. There are many examples of multifactor authentication in everyday life. Using an ATM requires something you have (the card) and something you know (your PIN). Many building access control systems have a badge to open a door, but that badge also brings up the badge holder’s face on a display that a guard can see, combining something you have (the badge) with something you are (your face).
In the remainder of this subsection, we’ll discuss a variety of common web MFA methods.
Although this is technically not MFA (it combines multiple things that the user knows), it was very popular in the past, and is still in use in many contexts. Using secret questions as part of authentication does provide some degree of defense against password reuse and password guessing attacks. Beyond that, it provides very little protection. It is almost worthless against phishing. The attacker’s website can simply attempt to log into the real website, and then turn around and ask the user the secret questions. Additionally, as discussed in the Password Reset subsection above, the secret question answers are frequently guessable. For these reasons, secret questions are not a strong MFA method.
An actual MFA method in common use is to text the user a code when they log in, then require that code to complete the login process. This combines something the user knows (their password) with something they have (the phone that receives messages at a certain number). Unfortunately, SMS codes are almost worthless against phishing. When the user logs into the attacker controlled fake website, the fake website will log into the real website. The real website will text the user, and the user then enters the code into the fake website. The fake site then uses the code on the real site, and is then logged in as the victim. Additionally, SIM swapping attacks can allow attackers to take over a victim’s phone number, allowing the attacker to receive SMS messages intended for the victim. For these reasons, SMS codes are not a strong MFA method for sensitive or important websites.
TOTP stands for Time-based One-Time Password. To initiate the system, the server and a device controlled by the user exchange a cryptographic secret (the “seed”) and synchronize their clocks. Then, when a user wishes to authenticate to a website, the user’s device performs a cryptographic operation on the seed and the current time, generating a code that’s only good for seconds or minutes. The server performs the same operation, and uses that to check the user’s code. In the past, the most common TOTP system was RSA SecureIDs, which were expensive. Now, most TOTP systems run on smartphones. Examples include Google Authenticator and Authy. Regardless, TOTP functions as something you have (the TOTP seed) for purposes of authentication.
Like SMS codes, TOTP is also vulnerable to phishing. The attacker-controlled fake site can simply ask the user for their TOTP code and use it to log into the real site. For this reason, TOTP is not a strong MFA method for sensitive or important websites. Also note that if a user loses or wipes their phone, they are unlikely to be able to authenticate to the site, as they have lost their TOTP seed.
Security keys (sometimes referred to as U2F, FIDO, WebAuthentication, Yubikeys, etc) are devices that implement a cryptographic authentication protocol. When you register a security key with a website, the site and the security key exchange public keys. For subsequent authentication, the server presents a signed challenge to the device. The device verifies the site’s signature, and then responds with a signed response. Finally, the server verifies the device’s signature. This proves to the server that you are in possession of the key that was registered initially, making it something you have. Traditionally, security keys were stand-alone devices that talked to a computer or mobile device over USB or NFC, although support for using smartphones and computers is available in some configurations.
Unlike the other MFA discussed here, security keys are resistant to phishing. The key here is that the signed challenge includes the identity of the website requesting authentication. For a valid site, this will match an existing site key on the device. For a lookalike attacker-controlled site, the site will not match any existing site key, and so no MFA will take place. So, the attacker may have the user’s password, but they will not be able to complete authentication to the target website, as there’s no way for the attacker to complete the MFA process. On the minus side, security keys can be lost. Generally, sites that use security keys will allow users to register multiple keys, so that if one is lost or damaged, a back-up can be used.
Pre-generated single use passwords are sometimes used as a backup for other MFA methods, and were used for high-security applications before the widespread use of smartphones. Modern websites will frequently refer to these as “backup codes.” The server will generate a list of codes, store them, and present them to the user. The user would generally print them out and store the paper in a secure location. Each time a code is used, it is marked as invalid by the server. These are subject to the same weaknesses as TOTP, but have a perverse advantage of being very inconvenient. As such, they are frequently used as a backup for other MFA methods. The hope is that their use is rare enough that, if a user is prompted to enter a backup code, they will stop and highly scrutinize the requesting website, making a phishing attack less likely to succeed. Examples of sites using backup codes are Gmail and GitHub.
For a bit more authentication, see the OWASP authentication cheat sheet and the OWASP MFA cheat sheet. For an in-depth exploration, see the Web Application Security Assessment learning path.
Session fixation is an important concept in web security. It refers to an attack where an attacker sets a user’s session identifier (session ID) to a value known to the attacker. This can occur through various means, such as phishing attacks or by exploiting vulnerabilities in the web application. The attack involves acquiring a valid session ID, persuading a user to authenticate with it, and then taking over the session by leveraging the known session ID. This requires the attacker to supply a genuine web application session ID and manipulate the targeted person’s browser into using it. They can then hijack the user’s session, gaining unauthorized access to the user’s account.
Session fixation exploits weaknesses in how a web application manages session IDs. Essentially, the vulnerable application fails to assign a new session ID during user authentication, enabling the attacker to utilize an existing session ID. Unlike Session Hijacking, which occurs after user login, Session Fixation establishes control over a session before user authentication.
Various techniques can be used to execute this attack, depending on how the web application handles session tokens:
Many web frameworks and libraries offer features to aid developers in implementing secure session management, which helps to mitigate session fixation vulnerabilities. These frameworks often include built-in mechanisms for generating, storing, and validating session IDs. They may allow for configuring session expiration, regenerating session IDs upon authentication, and ensuring secure transmission of session data. However, it could be useful for developers to effectively implement these practices within their application code as well, ensuring proper configuration and usage to mitigate session fixation and other vulnerabilities. Regular updates to libraries and frameworks are crucial, as they may contain patches or improvements related to session management security.
For most web server administrators, the best way of mitigating for session fixation vulnerabilities is to make sure that the software stack you use for authentication contains mitigations against such attacks and also up to date. If you are using a library which has a vulnerability which allows for session fixation, make sure to upgrade it as soon as you can.
Web apps, libraries, and frameworks take several steps to mitigate session fixation attacks. Those include generating random session IDs for each user session, expiring sessions after a period of inactivity, and implementing measures like session ID regeneration upon authentication. Your web app should always be using HTTPS for security and privacy, and it likewise offers an additional layer of protection against session fixation attacks: it’s much harder to intercept session IDs in transit if communication between the client and server is encrypted. Finally, your web app should also reject externally imposed session tokens, which will also help protect against this type of attack.
If you are going to be coding a web app with authentication capabilities, we recommend that read through this article and implement the following measures it recommends, which help protect the web application against session fixation attacks:
Go to the Try Hack Me website, create an account, and go through the room called OWASP Broken Access Control and follow the instructions.
Note: while this exercise provides a great learning opportunity on how adversaries could crack badly secured passwords, it does require quite a bit of free disk space and uses a tool which is only available on Windows and Linux. Since not all learners might be able to do this practice exercise, we have marked it as clearly optional. We encourage learners who want to learn more about rainbow tables and secure password storage, both those who can and cannot do the below exercise, to consult further reading through posts such as this one.
When authenticating users we need a way to verify whether they entered correct credentials. The easiest way of doing that is to store the password itself in a database. This is insecure, as anyone with access to that database could learn users’ plaintext passwords, and they would be revealed in case of a leak or application vulnerability. A simple protection can be implemented by storing a hash value of the password instead. This exercise will demonstrate how easy it is to break such protection and learn plaintext passwords from hashed values. The point of this exercise is not to make learners believe that all authentication mechanisms can be easily broken but rather to demonstrate how easy it is to break passwords which have only been hashed without any additional security mechanisms such as salting.
Rainbow tables are a smart way of reducing computation time in exchange for disk space when trying to brute-force a hashed password. They consist of pre-calculated chains of hashes that can be used to discover a hashed value (the plaintext password).
Given the hash value of 168f3c743786fea2e04aeeee33e112da
, try to discover the password using rainbow tables. 🌈 Use RainbowCrack (http://project-rainbowcrack.com/). The easiest way to run RainbowCrack might be to use Kali Linux (https://www.kali.org/) in a VM or booted from a LiveUSB (refer to the links in Basic information section at the beginning of this learning path for more info). The hashing algorithm is MD5 and the hash is unsalted.
Hint: the password is lowercase alphanumeric, max. 6 characters. Once you’ve installed RainbowCrack you can use the following command to generate the required table:
rtgen md5 loweralpha-numeric 1 6 0 3800 1000000 0
(Optional) Try to use the generated table to break another hash: feadfd87d487818698d63aedf385c4e2
.
Hint: If that fails you can try to generate more tables to increase the success rate of your table set (coverage). Just change the fifth parameter of the rtgen
command to different values (try 1-5).
Try to break the following salted hash: 93e99d25dd6e8f524f23814908b6c039
Generating a rainbow table requires specifying a hash algorithm to use, maximum length of the plaintext values were interested in and their character set. Those parameters only influence the time it takes for a table to be generated (amount of computation required).
Tables for shorter passwords with smaller character sets (eg. only lowercase letters) will take a shorter time to generate than tables for long passwords with numbers and special characters.
Additionally, you need to choose how many chains to generate and of what length. Those parameters are more complex to explain (see Philippe Oechslin’s whitepaper for more background) but have effects on coverage of the table. Only a subset of all possible plaintext values is included in each rainbow table.
The bigger the values of these parameters, the larger and more costly (in terms of CPU time) the table is, but also the more plaintext values can be discovered using it.
Pre-calculated tables for different hash functions, password lengths and character sets can be downloaded from the Internet (eg. https://freerainbowtables.com/) or obtained at IT security conferences and hacker camps (see https://dcddv.org/). For the purposes of this exercise we’ll generate our own!
You can install rainbowcrack on your system or use Kali Linux Live. For Kali, open a terminal window and run:
sudo apt update
sudo apt install rainbowcrack
This will install the software. You can use the rtgen
command to generate tables. According to its manual the command takes quite a few parameters:
rtgen hash_algorithm charset plaintext_len_min plaintext_len_max table_index chain_len chain_num part_index
We’ll use MD5 as our hash algorithm. We’ll be looking for passwords of length from 1 to 6 characters. We’ll use the loweralpha-numeric
charset, which includes lowercase letters and numbers only. We’re going to use 3800 for chain length, 1000000 for number of chains.
To generate our first table run:
sudo rtgen md5 loweralpha-numeric 1 6 0 3800 1000000 0
This command might take a while to execute, depending on your system configuration.
After generation, one more step is required before we can use our new tables:
sudo rtsort
This will sort the data to make using the table faster. rtcrack
will refuse to work with unsorted tables.
Let’s take a crack at our first hash:
rcrack . -h 168f3c743786fea2e04aeeee33e112da
This should take just a moment and reveal our plaintext password:
1 rainbow tables found
memory available: 11361376665 bytes
memory for rainbow chain traverse: 60800 bytes per hash, 60800 bytes for 1 hashes
memory for rainbow table buffer: 2 x 16000016 bytes
disk: ./md5_loweralpha-numeric#1-6_0_3800x1000000_0.rt: 16000000 bytes read
disk: finished reading all files
plaintext of 168f3c743786fea2e04aeeee33e112da is 1nfus3
statistics
----------------------------------------------------------------
plaintext found: 1 of 1
total time: 0.33 s
time of chain traverse: 0.22 s
time of alarm check: 0.11 s
time of disk read: 0.00 s
hash & reduce calculation of chain traverse: 7216200
hash & reduce calculation of alarm check: 4133612
number of alarm: 3194
performance of chain traverse: 32.80 million/s
performance of alarm check: 36.91 million/s
result
----------------------------------------------------------------
168f3c743786fea2e04aeeee33e112da 1nfus3 hex:316e66757333
Success! Now let’s try our second hash:
rcrack . -h feadfd87d487818698d63aedf385c4e2
The result:
1 rainbow tables found
memory available: 11236982784 bytes
memory for rainbow chain traverse: 60800 bytes per hash, 60800 bytes for 1 hashes
memory for rainbow table buffer: 2 x 16000016 bytes
disk: ./md5_loweralpha-numeric#1-6_0_3800x1000000_0.rt: 16000000 bytes read
disk: finished reading all files
statistics
----------------------------------------------------------------
plaintext found: 0 of 1
total time: 0.31 s
time of chain traverse: 0.20 s
time of alarm check: 0.11 s
time of disk read: 0.00 s
hash & reduce calculation of chain traverse: 7216200
hash & reduce calculation of alarm check: 4238786
number of alarm: 3324
performance of chain traverse: 36.08 million/s
performance of alarm check: 37.18 million/s
result
----------------------------------------------------------------
feadfd87d487818698d63aedf385c4e2 <not found> hex:<not found>
We didn’t find our hash in this table. Let’s generate a few more tables with the hope of increasing our coverage. We’ll use the same rtgen
command, only changing the table_index
parameter:
sudo rtgen md5 loweralpha-numeric 1 6 1 3800 1000000 0
sudo rtgen md5 loweralpha-numeric 1 6 2 3800 1000000 0
sudo rtgen md5 loweralpha-numeric 1 6 3 3800 1000000 0
sudo rtgen md5 loweralpha-numeric 1 6 4 3800 1000000 0
sudo rtgen md5 loweralpha-numeric 1 6 5 3800 1000000 0
sudo rtsort .
Let’s try again:
rcrack . -h feadfd87d487818698d63aedf385c4e2
The result:
6 rainbow tables found
memory available: 10784174899 bytes
memory for rainbow chain traverse: 60800 bytes per hash, 60800 bytes for 1 hashes
memory for rainbow table buffer: 6 x 16000016 bytes
disk: ./md5_loweralpha-numeric#1-6_0_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_1_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_2_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_3_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_4_3800x1000000_0.rt: 16000000 bytes read
disk: ./md5_loweralpha-numeric#1-6_5_3800x1000000_0.rt: 16000000 bytes read
disk: finished reading all files
plaintext of feadfd87d487818698d63aedf385c4e2 is trolo0
statistics
----------------------------------------------------------------
plaintext found: 1 of 1
total time: 0.54 s
time of chain traverse: 0.41 s
time of alarm check: 0.13 s
time of disk read: 0.02 s
hash & reduce calculation of chain traverse: 14432400
hash & reduce calculation of alarm check: 4766264
number of alarm: 4606
performance of chain traverse: 35.46 million/s
performance of alarm check: 36.66 million/s
result
----------------------------------------------------------------
feadfd87d487818698d63aedf385c4e2 trolo0 hex:74726f6c6f30
Got it! Additional tables increased the coverage and the hash was found out.
An improvement on using simple hashing for password protection is called “salting” the hashes – adding an application-specific secret to the plaintext value. That increases the length and character set of the hashed value, making a rainbow table approach infeasible. Trying the third (salted) hash given in this exercise will fail with this method as it would require rainbow tables bigger than can be currently generated (and stored).
Complete the exercise we described above: carry out a SQL injection on DVWA and compare the hashes you discovered to those you found on a hash lookup site.
Broken authentication represents a significant threat to the security of web applications, allowing attackers to compromise user credentials, hijack sessions, and gain unauthorized access to sensitive information. In this set of multiple-choice questions, you can explore the concept of broken authentication and delve into the various risks associated with this vulnerability. Additionally, if you have a mentor or with a peer you can examine different types of flaws that can lead to compromised authentication mechanisms and discuss specific mitigation strategies tailored to address each of these vulnerabilities effectively.
Enhance your understanding of web application security and learn how to mitigate the risks posed by broken authentication with these questions:
Question 1. What is broken authentication in the context of web application security?
A) A vulnerability that allows attackers to execute arbitrary code on the server.
B) An exploit that grants unauthorized access to restricted parts of a web application.
C) A weakness in the authentication mechanism of a web application, leading to compromised user credentials.
D) A security flaw that enables attackers to intercept communication between the client and server.
Question 2. What are the potential risks associated with broken authentication vulnerabilities?
A) Unauthorized access to sensitive data and user accounts.
B) Exposure of session tokens, leading to session hijacking attacks.
C) Compromise of user credentials, including passwords and authentication tokens.
D) All of the above.
Question 3. Which of the following is NOT an example of a mitigation mechanism for broken authentication vulnerabilities?
A) Implementing multi-factor authentication (MFA) for user accounts.
B) Enforcing strong password policies, including regular password rotation.
C) Disabling HTTPS to prevent interception of authentication credentials.
D) Implementing account lockout mechanisms to prevent brute force attacks.
Question 4. Which type of flaw may lead to compromised authentication mechanisms by allowing attackers to guess or crack user passwords?
A) Session Fixation
B) Cross-Site Request Forgery (CSRF)
C) Insufficient Password Complexity
D) Cross-Site Scripting (XSS)
Question 5. What is a specific example of a mitigation strategy for addressing the flaw of insufficient password complexity?
A) Implementing CAPTCHA challenges during the login process.
B) Enforcing password length and complexity requirements.
C) Encrypting authentication tokens to prevent interception.
D) Whitelisting trusted IP addresses for accessing the login page.
Question 6. Which mitigation strategy aims to prevent attackers from exploiting session fixation vulnerabilities?
A) Implementing session timeout mechanisms.
B) Encrypting session cookies using HTTPS.
C) Regenerating session identifiers after successful authentication.
D) Enforcing strong password policies for user accounts.
Question 7. What type of flaw may lead to compromised authentication mechanisms by allowing attackers to hijack active user sessions?
A) Insufficient Session Expiration
B) Insecure Token Storage
C) Cross-Site Scripting (XSS)
D) Cross-Site Request Forgery (CSRF)
Question 8. Which mitigation strategy addresses the flaw of insecure token storage by securely managing authentication tokens?
A) Storing tokens in plaintext within client-side cookies.
B) Encrypting tokens using a symmetric encryption algorithm.
C) Implementing secure password hashing algorithms.
D) Using HTTP headers for transmitting authentication tokens.
Question 9. What is a specific example of a mitigation strategy for preventing session fixation attacks?
A) Rotating session identifiers after a successful login.
B) Implementing multi-factor authentication (MFA).
C) Using CAPTCHA challenges to verify user authenticity.
D) Enforcing strict input validation on the login form.
Question 10. What type of flaw may lead to compromised authentication mechanisms by allowing attackers to forge requests to the web application while authenticated as another user?
A) Insufficient Session Expiration
B) Insufficient Transport Layer Protection
C) Cross-Site Scripting (XSS)
D) Cross-Site Request Forgery (CSRF)
Credential stuffing
FreeOverview of an attack where adversaries test many login combinations, often from data breaches.
Cryptographic hash function
FreeOverview of cryptographic hash functions and their importance to security.
Rainbow table
FreeList of precomputed hash functions used in brute-forcing encrypted content.
Salt
FreeExplanation of a salt added to passwords before encryption to prevent rainbow table attacks.
Traditional crypt
FreeOverview of early password encryption algorithms from the 1970s, no longer in use.
Cryptographic right answers
FreeList of recommended cryptographic solutions for modern use.
Hash lookup
FreeTool for reverse lookup of hashes, useful for working with tools like DVWA.
Password storage cheat sheet & Forgot password cheat sheet, Resource 1
FreeBest practices for storing encrypted passwords and managing password recovery.
Password storage cheat sheet & Forgot password cheat sheet, Resource 2
FreeBest practices for storing encrypted passwords and managing password recovery.
International SMS Fraud
FreeCase study on SMS abuse by adversaries and reasons not to rely on SMS for authentication.
Testing for Account Enumeration and Guessable User Account
FreeWorkflow for testing web app security to see if it’s possible to enumerate usernames.
Have I Been Pwned
Free for low volumes of queriesService to check if a username has been featured in any data breaches.
Introducing 306 Million Freely Downloadable Pwned Passwords
FreeBlog post by Troy Hunt on finding millions of leaked passwords and their implications.
Common credentials
FreeLists of commonly used credentials, like passwords.
NIST password guidelines
FreeBlog post outlining NIST password guidelines and their rationale.
Phishing
FreeOverview of phishing attacks, their history, and methods used by adversaries.
SIM swap scam
FreeOverview of SIM swap scams and reasons not to rely on SMS-based authentication.
U2F Technical Overview
FreeDetailed look at U2F authentication method using physical security keys.
Two factor authentication backup codes: Google
FreeGuides on managing backup methods for two factor authentication by Google and GitHub.
Two factor authentication backup codes: Github
FreeGuides on managing backup methods for two factor authentication by Google and GitHub.
Multifactor authentication cheat sheet
FreeOverview of multifactor authentication and best practices for implementation.
Congratulations on finishing Module 3!
Mark the checkbox to confirm your completion and continue to the next module.
Marks the current module as completed and saves the progress for the user.
You've completed all modules in this learning path.