Sample questions
As Authentication SessionDifficulty 1
Why is storing passwords as a plain SHA-256 hash considered insecure, even though SHA-256 is a strong cryptographic hash function?
- aSHA-256 produces a hash that is too short to be collision-resistant, making it feasible for an attacker to find two different passwords that hash to the identical digest
- bSHA-256 cannot be implemented in most programming languages without a paid license
- cSHA-256 is designed to be extremely fast, so attackers can try billions of guesses per second against a stolen hash dump✓
- dSHA-256 always produces the same output length regardless of input, which leaks the password length
Explanation:General-purpose hash functions like SHA-256 are built for speed, which is exactly the wrong property for password storage: an attacker with a leaked hash database can run massively parallel brute-force or dictionary attacks on cheap hardware. Password hashing functions (bcrypt, scrypt, argon2) are deliberately slow and tunable to make each guess expensive.
As Authentication SessionDifficulty 1
In the context of password hashing algorithms like bcrypt, what is the purpose of a per-user random salt?
- aIt speeds up the hashing computation by giving the algorithm a shorter input to process, cutting the time needed to verify a login on high-traffic authentication endpoints
- bIt compresses the password to a fixed length before hashing so the database column can be smaller
- cIt encrypts the hash so it can later be decrypted back to the original password for support requests
- dIt ensures that two users with the same password get different stored hashes, defeating precomputed rainbow-table attacks✓
Explanation:A salt is random data mixed into the input before hashing and stored alongside the hash. Because it differs per user, identical passwords produce different hashes, which makes precomputed lookup tables (rainbow tables) useless and forces an attacker to attack each hash individually.
As Authentication SessionDifficulty 2
What does the 'work factor' (or cost parameter) in bcrypt control?
- aHow many rounds of internal computation are performed, directly controlling how slow (and therefore expensive to brute-force) each hash operation is✓
- bHow many previous passwords are remembered to prevent password reuse, a history list the authentication service consults on every password-change request before accepting the new value
- cThe maximum allowed length of the input password before it is truncated
- dThe number of database replicas that must acknowledge the write before the hash is considered stored
Explanation:bcrypt's work factor is an exponential cost parameter: increasing it doubles the computation time per hash. This lets operators tune hashing cost upward as hardware gets faster, keeping brute-force attacks expensive over time.
As Authentication SessionDifficulty 1
A JWT (JSON Web Token) is typically composed of which three parts, separated by dots?
- aHeader, payload, and signature✓
- bPublic key, private key, and ciphertext
- cSession ID, CSRF token, and expiry timestamp
- dIssuer, subject, and encrypted payload
Explanation:A JWT is header.payload.signature, each part base64url-encoded. The header describes the algorithm and token type, the payload holds claims (like user ID and expiry), and the signature lets the receiver verify the token was not tampered with.
As Authentication SessionDifficulty 2
What is the security risk of the JWT alg: none attack?
- aIt doubles the size of the payload, making the token too large for most HTTP headers, which would cause the server to reject the request outright with a header-size-limit error before any signature check occurs
- bIt forces the server to fall back to plaintext HTTP instead of HTTPS for that request
- cIt causes the token to expire immediately, resulting in denial of service for legitimate users
- dA poorly implemented verifier that trusts the token's own
alg header may accept an unsigned token as valid, letting an attacker forge arbitrary claims✓
Explanation:The JWT header's alg field is attacker-controlled input. If a library naively honors whatever alg the token claims, an attacker can set alg: none, strip the signature, and the server may accept the forged token as authentic. The fix is to whitelist expected algorithms on the verifying side and never derive trust from the token itself.
As Authentication SessionDifficulty 1
What does the exp (expiration) claim in a JWT payload control?
- aThe maximum number of API endpoints the token is allowed to call
- bThe encryption algorithm used to protect the token in transit, which the client and server negotiate separately from the token's own contents
- cThe timestamp after which the token must be treated as expired and rejected by any verifier✓
- dThe number of times the token can be refreshed before a new login is required
Explanation:exp is a standard registered claim holding a Unix timestamp. Verifiers must check the current time against it and reject the token once that time has passed, which bounds how long a stolen token remains useful to an attacker.