authentication & account security

46 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Authentication failures require continuous monitoring

Failed authentication attempts provide critical early indicators of credential-based attacks such as brute-force, credential-stuffing, and password-spraying. Monitoring repeated failures for the same account, failures from multiple IP addresses, or rapid bursts of login attempts helps detect account takeover attempts before they succeed. This aligns with OWASP ASVS 7.1.1 for authentication failure logging requirements.

Brute-force attack prevention modules for Node.js

Use `express-bouncer`, `express-brute`, or `rate-limiter` modules to prevent brute-force attacks on login pages. `express-bouncer` and `express-brute` increase delay for failed requests and can be applied to specific routes. `rate-limiter` limits requests per IP address within a specified time period. Additionally, use CAPTCHA (e.g., `svg-captcha` module) and account lockout mechanisms to deter attackers.

Do not require periodic password changes

According to NIST guidelines, verifiers should not mandate arbitrary password changes such as periodic password resets. Instead, encourage users to pick strong passwords and enable Multifactor Authentication.

Minimum password length without MFA

When MFA is not enabled, passwords shorter than 15 characters are considered weak according to NIST SP800-63B.

Maximum password length requirement

Maximum password length should be at least 64 characters to allow passphrases, as specified in NIST SP800-63B.

Password composition rules deprecated

There should be no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. Allow usage of all characters including unicode and whitespace.

Password blocklist defense mechanism

Block common and previously breached passwords to prevent users from selecting passwords that are commonly used or already known to attackers. This aligns with NIST SP 800-63B recommendations and helps protect against credential stuffing and password guessing attacks.

Pwned Passwords service for blocklist checking

Pwned Passwords is a service where passwords can be checked against previously breached passwords. The API is available at https://haveibeenpwned.com/API/v3#PwnedPasswords. Alternatively, the Pwned Passwords database can be downloaded using the PwnedPasswordsDownloader tool to host it yourself.

Credential rotation on compromise

Ensure credential rotation when a password leak occurs at the time of compromise identification or when authenticator technology changes.

User IDs should be randomly generated

User IDs should be randomly generated to prevent the creation of predictable or sequential IDs, which could pose a security risk especially in systems where User IDs might be exposed or inferred from external sources.

Generic error messages prevent user enumeration

An application must respond with a generic error message regardless of whether the user ID or password was incorrect, the account does not exist, or the account is locked or disabled. This prevents creation of a discrepancy factor and user enumeration attacks.

Generic login error message example

The correct response for a failed login is: 'Login failed; Invalid user ID or password.' This is preferable to responses like 'Login for User foo: invalid password', 'Login failed, invalid user ID', 'Login failed; account disabled', or 'Login failed; this user is not active.'

Generic password recovery error message

For password recovery features, the correct generic response is: 'If that email address is in our database, we will send you an email to reset your password.' Avoid responses like 'We just sent you a password reset link' or 'This email address doesn't exist in our database.'

Generic account creation response

For account creation, the correct response is: 'A link to activate your account has been emailed to the address provided.' Avoid responses like 'This user ID is already in use' or 'Welcome! You have signed up successfully.'

Prevent timing-based user enumeration attacks

The processing time must be approximately the same whether a user exists or not to prevent time-based enumeration attacks. Do not use the 'quick exit' approach where non-existent users are errored immediately; instead, always hash the password and perform the same lookup process regardless of whether the user exists.

Account lockout counter should be per-account not per-IP

The counter of failed logins should be associated with the account itself, rather than the source IP address, in order to prevent an attacker from making login attempts from a large number of different IP addresses.

Exponential lockout duration mechanism

Rather than implementing a fixed lockout duration such as ten minutes, some applications use an exponential lockout where the lockout duration starts as a very short period such as one second, but doubles after each failed login attempt.

Current password verification in change password feature

When developing a change password feature, require current password verification to ensure that it is the legitimate user who is changing the password. This prevents an attacker from changing a password on an active session of another user.

Password comparison function requirements

Use secure password comparison functions provided by the language or framework, such as password_verify() in PHP. The comparison function must have a maximum input length to protect against denial of service, explicitly set the type of both variables to protect against type confusion attacks, and return in constant time to protect against timing attacks.

TLS required for login page and authenticated pages

The login page and all subsequent authenticated pages must be exclusively accessed over TLS or other strong transport. Failure to utilize TLS allows an attacker to modify the login form action or view unencrypted session IDs.

Re-authentication for sensitive features

Require re-authentication before updating sensitive account information such as password or email address, or before sensitive transactions. This mitigates CSRF and session hijacking attacks and protects against temporary physical access or session ID theft.

Re-authentication on high-risk account activity

Trigger re-authentication when unusual login patterns, IP address changes, device enrollments occur, after password resets or account recovery, or for high-risk actions like changing payment details or adding trusted devices.

Re-authentication mechanisms: adaptive, MFA, and challenge-based

Re-authentication can be implemented through adaptive authentication using risk-based models, Multi-Factor Authentication for additional verification on sensitive actions, or challenge-based verification using challenge questions or secondary methods.

Do not allow sensitive internal accounts to log in via front-end UI

Do not allow login with sensitive accounts such as backend, middleware, or database accounts to any front-end user interface.

Do not reuse internal authentication for public access

Do not use the same authentication solution such as IDP or Active Directory that is used internally for unsecured access such as public access or DMZ.

Email address as username with verification

Users should be permitted to use their email address as a username, provided the email is verified during sign-up. Users should also have the option to choose a username other than an email address.

