authentication

408 notes in this subject, read out of this brain and free to use. This is page 6 of 7.

Security questions and MFA do not constitute multi-factor authentication

A combination of password and security questions does not constitute MFA because both factors are the same type: something you know. True MFA requires multiple different factor types.

Desired characteristics for security questions

Security questions used for password reset must meet these characteristics: Memorable (user can recall answer years later), Consistent (answer does not change over time), Applicable (user can answer the question), Confidential (answer is hard for attacker to obtain), and Specific (answer is clear to the user).

User-defined vs system-defined security questions

User-defined security questions allow users to choose from a list and provide their own answer. This is easy to implement but users often choose weak answers. System-defined security questions are based on information already known about the user, preventing weak choices but requiring sufficient stored user data and ensuring that data is difficult for attackers to obtain.

Examples of bad security questions

Bad security questions include: 'When is your date of birth?' (easy for attacker to discover), 'What is your memorable date?' (most users enter birthday), 'What is your favourite movie?' (likely to change), 'What is your favourite cricket team?' (not applicable to most), 'What is the make and model of your first car?' (small range of answers), 'What is your nickname?' (could be guessed from social media).

Examples of good security questions

Good security questions include: What is the name of a college you applied to but didn't attend? What was the name of the first school you remember attending? Where was the destination of your most memorable school field trip? What was your maths teacher's surname in your 8th year of school? What was the name of your first stuffed toy? What was your driving instructor's first name?

Should users be allowed to write their own security questions

It is generally best not to allow users to write their own security questions. While users might choose very strong and unique questions, there is significant risk they will choose weak questions or even set recovery questions as password reminders, allowing account compromise.

Enforcing minimum answer length for security questions

Enforcing a minimum length for answers prevents users from entering very short strings like 'a' or '123'. However, depending on the question, this could prevent valid answers like two-letter names ('Li') or four-letter colors ('blue'). Answers should be checked against a denylist including: the username or email address, the user's current password, and common strings such as '123' or 'password'.

Periodic renewal of security questions

If security questions are not part of main authentication, consider periodically prompting users to review questions and verify they still know answers, such as when changing passwords after expiration. This allows updates to changed answers and increases likelihood of remembering them if needed for account recovery.

System-defined questions based on personal details are weak

System-defined security questions based on personal details like full name, address, and date of birth provide very weak authentication because attackers can easily obtain this information from social media or other public sources.

When security questions should never be used

Security questions should never be relied upon as the sole mechanism to authenticate a user.

Appropriate use cases for security questions

Security questions can provide a useful additional layer of security when stronger factors are not available. Common use cases include: logging in, resetting a forgotten password, and resetting a lost MFA token.

Authentication flow with security questions supplementing passwords

When security questions supplement passwords where MFA is unavailable, the flow is: user enters username and password, if correct user is presented with security question(s), if answers are correct user is logged in. If answers to security questions are incorrect, this counts as a failed login attempt and the account lockout counter is incremented.

Forgotten password or lost MFA token flow to prevent account enumeration

To prevent user account enumeration, the forgotten password or lost MFA token flow should be: user enters email address and solves CAPTCHA, application displays generic message like 'If the email address was correct, an email will be sent to it', an email with randomly generated single-use link is sent, user clicks link, user is presented with security question(s), if answer is correct user can enter new password.

Storage of security question answers

Answers to security questions may contain personal information and may be reused between applications. They should be treated like passwords and stored using a secure hashing algorithm such as Bcrypt.

Case-insensitive comparison of security question answers

Comparing answers in a case-insensitive manner makes it easier for users. The simplest way to implement this is to convert the answer to lowercase before hashing it for storage, and then lowercase the user-provided answer before comparing.

Updating security question answers requires re-authentication

When users update their security question answers, this is a sensitive operation. Users should be required to re-authenticate by entering their password or ideally using MFA to prevent attackers from updating questions if they gain temporary account access.

Using multiple security questions

Users can be asked a single question or multiple questions simultaneously. Multiple questions provide greater assurance, especially if diverse, as attacker would need to obtain more information. A mixture of user-defined and system-defined questions can be very effective.

