Comprehensive coverage of methods, protocols, design principles, and practical mechanisms for proving identity and enforcing permissions across systems. Authentication topics include credential based methods such as passwords and secure password storage, Multi Factor Authentication, one time passwords, certificate based and passwordless authentication, biometric options, federated identity and single sign on using Open Authorization, OpenID Connect and Security Assertion Markup Language, and service identity approaches such as Kerberos and mutual Transport Layer Security. Covers token based and session based patterns including JSON Web Token and session cookies, secure cookie practices, token lifecycle and refresh strategies, token revocation approaches, refresh token design, and secure storage and transport of credentials and tokens. Authorization and access control topics include role based access control, attribute based access control, discretionary and mandatory access control, access control lists and policy based access control, Open Authorization scopes and permission modeling, privilege management and the principle of least privilege, and defenses against privilege escalation and broken access control. The description also addresses cryptographic foundations that underlie identity systems including symmetric and asymmetric cryptography, public key infrastructure and certificate lifecycle management, secure key management and rotation, and encryption in transit and at rest. Common threats and mitigations are covered, such as credential stuffing, brute force attacks, replay attacks, session fixation, cross site request forgery, broken authentication logic, rate limiting, account lockout strategies, secrets management, secure transport, and careful authorization checks. Candidates should be able to design authentication and authorization flows for both user and service identities, evaluate protocol and implementation trade offs, specify secure lifecycle and storage strategies for credentials and tokens, and propose mitigations for common failures and attacks.
MediumTechnical
48 practiced
Design rate-limiting and account lockout thresholds given a login endpoint receiving up to 10k attempts/sec, with periodic credential-stuffing spikes. Describe a combined per-IP, per-account, and global strategy, including exponential backoff, CAPTCHA triggers, temporary lockouts, and adaptive thresholds based on risk signals. Explain how you'd tune to avoid account denial-of-service while stopping automated attacks.
Sample Answer
**Situation & goals**Design a layered rate-limit and lockout system that stops credential-stuffing at up to 10k req/s (with spikes) while avoiding legitimate user denial-of-service.**High-level strategy**- Defense-in-depth: combine global ingress controls, per-IP/IP-range throttles, and per-account protections, plus adaptive risk signals, exponential backoff, CAPTCHAs and temporary lockouts.**Components**- Global protective layer - Token-bucket global gate: allow baseline throughput and absorb bursts; when sustained > threshold (e.g., 5k rps) apply progressive throttling and route suspicious traffic to scrubbing layer. - WAF integration to block known bad indicators (TOR, bad ASNs).- Per-IP / per-subnet - Soft limit: 10 attempts/min per IP; hard limit: 100 attempts/hour. - Apply exponential backoff on repeated failures per IP: delay = base * 2^n (capped). - Rate-limit whole /24 if many fail events originate there.- Per-account - Low-sensitivity failures: allow up to 5 failed attempts in 15 minutes with incremental delays. - After 5–10 failures, require CAPTCHA or 2FA step-up. - Temporary lockout: progressive windows (15m, 1h, 24h) only after evidence of automated pattern (velocity from many IPs, known bad signals). - Never auto-lock for high-value accounts without step-up verification—prefer step-up over permanent lock.- Captcha & step-up - Trigger when risk score exceeds threshold: rapid failures, multiple IPs targeting same account, unknown geolocation, user-agent anomalies. - Use invisible CAPTCHA first; escalate to interactive if bot persists.- Adaptive thresholds & signals - Risk engine ingest: IP reputation, device fingerprint, geolocation, success-rate per IP, velocity, credential stuffing threat intel. - Dynamically lower thresholds when risk high (e.g., many accounts targeted) and relax during maintenance or known traffic patterns.- Observability & tuning - Metrics: failed/successful attempts per IP/account, CAPTCHA pass rates, false lockouts, customer support tickets. - Use rolling windows and A/B test thresholds; start conservative and tighten on detected attacks. - Implement temporary safety valves: allow manual override, notify users of lockouts via email with verification link.- Preventing account DoS - Prefer friction (CAPTCHA, 2FA) over irreversible lockouts. - Correlate failure signals across IPs before hard lock. - Graceful degradation: present step-up challenges before lock, and escalate only if distributed attack pattern confirmed.**Why this works**Layered controls stop volume attacks early (global/IP), protect accounts intelligently (per-account + step-up), and adapt to threat context to minimize false positives and account DoS while blocking automated credential stuffing.
HardTechnical
78 practiced
Provide a comprehensive threat model for deploying WebAuthn/FIDO2-based passwordless authentication supporting both roaming authenticators (security keys) and platform authenticators (TPM, Secure Enclave). Address phishing resistance, lost/stolen devices, account recovery, credential migration between devices, attestation privacy, and server-side verification of attestation objects.
Sample Answer
**Summary / Scope**Threat model for WebAuthn/FIDO2 passwordless supporting roaming authenticators (security keys) and platform authenticators (TPM, Secure Enclave). Focus on phishing resistance, lost/stolen, account recovery, credential migration, attestation privacy, and server-side attestation verification.**Assets**- User credentials (private keys in authenticators)- Relying Party (RP) server keys and user account state- Attestation keys / metadata- Recovery tokens/backups**Threats & Risks**- Phishing/credential exfiltration: mitigated by origin-bound signatures and user-presence/user-verification; cloned authenticators via stolen attestation keys.- Lost/stolen device: local access enabling authenticator use if user verification absent; device-compromise leading to key extraction (more risk for software authenticators).- Account recovery abuse: attackers leveraging weak recovery flows to enroll new authenticators.- Credential migration interception: copying backups exposes private keys; insecure transport/storage.- Attestation privacy leakage: cross-RP tracking via unique attestation keys or certificate metadata.- Malicious RP/server: improper attestation verification accepting rogue attestation.- Supply-chain/backdoor authenticators: vendor-level compromised attestation/firmware.**Mitigations**- Phishing: enforce origin check, require user-verification (biometric/PIN) for high-risk operations, use U2F/WebAuthn with clientDataJSON origin binding.- Lost/stolen: encourage strong UV; provide device management UI for users to deregister credentials; implement short-lived sessions and step-up auth for sensitive actions.- Recovery: avoid single-secret recovery. Offer multi-factor recovery (email + OOB OTP + device-based recovery token), cryptographic recovery using SRP-protected encrypted key blobs stored server-side only if user confirms via secondary factor; rate-limit recovery attempts and require proof-of-possession of recovery device/backup.- Migration: use Authenticator Export with user consent only; prefer per-device generated credentials and transfer via secure local channel (Bluetooth/QR with mutual auth) or cloud seeding via end-to-end encrypted backup (keys encrypted with user-derived key from strong passphrase + possibly platform TPM sealing).- Attestation privacy: prefer "attestation-conveyance: indirect" or "none" for most users; implement anonymization/Audit of attestation metadata; map attestation certificates to metadata service identifiers (FIDO Metadata Service) instead of exposing raw certs to RPs; respect user choice for privacy.- Server-side attestation verification: verify attStmt per FIDO2 spec, validate attestation cert chain against trusted root store (FIDO MDS), check aaguid and metadata for known vulnerabilities, check signature over authenticatorData + clientDataHash, ensure rpIdHash and user presence/verification flags, validate public key formats and key algorithm. Reject self-attestation unless policy allows; apply risk-based policy: allow self-attestation for platform authenticators with additional checks.- Logging & monitoring: alert on abnormal registration patterns, multiple keys for same user from diverse aaguid locations, or mass recovery attempts.- Supply-chain: maintain approved authenticator list via FIDO MDS, require vendor security attestation, perform periodic device vetting.**Trade-offs**- Strict UV and attestation checks increase security but reduce UX and device compatibility.- Server-side storage of encrypted backups increases recovery usability but raises attack surface.**Practical checklist (implementation)**- Enforce origin checks, require UV for high-risk ops.- Use FIDO MDS and validate attestation chains.- Implement robust recovery with rate-limits and MFA.- Provide user-managed device revocation UI and admin controls.- Log, alert, and periodically review attestation metadata and vendor trust.
MediumTechnical
44 practiced
You're designing an enterprise access control model for an application with complex approval workflows, many dynamic resource attributes, and frequent org changes. Compare RBAC and ABAC and decide which approach (or hybrid) you'd choose. Describe how you'd implement role or attribute administration, policy evaluation, testing, and auditing, and name trade-offs in scalability and expressiveness.
Sample Answer
**Recommendation — hybrid (RBAC + ABAC)**I’d use a hybrid model: RBAC for stable, coarse-grain duties (payroll admin, approver tiers) and ABAC for dynamic decisions driven by resource attributes, workflow state, and org changes (asset sensitivity, approval escalation, geo, shift). Hybrid balances manageability and expressiveness.**Architecture & components**- Policy administration point (PAP) for authoring RBAC role-permissions and ABAC policies (XACML/OPA/Rego).- Policy decision point (PDP) centralized (or distributed via sidecars) to evaluate policies.- Policy enforcement point (PEP) in the app/API gateway.- Policy information point (PIP) pulling attributes from HR/CMDB, workflow engine, and request context.**Role/Attribute administration**- Roles managed via IAM with lifecycle automation: provisioning/deprovisioning from HR/IdP.- Attributes sourced from canonical authorities (SCIM sync from HR, CMDB, ticketing). Use attribute versioning and TTLs to handle frequent org changes.- Change workflows: requests for role changes or attribute overrides require approval and are logged.**Policy evaluation & testing**- Use PDP with caching for high-QPS; include risk scoring and deny-by-default fail-safe.- Test policies via unit tests (Rego/xUnit), policy simulators, and integration tests in CI with synthetic attributes and replay of real request traces.- Canary deployments of policy changes with gradual rollout and monitoring.**Auditing & Monitoring**- Immutable audit events for every decision (request, attributes used, decision, policy version) shipped to SIEM and long-term WORM storage.- Alerts for anomalies (sudden privilege grants, abnormal allow rates) and periodic attestation reports for privileged roles.**Trade-offs**- Scalability: RBAC scales well for large user bases; ABAC evaluation is heavier (attribute fetch, PDP load) — mitigate with caching, PDP horizontal scaling, and attribute pre-aggregation.- Expressiveness: ABAC is more expressive for dynamic workflows but harder to reason about; RBAC is simpler to certify and audit.- Operational complexity: Hybrid adds integration complexity but gives best operational control and security posture.This approach prioritizes secure, auditable decisions while remaining adaptable to frequent org and resource changes.
EasyTechnical
79 practiced
Compare common Multi-Factor Authentication (MFA) approaches — TOTP (time-based OTP), SMS OTP, push-based approval, and hardware-backed/U2F/WebAuthn tokens — in terms of security, usability, deployability, and attack surface. For each method, list typical threats (e.g., SIM swapping, phishing, device theft) and describe when you would choose or avoid that method for a user-facing application.
Sample Answer
**Brief framing (role: Cybersecurity Engineer)** Compare four MFA methods across security, usability, deployability, and attack surface, list typical threats, and when to choose/avoid.**TOTP (Time-based OTP)** - Security: Good if device protected; secrets stored on device or server. - Usability: Requires app (Authenticator), occasional friction (clock drift, backup). - Deployability: Low cost, standards-based (RFC 6238). - Attack surface / threats: Phishing, device theft, malware/keyloggers, secret extraction from backups. - When to choose/avoid: Choose for broad user bases needing stronger than passwords but low cost. Avoid for very high-risk users or when devices are unmanaged.**SMS OTP** - Security: Weak — channel is not end-to-end encrypted. - Usability: Very high (ubiquitous), low barrier. - Deployability: Very easy (telco integration). - Attack surface / threats: SIM swapping, SS7 interception, SMS malware, phishing. - When to choose/avoid: Use only for low-risk or transitional flows; avoid for sensitive applications (finance, admin access).**Push-based approval (mobile push)** - Security: High if using device binding, attestation, and cryptographic challenge-response. Better phishing resistance than OTPs. - Usability: Excellent (one-tap). - Deployability: Moderate — requires mobile app, push infra, device attestation. - Attack surface / threats: Device compromise, notification fatigue/social engineering, account linking attacks. - When to choose/avoid: Good for consumer apps with mobile users; avoid when users are unmanaged or can't install apps.**Hardware-backed / U2F / WebAuthn tokens** - Security: Best — phishing-resistant, private-key never leaves device, strong attestation. - Usability: High once registered; UX varies for non-technical users. - Deployability: Higher cost & logistics (provisioning, lost tokens). WebAuthn simplifies browser support. - Attack surface / threats: Physical theft, supply-chain tampering, lost tokens (availability). - When to choose/avoid: Choose for high-value accounts, enterprise admin access, and regulatory needs. Avoid only if cost/usability constraints prohibit.Recommendation: Use a risk-based policy — prefer WebAuthn/U2F for high-risk, push for mainstream mobile users, TOTP for fallback, and deprecate SMS where possible.
EasyTechnical
50 practiced
Explain the difference between session fixation and Cross-Site Request Forgery (CSRF). For each attack describe how it works and provide concrete mitigations at the web-stack level (server-side session handling, cookie attributes, CSRF tokens, SameSite, session rotation on privilege changes).
Sample Answer
**Difference (brief):**Session fixation forces a victim to use an attacker-chosen session identifier so the attacker can later use it to impersonate them. CSRF forces a logged-in user’s browser to submit unintended requests to a site where they are authenticated, leveraging the browser’s auto-sent cookies.**How each works**- Session fixation - Attacker obtains a valid session id (via link, header, or set-cookie) and lures user to authenticate using that id. - After user logs in under the fixed id, attacker reuses the same id to access the authenticated session.- CSRF - Attacker hosts a page that issues a side-effecting request (POST/GET) to the target site (e.g., via auto-submitted form, image, or fetch in some contexts). - Browser automatically includes cookies; if the user is authenticated, the action executes with their privileges.**Concrete mitigations (web-stack level)**- Server-side session handling - Rotate session id on authentication and on any privilege change (login, role elevation). This breaks fixation. - Bind sessions to additional attributes (IP range, user-agent fingerprint) with caution for usability. - Invalidate sessions on logout and provide short idle/absolute timeouts.- Cookie attributes - Set Secure and HttpOnly. - Set SameSite=Lax (or Strict for sensitive flows); Lax prevents most CSRF for unsafe methods by blocking cross-site cookie sends on top-level cross-site navigations.- CSRF tokens - Use per-session or per-request cryptographically random CSRF tokens embedded in state-changing forms / XHR headers and validated server-side. - For SPAs, use double-submit cookie + compare token header with cookie value or require X-Requested-With / custom header checked against origin.- Origin/Referer checks - Enforce strict Origin (or Referer) validation for state-changing requests; reject requests missing or mismatched origin.- Session rotation on privilege changes - Always issue a new session id and copy minimal needed state after authentication or privilege escalation; revoke the old id immediately.Combining server-side rotation + SameSite + CSRF tokens + strict origin checks yields strong defense-in-depth against both attacks.
Unlock Full Question Bank
Get access to hundreds of Authentication and Access Control interview questions and detailed answers.
