Cryptography and identity security interview questions

Questions and answers

5 questions with model answers

Rewrite each answer in your own words before the loop — interviewers can tell a memorized paragraph from one you can defend under a follow-up.

1. Question 1

   Hashing, encryption, and encoding — what is the difference, and what do you use for passwords?

   Encoding, like base64, is a reversible representation change with no security property at all. Encryption is reversible with a key and gives confidentiality; authenticated modes such as AES-GCM also give integrity and authenticity. Hashing is one-way and gives a fixed-length fingerprint used for integrity and verification, not secrecy. For passwords you specifically need a slow, salted password hash — Argon2id, scrypt, or bcrypt with a sensible work factor — because general-purpose hashes like SHA-256 are designed to be fast, which is precisely what an offline cracking rig wants. The salt is per-user and defeats precomputed tables, while the work factor is what you tune upward as hardware improves.

2. Question 2

   What does a valid TLS certificate actually prove?

   It proves that a certificate authority the client trusts asserted a binding between the presented public key and the domain name, and that the server holds the corresponding private key. It does not say anything about the site being trustworthy, honest, or free of malware — which is why "the padlock means it is safe" is wrong and phishing sites almost universally use valid certificates. In the handshake, that certificate authenticates the server while an ephemeral key exchange establishes forward secrecy, so recording traffic today and stealing the server key later does not decrypt it. Related things worth mentioning are certificate pinning for high-value mobile clients, certificate transparency logs for spotting unauthorized issuance for your domains, and monitoring expiry, since expired certificates cause more outages than attacks.

3. Question 3

   What is the difference between OAuth 2.0 and OpenID Connect?

   OAuth 2.0 is an authorization framework: it lets an application obtain an access token to call an API on a user's behalf, and the access token says nothing reliable about who the user is. OpenID Connect is an authentication layer on top of it that adds the ID token, a signed JWT containing claims about the user and the authentication event, intended for the client to consume. The common failure is using an OAuth access token as proof of identity, or accepting an ID token without validating its signature, issuer, audience, and expiry. For a confidential detail that shows depth, mention that the authorization code flow with PKCE is now the recommended flow for public clients, and that the implicit flow is deprecated because tokens in the URL fragment leak too easily.

4. Question 4

   MFA is enabled everywhere. Why are accounts still being compromised?

   Because most MFA factors prove possession of something phishable. Adversary-in-the-middle phishing kits proxy the real login page, capture the one-time code, and steal the resulting session cookie, after which the attacker never needs the factor again. Push fatigue works by spamming approvals until a tired user accepts one, SIM swaps defeat SMS, and help desk social engineering resets the factor outright. Token theft from an already-compromised endpoint bypasses the login flow entirely. The mitigations are phishing-resistant factors bound to the origin — FIDO2 or passkeys and certificate-based authentication — plus number matching where push is unavoidable, conditional access on device and location, shorter session lifetimes, and detection for impossible-travel and new-device token use.

5. Question 5

   What goes wrong with JWT-based sessions?

   The recurring problems are validation shortcuts and revocation. Accepting the token's own algorithm header without pinning the expected algorithm, skipping issuer and audience checks, or trusting an unsigned token are classic implementation bugs. The structural issue is that a self-contained token is valid until it expires, so logout and "disable this user now" do not really work without a server-side revocation list or short expiry plus refresh tokens. Storage matters too: a token in localStorage is readable by any XSS payload, whereas an HttpOnly cookie is not — at the cost of needing CSRF defenses. And because a JWT payload is only base64url encoded, not encrypted, nothing sensitive belongs inside it.