Step-up authentication for high-risk activities

Organizations may require MFA in the form of step-up authentication for specific scenarios during an active session combined with requests for high-risk activities such as large currency transactions or privileged administrative configuration changes.

Allowlist trusted IP ranges to reduce MFA friction

For enterprise applications, known trusted IP ranges can be added to an allowlist so that MFA is not required when users connect from these ranges, balancing security with usability.

Graduated response to abuse based on multiple factors

IP mitigation decisions (including blocking and CAPTCHA) should consider multiple abuse scenarios rather than relying on a single predictable volume limit. Short bursts and long time periods should be considered, as well as high request volume and low but consistent volumes. Decisions should consider IP address classification (residential vs hosting) and geolocation to adjust thresholds and reduce impact on legitimate users.

IP mitigations should be temporary

Mitigations, especially blocking an IP address, should be temporary. Processes should be in place to remove an IP address from a mitigated state as abuse declines or stops.

Use IP intelligence to identify distributed credential stuffing

Correlate authentication traffic with proxy and IP address intelligence, as well as hosting provider IP address ranges, to identify highly distributed credential stuffing attacks. Many credential stuffing toolkits like Sentry MBA use proxy networks to distribute requests across unique IP addresses, defeating per-IP rate limiting and blocklists. Commercial and public sources of IP address intelligence and classification can be leveraged for this purpose, and some hosting providers publish their own IP address space like AWS.

Store and monitor account IP address authentication history

Store an account's IP address authentication history. If a recent IP address is added to a block or mitigation list, it may be appropriate to lock the account and notify the user.

Device fingerprinting factors from HTTP headers

Device fingerprinting can be obtained passively from HTTP headers, including operating system and version, browser and version, and language (particularly the User-Agent header).

JavaScript-based device fingerprinting factors

Using JavaScript, additional device fingerprinting information can be accessed: screen resolution, installed fonts, and installed browser plugins. The fingerprintjs2 JavaScript library can be used to carry out client-side fingerprinting.

Device fingerprinting can be spoofed by attackers

Device fingerprinting information is provided by the client and can potentially be spoofed by an attacker. In some cases spoofing is trivial (such as modifying User-Agent), but in other cases it may be more difficult.

Device history and remembered devices management

Most users have multiple devices or browsers they use. It is common to define a process for users to view their device history and manage their remembered devices, rather than simply blocking attempts that do not match existing fingerprints.

Connection fingerprinting techniques

Connection fingerprinting techniques include JA3, HTTP/2 fingerprinting, and HTTP header order. These techniques typically focus on how a connection is made and may provide more accurate results than defenses relying on IP address or request data like user agent string.

Combine connection fingerprinting with device fingerprinting

Connection fingerprinting may be used with other defenses to ascertain the truthfulness of authentication requests. For example, if user agent header and device fingerprint indicate a mobile device, but connection fingerprint indicates a Python script, the request is likely suspect.

Require unpredictable usernames to prevent credential stuffing

Requiring users to create their own username when registering makes it harder for attackers to obtain valid username/password pairs for credential stuffing, since many available credential lists only include email addresses. Providing generated usernames provides higher protection but is less user-friendly. Generated usernames must not be predictable (based on full name or sequential numeric IDs) as this could facilitate password spraying attacks.

Email addresses as usernames enable credential stuffing

A significant number of websites use email addresses as usernames. Since most users have a single email address for all their accounts, this combination of email and password is very effective for credential stuffing attacks.

Multi-step login processes increase attack difficulty

Multi-step login processes, such as requiring username and password to be entered sequentially or requiring a random CSRF Token before login, make attacks slightly more difficult and double the number of requests an attacker must make. However, they should not facilitate user enumeration.

Require JavaScript and block headless browsers

Most credential stuffing tools make direct POST requests and do not execute JavaScript. By requiring attackers to evaluate JavaScript in responses (for example to generate a valid token), this forces use of real browsers with automation frameworks like Selenium or Headless Chrome, or implement JavaScript parsing with tools like PhantomJS. Techniques exist to identify Headless Chrome and PhantomJS. Note that blocking visitors without JavaScript reduces website accessibility.