TLS Client Authentication use cases

TLS Client Authentication is appropriate when the user has access from only a single computer/browser, when users are not frightened by installing TLS certificates, when the website requires extra security, or for intranet websites. It is generally not appropriate for widely available public websites with average users.

MFA effectiveness against account compromises

Multi-factor authentication is by far the best defense against password-related attacks including brute-force attacks. Analysis by Microsoft suggests that MFA would have stopped 99.9% of account compromises.

Account lockout policy considerations

When implementing account lockout policy, consider the lockout threshold (number of failed attempts before lockout), observation window (time period attempts must occur within), and lockout duration (how long the account is locked). Care must be taken to prevent denial of service by locking out legitimate users.

Forgotten password functionality during account lockout

Allow the use of the forgotten password functionality to log in even if the account is locked out, to prevent denial of service attacks that lock out legitimate user accounts.

Security questions not multi-factor authentication

Security questions do not constitute multi-factor authentication because both factors are the same (something you know). Security questions are often weak and have predictable answers, so they must be carefully chosen.

OAuth 2.0 is authorization not authentication

OAuth is an authorization framework for delegated access to APIs, not an authentication protocol. OAuth 2.0 and 2.1 should be used for authorization purposes.

OpenID Connect provides authentication via ID Token

OpenID Connect is an identity layer on top of OAuth 2.0. It defines how a relying party verifies the end user's identity using an ID Token (a signed JWT) and how to obtain user claims in an interoperable way. Use OIDC for authentication/SSO; use OAuth for authorization to APIs.

OpenID 2.0 is obsolete

OpenID 2.0 is a separate legacy authentication protocol that has been superseded by OpenID Connect and is considered obsolete. New systems should not implement OpenID 2.0.

SAML 2.0 is recommended version

Security Assertion Markup Language SAML 2.0 is the most recommended version as it is very feature-complete and provides strong security. SAML is XML-based, supports both service provider and identity provider initiated authentication, and is often preferred for enterprise applications.

FIDO2 and WebAuthn enable Passkeys technology

FIDO2 and WebAuthn, encompassing previous FIDO standards (UAF/U2F), form the foundation of modern Passkeys technology. Passkeys enable users to securely log in using local user verification such as biometrics or device PINs, often with credential synchronization across devices.

Password manager compatibility requirements

Web applications should not make the job of password managers more difficult by implementing standard HTML forms for username and password input with appropriate type attributes, avoiding plugin-based login pages, implementing reasonable maximum password length of at least 64 characters, allowing any printable characters in passwords, allowing users to paste into username/password/MFA fields, and allowing Tab key navigation between fields.

Email address change process without MFA

When a user without MFA wants to change their registered email address: 1) Confirm validity of authentication cookie/token, 2) Describe the process, 3) Ask for proposed new email address, 4) Request current password verification, 5) Store proposed change as pending, 6) Create and store three time-limited nonces, 7) Send confirmation-required emails to both current and proposed new addresses, 8) Handle responses accordingly.

Adaptive authentication based on risk factors

Adaptive or risk-based authentication requires different authentication stages depending on environmental and contextual attributes such as data sensitivity, time of day, user location, IP address, or device fingerprint. Different risk tiers can map to different actions such as allow, CAPTCHA, step-up MFA, block, or revoke session.

Adaptive authentication implementation questions

When implementing adaptive authentication, consider: 1) Corporate and regulatory policy alignment, 2) Which user/device attributes to monitor at session start, 3) Which signals need refresh during session and at what cadence, 4) Signal accuracy and handling of missing data, 5) Scoring model type (weights, thresholds, ML, rule-based, hybrid), 6) Where the model runs (edge, API gateway, central service), 7) Action mapping to risk tiers, 8) User-facing messages and error codes, 9) Code/platform layers for risk engine invocation, 10) Propagation across web, mobile, API clients, 11) Token/cookie mutation when risk escalates, 12) State synchronization across concurrent devices/tabs, 13) Monitoring and alerting for suspicious activity.

zxcvbn-ts library for password strength meter

The zxcvbn-ts library can be used to implement a password strength meter to help users create more complex passwords. Other language implementations of zxcvbn are listed in the zxcvbn GitHub repository, but check the age and maturity before use.

Do not silently truncate passwords

Do not silently truncate passwords. The Password Storage Cheat Sheet provides guidance on how to handle passwords longer than the maximum length.

Long password denial of service risk

Certain implementations of hashing algorithms may cause long password denial of service attacks, so care should be taken when allowing very long passwords.

NIST SP800-63B on password entropy estimation

According to NIST SP800-63B, estimating entropy for user-chosen passwords is challenging. NIST recommends length and blocklist checks over composition or entropy math. Entropy estimates rely on assumptions about the search space and should be treated as illustrative rather than as absolute measures of password strength.

Brute force, credential stuffing, and password spraying attacks

Common automated attacks include: Brute Force (testing multiple passwords from a dictionary against a single account), Credential Stuffing (testing username/password pairs obtained from another site breach), and Password Spraying (testing a single weak password against many different accounts).

CAPTCHA as defense-in-depth control

An effective CAPTCHA can help prevent automated login attempts, but many implementations have weaknesses that allow automated solving or outsourcing. CAPTCHA should be viewed as a defense-in-depth control to make brute-force attacks more time-consuming and expensive rather than as a preventative. It may be more user-friendly to require CAPTCHA only after a small number of failed login attempts.

Give your agent this brain