Password Security Interview Questions and Answers

Password Security Interview Questions and Answers

Interviewers ask these password security questions often. Here are concise answers.

Q1: Why should you hash passwords?

Because if the database is leaked, plain-text passwords expose every user. People reuse passwords, so one leak breaks other accounts too. Hashing turns passwords into irreversible strings.

Q2: Why bcrypt instead of SHA-256?

SHA-256 is a fast hash, not a password hash. Fast means brute-forcing a list of hashes is fast. bcrypt is slow on purpose and has a salt built in, making brute-force expensive.

Q3: What is a salt and why do you need it?

A random value added to the password before hashing. It ensures two users with the same password get different hashes. Prevents rainbow table attacks. bcrypt handles salting automatically.

Q4: What salt rounds should you use?

10 for most apps (~100ms per hash). 12 for high-security apps (~400ms). Each increment doubles the work. 14+ is too slow for most apps.

Q5: Where should you store a JWT?

In an httpOnly, secure, sameSite cookie for web apps. In secure storage (Keychain, Keystore) for mobile. Do not use LocalStorage (open to XSS).

Q6: How do you handle password resets?

Generate a random token, store its hash with a 15-min expiry, email a link with the raw token, verify the hash on reset, hash the new password, invalidate the token. Rate limit the request endpoint. Do not reveal if the email is registered.

Q7: How do you invalidate sessions on password change?

Bump a tokenVersion field on the user. The auth middleware checks that the JWT's tokenVersion matches the user's current one. After a change, old JWTs are rejected.

Q8: How do you prevent brute-force attacks?

Rate limit login (5 attempts per 15 min per IP and per email). Lock the account temporarily after too many failures. Use a slow hash (bcrypt, argon2) so each attempt is expensive.

Q9: How do you store API keys?

Hashed, like passwords. Send the raw key once on creation; the user stores it. Compare hashes on each request. If the database is leaked, attackers cannot use the hashes.

Q10: Why should you never log passwords?

Logs are often shipped to centralized systems with broader access than the database. A password in logs is a leak waiting to happen. Filter sensitive fields from logs or use a logger that redacts them.

The Takeaway

Password security interview answers: hash always (bcrypt or argon2); bcrypt not SHA-256 (slow, salted); salt prevents rainbow tables; 10 rounds default; JWT in httpOnly cookie; password reset with hashed token and 15-min expiry; tokenVersion for session invalidation; rate limit login; hash API keys; never log passwords.