Degradation techniques to slow credential stuffing

Degradation measures increase attack completion time by: incrementally increasing JavaScript complexity, requiring users to solve cryptographic or Proof-of-Work computational puzzles, introducing long wait periods before responding to requests, returning overly large HTML assets, or returning randomized error messages. These provide security without user tracking and require context-dependent risk assessment.

CAPTCHA for bot detection but not perfect defense

Requiring users to solve CAPTCHAs for each login attempt can help identify automated/bot attacks and prevent automated login attempts, potentially slowing credential stuffing or password spraying. However, CAPTCHAs are not perfect and tools exist to break them with reasonably high success rates. Monitoring CAPTCHA solve rates may identify impact to legitimate users or automated CAPTCHA breaking technology.

Risk-based CAPTCHA to improve usability

To improve usability, CAPTCHA may be required only when a login request is considered suspicious or high risk, using criteria such as new browser/device, unusual location, or untrusted IP addresses.

Secondary passwords and security questions do not constitute MFA

Users can be prompted to provide additional security information such as a PIN, specific characters from a secondary password or memorable word, or answers to security questions. However, this does not constitute multi-factor authentication since both factors are the same (something you know). It can still provide useful protection where proper MFA cannot be implemented.

Verify new passwords against breached password databases

ASVS v4.0 Password Security Requirements provision 2.1.7 requires verifying that new passwords are not present in breached password datasets. Free services like Pwned Passwords (haveibeenpwned.com) can be used for this validation, either by hosting a copy of the application or using the API.

Notify users of successful password logins followed by MFA failure

If a login attempt has the correct password but then fails subsequent MFA checks, the user should be notified so they can change their password. However, users should not be notified of attempts with incorrect passwords as this is normal attack activity.

Lock account pending verification for suspicious password reset activity

If a user requests multiple password resets from different devices or IP addresses, it may be appropriate to prevent further access to the account pending further user verification processes. This indicates possible account compromise.

Display recent login history to users

Details related to current or recent logins should be visible to the user. For example, when logging in, the date, time and location of their previous login attempt could be displayed. This helps users identify unauthorized access.

Allow users to view and terminate active sessions

If the application supports concurrent sessions, users should be able to view a list of all active sessions and terminate any sessions that are not legitimate.

Risk-based MFA triggers for suspicious logins

MFA can be required only in specific circumstances where login attempts may not be legitimate, including: login from a new browser/device or IP address, unusual country or location, specific countries considered untrusted, IP addresses on known denylists or associated with anonymization services (proxy or VPN), IP addresses that have tried to login to multiple accounts, or login attempts appearing scripted or from a bot.

Avoid overwhelming users with security notifications

When notifying users of suspicious or unusual activity, care should be taken not to overwhelm them with large numbers of unimportant notifications or they will ignore or delete them. Also consider that the user's email account may have been compromised due to password reuse across sites.

Implement defenses considering failure of individual defenses

Implement defenses that consider the impact of individual defenses being defeated or failing. For example, client-side defenses such as device fingerprinting or JavaScript challenges may be spoofed or bypassed and other layers should be implemented to account for this.

Generate volume metrics for all defenses

Each defense should generate volume metrics for use as a detective mechanism. Metrics should include both detected and mitigated attack volume and allow filtering on fields such as IP address. Monitoring and reporting may identify defense failures or presence of unidentified attacks.

Coordinate between teams managing multiple defenses

When administration of different defenses is performed by multiple teams, care should be taken to ensure communication and coordination when separate teams are performing maintenance, deployment or modifying individual defenses.

Implement different defenses for different user roles

Where an application has multiple user roles, different defenses may be appropriate for different roles. For example, it may not be feasible to enforce MFA for all users, but it should be possible to require that all administrators use it.

Gait analysis for MFA

Gait analysis based on way user walks using cameras and sensors, often used in physical security systems but not widely in web applications. Mobile applications may use accelerometer to detect user gait as additional factor but still largely theoretical. Pros: very difficult to spoof, may be used without additional user interaction. Cons: requires specific hardware to implement, use outside physical security systems not widely tested.

