Secure Token-Based Authentication: Vulnerabilities & Best Practices Quiz

Explore essential concepts in token-based authentication, focusing on common vulnerabilities such as JWT security, safe token storage, and protection against token theft. Enhance your understanding of how to implement robust security practices and minimize risks in authentication systems.

1. JWT Transport Security

   Why is it critical to always transmit JSON Web Tokens (JWTs) over HTTPS rather than HTTP?

   1. HTTPS encrypts traffic, protecting tokens from being intercepted
   2. HTTP is faster and safer for token transport
   3. HTTPS allows larger token payloads
   4. JWTs can only be transmitted over HTTPS by definition

   Explanation: Transmitting JWTs over HTTPS ensures that tokens are encrypted during transit, preventing attackers from capturing them via network sniffing. Using HTTP can expose sensitive tokens to interception. Payload size is not dependent on the protocol used. While using HTTPS is best practice, JWTs themselves are protocol-agnostic and not limited only to HTTPS.

2. Token Storage Practices

   What is the safest way to store tokens on a client-side web application to prevent cross-site scripting (XSS) attacks?

   1. Store tokens in HTTP-only cookies
   2. Save tokens in localStorage
   3. Keep tokens in a global JavaScript variable
   4. Store tokens in sessionStorage

   Explanation: Storing tokens in HTTP-only cookies prevents JavaScript access, which helps protect against XSS attacks. LocalStorage and sessionStorage are both accessible to JavaScript, making them less secure against XSS. Keeping tokens in global variables is also insecure because it exposes them to XSS vulnerabilities.

3. Validating Token Signatures

   When a server receives a JWT, what should it do first to confirm the token has not been tampered with?

   1. Verify the JWT's signature
   2. Check the token's expiration claim
   3. Decode the payload and trust its contents
   4. Look up the token in a database

   Explanation: Verifying the JWT's signature ensures the token's integrity and confirms it has not been altered. Checking the expiration is necessary, but only after confirming authenticity. Trusting the payload without verification is unsafe. JWTs may not always be stored in a database, so a lookup isn't always feasible or effective first.

4. Token Expiry Best Practices

   How does setting short expiration times for tokens help reduce security risks?

   1. It limits the time window an attacker can use a stolen token
   2. It makes authentication faster for users
   3. It increases token size, making them harder to steal
   4. It prevents brute-force attacks against token endpoints

   Explanation: Short token lifetimes minimize the opportunity for a stolen or compromised token to be misused. Short expiration does not necessarily speed up authentication or impact token size. While it reduces the impact of brute-force, its main benefit is limiting how long a stolen token is valid.

5. Preventing Token Replay

   Which mechanism can be used to protect against replay attacks with tokens?

   1. Use unique nonces in each authentication request
   2. Only validate tokens during business hours
   3. Allow unlimited token reuse
   4. Increase the token's length

   Explanation: Unique nonces ensure that each authentication request is distinct, making replay attacks much harder. Validating only during business hours does not address the core vulnerability. Unlimited token reuse and simply lengthening tokens do not provide meaningful protection against replay attacks.

6. Securing Refresh Tokens

   Why should refresh tokens be given extra protection compared to access tokens?

   1. A stolen refresh token can be used to obtain new access tokens for an extended period
   2. Refresh tokens have built-in signature validation
   3. They are shorter, making them easier to guess
   4. Clients never store refresh tokens

   Explanation: Because refresh tokens are long-lived and can be exchanged for new access tokens, their compromise poses a significant threat. Signature validation applies to tokens but is not unique to refresh tokens. Refresh tokens are not shorter or easier to guess by nature. Clients often do store refresh tokens securely.

7. Token Audience Claim Importance

   What is the main purpose of the 'aud' (audience) claim in a JWT?

   1. To specify which service or client the token is intended for
   2. To record the token's issuer
   3. To track the number of token uses
   4. To store the user password

   Explanation: 'aud' defines the intended recipient or service for the token, helping ensure that the token is only accepted by the correct party. The token's issuer is recorded separately, often in the 'iss' claim. Counting uses or storing passwords is not a function of the 'aud' claim.

8. Mitigating Cross-Site Request Forgery (CSRF)

   Which token storage strategy helps reduce the risk of CSRF in browser-based applications?

   1. Store tokens in localStorage and not send them with every request automatically
   2. Store tokens in regular cookies without the SameSite attribute
   3. Store tokens in cookies with the 'SameSite=Strict' attribute
   4. Store tokens in hidden HTML form fields

   Explanation: Cookies with 'SameSite=Strict' attributes are not sent to other sites, helping protect against CSRF. LocalStorage does not prevent CSRF as it is not tied to request submission. Regular cookies without SameSite are vulnerable to CSRF. Hidden form fields are not a reliable or secure strategy for tokens.

9. Handling Token Revocation

   What is a common method for servers to handle JWT revocation before the token’s expiration?

   1. Maintain a server-side denylist or blacklist of invalidated tokens
   2. Extend the token's expiration time
   3. Change the payload to mark the token as revoked
   4. Avoid using any token expiration

   Explanation: A denylist allows the server to maintain a list of tokens that should no longer be accepted even if not expired. Extending expiration doesn't revoke tokens. Changing the payload post-issuance does not affect already issued tokens. Omitting expiration increases risk and does not address revocation.

10. Minimizing Sensitive Data in Token Payloads

    Why is it a security risk to store sensitive information, like passwords or full credit card numbers, inside a token's payload?

    1. Tokens are often exposed in browser storage and transmission, making sensitive data vulnerable
    2. Payload data is always encrypted inside a JWT
    3. It makes tokens too large to transmit
    4. Browsers do not allow storage of any sensitive data

    Explanation: Token payloads can be easily decoded and may be exposed via browser storage or interceptable transmission, risking leaks of sensitive information. JWTs are usually only encoded, not encrypted by default. Token size is not a major concern for this kind of data risk. While storing sensitive data in browsers is discouraged, the main issue is exposure, not browser prohibition.