Hardware OTP tokens characteristics and trade-offs
Hardware OTP tokens like RSA SecureID generate constantly changing numeric codes (typically six digits every 60 seconds) that must be submitted when authenticating. Pros: almost impossible for remote attacker to compromise, can be used without mobile phone. Cons: expensive and complicated to deploy, long replacement time if lost, some require backend server introducing vulnerabilities, stolen tokens usable without PIN, susceptible to phishing (though short-lived).
Software OTP tokens (TOTP) implementation and standardization
Software OTP tokens using Time-based One-Time Password (TOTP) involve user installing TOTP application on mobile phone and scanning QR code from web application providing initial seed. Authenticator app then generates six digit number every 60 seconds. Most websites use standardized TOTP tokens allowing any compatible authenticator app. A small number use variants like Symantec requiring specific app, which should be avoided in favor of standards-based approach.
Universal Second Factor (U2F) tokens
Universal Second Factor is a standard for USB/NFC hardware tokens implementing challenge-response based authentication via button press or NFC tap rather than manual code entry. Most common U2F token is YubiKey. Pros: resistant to phishing since private key never leaves token, simpler user experience than typing codes, resistant to remote compromise, natively supported by major browsers, no mobile phone required. Cons: significant costs and administrative overheads, stolen tokens usable without PIN, users likely to forget USB-connected tokens.
Digital certificates for MFA (X.509 client certificates)
Digital certificates are files stored on user's device automatically provided alongside password when authenticating. Most common type is X.509 certificates known as client certificates. Pros: no need to purchase hardware tokens, simple once installed, centrally managed and revoked, resistant to phishing. Cons: requires backend Private Key Infrastructure (PKI), difficult installation particularly in restricted environments, enterprise SSL-decrypting proxies prevent use, can be stolen if system compromised.
Smart cards for MFA
Smart cards are credit-card size cards with chip containing digital certificate unlocked with PIN, commonly used for operating system authentication but rarely for web applications. Pros: stolen smartcards cannot be used without PIN, usable across multiple applications and systems, resistant to phishing. Cons: same costs and overheads as hardware tokens for managing and distribution, not natively supported by modern browsers requiring third-party software, home systems often lack smartcard readers, requires backend PKIs.
SMS and phone calls for MFA restrictions
NIST SP 800-63B-4 designates SMS and PSTN-delivered codes as a restricted authenticator because of SS7 interception, SIM-swap, and number-porting attacks. Do not use SMS for high-value or PII-handling applications such as healthcare and banking. Where SMS is the only available factor, document the risk acceptance, enforce per-account rate limits, monitor for SIM-swap signals, and plan migration to TOTP, push notifications, or WebAuthn/FIDO2.
SMS and phone call MFA disadvantages
SMS and phone calls for MFA have multiple cons: requires user to have mobile device or landline, requires signal or internet access to receive call or message, calls and SMS may cost money requiring protection against attackers requesting large number of messages, susceptible to SIM swapping attacks, SMS may be received on same device user is authenticating from, susceptible to phishing, SMS may be previewed when device locked, SMS may be read by malicious or insecure applications.
Email verification for MFA limitations
Email verification requires user to enter a code or click link sent to email address. Debate exists whether email constitutes MFA because if user has no MFA on email account, it only requires knowledge of email password (often same as application password). Pros: very easy to implement, no separate hardware or mobile device requirements. Cons: relies entirely on email account security which often lacks MFA, email passwords commonly same as application passwords, no protection if email compromised first, email may be on same device for authentication, susceptible to phishing.
Biometric authentication types and trade-offs
Common biometric types include: fingerprint scans, facial recognition, iris scans, voice recognition. Pros: well-implemented biometrics hard to spoof requiring targeted attack, fast and convenient for users. Cons: manual enrollment required, custom sometimes expensive hardware often required to read biometrics, privacy concerns with storing sensitive physical information, if compromised biometric data difficult to change, hardware may be vulnerable to additional attack vectors.
Source IP address as location-based MFA factor
Source IP address can be used as MFA factor typically with allow-list approach based on static list such as corporate office ranges or dynamic list such as previous IP addresses user authenticated from. Pros: very easy for users, minimal configuration and management. Cons: no protection if user's system compromised, no protection against rogue insiders, trusted IP addresses must be carefully restricted such as open guest Wi-Fi using main corporate IP range.
Geolocation as MFA factor
Geographic location that IP address is registered to can be used rather than exact IP address. Less precise but more feasible in environments with non-static IP addresses. Common usage is requiring additional authentication factors when attempt made from outside user's normal country. Pros: very easy for users. Cons: no protection if system compromised, no protection against rogue insiders, easy to bypass by obtaining IP addresses in trusted country, privacy features like Apple iCloud Private Relay and VPNs reduce accuracy.
Geofencing as precise location-based MFA factor
Geofencing allows user to define specific area where allowed to authenticate, more precise than geolocation. Often used in mobile applications where location determined with high accuracy using geopositioning like GPS. Pros: very easy for users, provides high level of protection against remote attackers. Cons: no protection if system compromised, no protection against rogue insiders, no protection against attackers physically close to trusted location.
Behavioral profiling as MFA factor
Behavioral profiling based on user interaction with application such as time of day login, devices used, and navigation way. Rapidly becoming more common when combined with risk-based authentication and User and Entity Behavior Analytics (UEBA) systems. Pros: no user interaction required, can continuously authenticate user, combines well with other factors to increase assurance. Cons: early implementations often inaccurate with significant false positives, requires large data amounts and processing power, may be difficult in environments where user behavior likely to change frequently.
Keystroke and mouse dynamics for MFA
Keystroke and mouse dynamics based on way user types and moves mouse, for example time between key presses, time between press and release, and speed and acceleration of mouse. Largely theoretical and not widely used in practice. Pros: no additional hardware required, no additional user interaction, can continuously authenticate, can detect when not user using system, can detect duress or unfit state. Cons: unlikely accurate enough as standalone factor, may be spoofed by AI or advanced attacks.
Adaptive or risk-based authentication principles
Adaptive (or risk-based) authentication adjusts authentication requirements dynamically based on login attempt context. Common signals to determine risk include: geolocation and IP reputation, device fingerprinting, time of access such as 3 AM login, behavioral biometrics like typing speed or mouse movements, known compromised credentials. If risk detected, system may: prompt for additional factor like OTP, enforce re-authentication, deny access and trigger alerting or account protection flows.
Risk-based authentication balance and fallback requirements
Risk-based authentication helps improve user experience while strengthening security by applying additional verification only when risk elevated. This method is widely used in modern authentication systems to balance usability and security. Developers must ensure risk signals cannot be spoofed and fallback mechanisms are not weaker than primary MFA methods. For high-risk events such as account recovery or suspicious activity, reauthentication should be enforced as detailed in Authentication Cheat Sheet.
Risk-based authentication use case example
User logs in from trusted device in usual location — no additional prompt needed. But if user logs in from new country using Tor exit node, system requires SMS verification or triggers account lock until further verification.
OWASP-recommended MFA methods ranked by security from most to least secure
Based on OWASP Multifactor Authentication Cheat Sheet analysis, MFA methods ranked by security effectiveness from most to least secure: Passkeys/FIDO2 with WebAuthn (phishing-resistant, cryptographic), Hardware tokens like U2F/YubiKey (resistant to remote compromise, phishing-resistant), Smart cards with PKI (requires PIN protection), Software OTP/TOTP (time-based, smaller target), Push notifications (out-of-band), Email verification (dependent on email security), SMS/phone calls (restricted due to SS7/SIM-swap attacks), Source IP/Geolocation (bypassable), Behavioral profiling (supplementary), Security questions (deprecated - NIST no longer accepts as factor).
npm 2FA modes: auth-only vs auth-and-writes
npm supports two 2FA modes: 'auth-only' protects login and profile changes only; 'auth-and-writes' protects those actions plus write operations including token management and package publishing. Enable 2FA with 'npm profile enable-2fa auth-only' or 'npm profile enable-2fa auth-and-writes' in npm CLI version 5.5.1+. Save the emergency authentication codes provided during setup for account recovery.
Mobile sensitive operation re-authentication
Require users to re-authenticate for sensitive operations like changing passwords or updating payment information. Consider requiring re-authentication before displaying highly sensitive information as well.
Mobile password complexity requirement
Require password complexity in mobile applications.
Mobile PIN minimum length requirement
Do not allow short PINs such as 4 digits in mobile applications; require longer PIN lengths.
Mobile biometric authentication platform support
Use platform-supported methods for biometric authentication on mobile devices. Always provide a fallback, such as a PIN.
iOS sensitive shortcuts require device unlock
iOS/iPadOS Shortcuts can be executed while the device is locked through multiple methods: Today View widgets, Action Button (iPhone 15 Pro and 16 Pro), Control Center (iOS 18+), Siri voice commands, Home Screen shortcuts (iOS 18+), and scheduled execution. Sensitive app functionalities triggered via Shortcuts must always require device unlock before execution. Store secure tokens in Keychain that the app validates before executing sensitive shortcuts. Implement checks with `UIApplication.shared.isProtectedDataAvailable` to restrict execution of sensitive actions when the device is locked.
Mobile backend authorization enforcement
Require authorization checks on any backend functionality accessed from mobile applications.
Mobile OAuth2 and JWT for secure authentication
Use OAuth2, JWT, or similar mechanisms for secure authentication between mobile apps and backend services.
Mobile client-side authentication must be verified server-side
Perform authentication and authorization server-side and only load data on the device after successful authentication. Assume all client-side controls can be bypassed and perform them server-side as well.
Mobile spoofable device identifier authentication prohibition
Avoid using spoofable values like device identifiers for authentication in mobile applications.
iOS Siri intent authentication configuration
Configure `requiresUserAuthentication` to `true` on intents that expose sensitive information or functionality. Additionally, set `INIntent.userConfirmationRequired = true` for operations requiring explicit user confirmation. These settings ensure proper authentication (e.g., Face ID or PIN) and explicit approval before Siri can execute sensitive commands.
Secure coding basics: Authentication and Authorization
Implement strong authentication and authorization mechanisms to ensure that only authorized users can access sensitive data and resources.
V2.4 Credential Storage references Password Storage Cheat Sheet
For credential storage covered under V2.4 Credential Storage Requirements, OWASP references the Password Storage Cheat Sheet.
Authentication cheat sheet reference
The OWASP ASVS index references the Authentication Cheat Sheet under V6 Authentication sections including V6.2 Password Security, V6.3 General Authentication Security, V6.5 General Multi-factor authentication requirements, V6.7 Cryptographic authentication mechanism, and V6.8 Authentication with an Identity Provider.
C6 Implement Digital Identity controls
C6 Implement Digital Identity includes: Authentication Cheat Sheet, Choosing and Using Security Questions Cheat Sheet, DotNet Security Cheat Sheet (Forms authentication and A2 Weak Account management), Forgot Password Cheat Sheet, JAAS Cheat Sheet, JSON Web Token Cheat Sheet, Password Storage Cheat Sheet, REST Security Cheat Sheet (JWT), Ruby on Rails Cheat Sheet (Sessions and Authentication), SAML Security Cheat Sheet, Session Management Cheat Sheet, and Multi-Factor Authentication Cheat Sheet.
Critical authentication topics covered elsewhere in OWASP
Operational and security concerns such as token theft, replay protection, session lifecycle, and reauthentication are extensively covered in the OWASP Authentication Cheat Sheet and Session Management Cheat Sheet.
Two phases of authentication verification
Most systems handle authentication in two phases: Primary Authentication, which directly verifies credentials tied to authentication factors such as passwords, biometric inputs, signed challenges like WebAuthn assertions, or for internal actors, machine-issued certificates, SPIFFE IDs, or workload authentication data. Authentication Proof Verification, which after successful primary authentication verifies a reusable artifact (such as a session cookie, token, assertion, or cryptographic session state) that confirms the authenticated identity in subsequent interactions.
OWASP Cheat Sheets: Authentication and Access Control
Two OWASP Cheat Sheets are available:
1. Authentication Cheat Sheet - covers authentication controls and mechanisms
2. Access Control Cheat Sheet - covers authorization and access control mechanisms
Both are part of the OWASP series.
Client credentials request via POST parameters
A client credentials request can be sent as POST parameters in the format: grant_type=client_credentials&client_id=<client_id>&client_secret=<client_secret> to the authorization server endpoint /oauth/accesstoken with Content-Type: application/x-www-form-urlencoded.
Client credentials request via Basic authentication with POST parameters
A client credentials request can be sent using POST parameters in conjunction with HTTP Basic authentication. The Authorization header contains Basic <base64(<client_id>:<client_secret>)>, and the body contains grant_type=client_credentials&client_id=<client_id>&client_secret=<client_secret> with Content-Type: application/x-www-form-urlencoded.
Protect against Referer header leaks of authorization code
OWASP recommends implementing measures to avoid leaking the authorization code through the Referer Header during OAuth 2.0 flows.
Authorization Server Mix-Up Protection validates proper server targeting
OAuth 2.0 implementations should validate and target the proper authorization server to prevent authorization server mix-up attacks.
PKCE considerations for OAuth 2.0 security
PKCE (Proof Key for Public Clients) should be considered as part of OAuth 2.0 security protective measures, particularly for public clients that cannot securely store credentials.
Client credentials protection implements client_id and client_secret
OWASP recommends implementing client_id and client_secret as part of OAuth 2.0 client credentials protection.
OAuth 2.0 roles: Resource Owner, Resource Server, Client, Authorization Server
OAuth 2.0 defines four primary roles. The Resource Owner is the person or entity that can grant access to a resource, typically an end-user. The Resource Server hosts the protected resource and decides whether access with an OAuth 2.0 Access Token is accepted. The Client is the application that accesses a protected resource on behalf of and with authorization from the Resource Owner. The Authorization Server authenticates the Resource Owner and issues Access Tokens to the Client after authorization consent from the Resource Owner, such as a central Single Sign On (SSO) solution or Identity Provider (IdP).
Access tokens are opaque credentials for protected resources
Access tokens are credentials that the Client uses to obtain access to protected resources on behalf of the Resource Owner. Access tokens are issued by the Authorization Server after authorization consent from the Resource Owner and must be verified by the Resource Server. Access tokens are opaque, meaning the Client does not have to parse or understand token structure to use it at the Resource Server.
Refresh tokens are credentials to obtain new access tokens
Refresh tokens are credentials that the Client uses to obtain new access tokens. Refresh tokens are optionally issued by the Authorization Server in addition to the access token after authorization consent from the Resource Owner. The Client uses the refresh token to obtain a new access token after the old one has expired or been invalidated. Refresh tokens are opaque and are only presented to the Authorization Server, never to the Resource Server.
Client credentials response must include access token, token type, and expiry
The Authorization Server must return an HTTP 200 OK response with Content-Type: application/json;charset=UTF-8 and Cache-Control: no-store and Pragma: no-cache headers. The response body must include access_token, token_type set to bearer, and expires_in indicating the token lifetime in seconds. A refresh token should not be returned in the client credentials flow. The response should also return the scope to validate the scope sent from the client side.
Client credentials grant for backend service-to-service communication
Backend services use the client credentials grant, also known as Machine to Machine (M2M) flow, for communication between services. This grant allows one service to be both the Client and the Resource Owner. Authorization is conducted by sending the Client ID and Secret to the Authorization Server to obtain an access token. Only trusted back-end services can access the Resource Server by tracking client IDs and secrets.
MFA prevents 99.9% of account compromises
Multi-factor authentication (MFA) is the best defense against password-related attacks including brute-force, credential stuffing, and password spraying. Analysis by Microsoft suggests that MFA would have stopped 99.9% of account compromises. MFA should be implemented wherever possible, and modern browsers and mobile devices now support FIDO2 Passkeys and other forms of MFA for most use cases.