Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
System Security · Question Set
Auth & Access interview questions for placements and exams.
Questions
14
Included in this set
Subject
System Security
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for System Security.
OAuth 2.0 is for authorization to protected resources using access tokens. OpenID Connect layers authentication on top and issues an I D token describing the user. Many providers implement both together for login plus API access. This difference is a frequent interview test.
Response includes: access_token for API; id_token (JWT) for user identity
For complete preparation, combine this set with full subject-wise practice for System Security. You can also explore other subjects and sets from the links below.
Kerberos authenticates clients and services using tickets issued by a trusted Key Distribution Center. After initial authentication, clients use tickets to access multiple services without re-entering passwords. It is common in Windows domains and many Unix realms.
kinit user@REALM klist # shows TGT and service tickets
Strong session management means random identifiers, secure and httpOnly cookies, and enforced expiry. Idle timeouts log out inactive users. Absolute timeouts end long-lived sessions even if active. These steps limit theft, fixation, and replay.
Set-Cookie: sid=abc...; Secure; HttpOnly; SameSite=Strict; Max-Age=1800
A J W S (signed token) lets receivers verify that claims were not altered. A J W E (encrypted token) protects claim contents in transit. Many breaches stem from poor token handling rather than the format itself, so follow best practices for storage and lifetime.
Header: { alg: RS256, typ: JWT }
Payload: { sub: "123", scope: "read" }
Signature: RSASSA-PKCS1-v1_5 over header.payloadUpdated guidance favors usability and breach resistance: longer passphrases, no composition gymnastics, checks against compromised lists, and only reset on evidence of compromise. This reduces reuse and help-desk burden while improving security.
Example: minLength 12; allow spaces; check against breached list; lockout after risk-based threshold
Scopes express permissions, such as read-only or write access to a specific API. Least-privilege scopes reduce blast radius if a token is stolen, which is critical in distributed systems.
Authorization request: scope=contacts.read%20calendar.read
Single sign-on improves user experience and reduces password sprawl. It centralizes policy, monitoring, and revocation, which helps compliance and incident response. But S S O concentrates risk: if the identity provider or its strong factors fail, many apps are at risk. Mitigate with multi-factor, conditional access, hardware-backed keys for admins, scoped tokens, and strong logging. Tie S S O to least-privilege and short-lived sessions to keep exposure small.
IdP issues ID token + access token; apps validate signature and audience before granting access
PAM lets each service define a stack of modules for auth, account, password, and session management. You can add multi-factor, set login bans, or force password policies per service without modifying the daemon itself. It is a core building block for access control on Unix-like systems.
/etc/pam.d/sshd includes pam_unix.so, pam_faildelay.so, pam_google_authenticator.so (example)
Secure prevents sending the cookie over plain H T T P. HttpOnly stops most script access to the cookie. SameSite limits cross-site requests that could carry the cookie, which helps reduce cross-site request forgery and some leakage. These align with session management guidance.
Set-Cookie: sid=...; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=1800
Frequent mistakes include accepting tokens without verifying signature, using none or weak algorithms, failing to check audience and issuer, and giving tokens very long lifetimes. Others include storing tokens where scripts can read them, not rotating keys, and mixing authentication and authorization data without care. Fix these by enforcing strong algorithms, validating signature and claims on every call, keeping tokens short-lived with refresh where needed, storing tokens in secure httpOnly cookies, and rotating signing keys. Use reputable libraries and follow cheat-sheet guidance.
Verify: alg=RS256; check iss/aud/exp/nbf; reject none; rotate kid keys; token TTL minutes, not days
Federation standards let users authenticate with their own identity provider while the app trusts assertions. Choose OpenID Connect for modern web and mobile, or SAML for older enterprise stacks. Use OAuth 2.0 tokens to gate API calls after the user is authenticated.
Front-channel OIDC login → ID token; back-channel API uses access_token with least-privilege scopes
MFA combines two or more different factors, such as something you know, something you have, or something you are. If a password leaks, the attacker still needs the second factor to pass authentication, which sharply lowers account-takeover risk. Standards like N I S T eight hundred sixty-three B describe authenticator assurance levels and when to require multi-factor.
User enters password + TOTP from an authenticator app; server verifies both before issuing a session
Separate human admin access from service identities. Use just-in-time elevation with approval, session recording, and command-level auditing. Rotate secrets automatically, prefer short-lived credentials, and lock high-risk actions behind step-up multi-factor. For services, use managed identities with scoping and time-boxed tokens over long-lived keys. Monitor admin sessions closely and alert on unusual source locations or off-hours activity. Map controls to assurance levels similar to those in national guidelines for authentication strength to avoid oversights.
Example: Admin requests elevation → PAM broker issues time-boxed role → session proxied and recorded; auto-revoke on logout
Use adaptive lockouts that trigger on suspicious patterns instead of a fixed small number. Combine rate limiting, progressive delays, and device or network reputation. Require step-up multi-factor for resets, and log every reset with alerting on unusual patterns. Provide secure self-service recovery with verified channels. Keep user experience in mind so you do not create a denial of service for real users. Align thresholds to your authenticator assurance level and monitor outcomes to tune the policy.
Example: 5 failures → 15-minute cool-down; repeated across IPs triggers CAPTCHA and step-up MFA; audited reset flow