Five authentication factors for MFA

Multifactor authentication uses five types of evidence (factors): Something You Know (passwords, PINs, security questions), Something You Have (OTP tokens, U2F tokens, certificates, smart cards, email, SMS and phone calls), Something You Are (fingerprints, facial recognition, iris scans, voice recognition), Somewhere You Are (source IP address, geolocation, geofencing), and Something You Do (behavioral profiling, keystroke and mouse dynamics, gait analysis). In practice, only the first three are common in web applications.

MFA factors must be independent and cannot be multiple instances of same factor

Requiring multiple instances of the same authentication factor, such as both a password and a PIN, does not constitute MFA and offers minimal additional security. The factors used should be independent of each other and should not be able to be compromised by the same attack.

Quick recommendations for implementing MFA

General recommendations for most applications include: require some form of MFA for all users; provide the option for users to enable MFA on their accounts using TOTP; require MFA for administrative or other high privileged users; implement a secure procedure to allow users to reset their MFA; consider MFA as a service using a third-party provider.

When to require MFA in applications

The most important place to require MFA is when the user logs in. Depending on functionality, it may also be appropriate to require MFA for: changing passwords or security questions, changing the email address associated with the account, disabling MFA, and elevating a user session to an administrative session. If the application provides multiple ways to authenticate, all should require MFA or have other protections.

OTP handling and storage minimum requirements

OTP implementations SHOULD: enforce a short time-to-live (TTL), ensure OTPs are single use, apply strict attempt limits, and invalidate the OTP on successful verification. OTP implementations SHOULD NOT: log OTP values or store OTPs in long-term plaintext form. To further reduce risk, it is RECOMMENDED to: generate OTPs using a cryptographically secure random number generator, consider 8-digit or longer codes where usability allows, and on resend, generate a new OTP and overwrite the old record.

OTP hashing purpose and limitations

Hashing OTPs is recommended not for strong offline attack resistance (since OTPs have small keyspace of ~1 million for 6-digit codes and can be brute-forced quickly), but to: prevent accidental disclosure via logs, metrics, or debugging tools; reduce blast radius if database is briefly exposed during OTP's validity window; enforce good secret-handling discipline and avoid plaintext storage by default. The goal is short-term exposure protection, not long-term cryptographic secrecy.

Handling failed login attempts with MFA

When a user enters their password but fails to authenticate using a second factor, the system should: prompt the user to try another form of MFA; allow the user to attempt to reset their MFA; notify the user of the failed login attempt and encourage password change if unrecognized. The notification should include the time, browser and geographic location of the login attempt, should be displayed next time they login, and optionally emailed as well.

MFA recovery methods

Possible methods for recovering access when users lose or cannot use their MFA factors include: providing single-use recovery codes when first setting up MFA; requiring setup of multiple types of MFA so unlikely to lose access to all at once; mailing a one-use recovery code or new hardware token to registered address; requiring user to contact support team with rigorous identity verification; requiring another trusted user to vouch for them. Choice depends on application security level and user control.

Best practices for changing MFA factors

When users update authentication factors: require reauthentication with an existing enrolled factor before allowing changes; do not rely solely on active session as it may be hijacked; treat factor replacement as high-risk action and apply risk-based checks such as new device or unusual location; notify user through out-of-band channels like email or push notification whenever MFA factor is changed; consider applying delays or step-up verification for high-value accounts.

Security questions are not acceptable MFA factor

Security questions are no longer recognized as an acceptable authentication factor per NIST SP 800-63. Account recovery is an alternate way to authenticate and should be no weaker than regular authentication. Security questions have easily guessable answers, answers can be obtained from social media, questions must be remembered years later, and they are susceptible to phishing.

Passkeys based on FIDO2 standard

Passkeys based on FIDO2 standard combine characteristics of possession-based and either knowledge-based or inherence-based authentication. The user is required to have a physical device such as a mobile phone and to enter a PIN or use biometric authentication to authenticate. The device then generates a cryptographic key used to authenticate with the server. This is a very secure form of MFA resistant to phishing attacks while also being frictionless for the user.

Give your agent this brain