Entry-Level Cryptographer Interview Preparation Guide - DoorDash

Direct answer

Threat modeling a small web service that stores user secrets (API keys and encrypted documents) follows a repeatable sequence: list what actually needs protecting, list who interacts with the system, map every place an outsider can reach it, mark where trust level changes as data moves through the system, walk each entry point for a realistic attack scenario, and propose a specific mitigation for each one. The step that most often gets rushed on a small service like this is trust boundaries, because it is tempting to treat "our backend" as one uniform trusted zone, when in practice the boundary between "authenticated as some user" and "authorized to see this specific user's secrets" is exactly where the highest-impact bugs tend to live.

Structured elaboration

1. Assets. What actually needs protecting, ranked by what a compromise would cost: user API keys (secrets that, if leaked, let an attacker impersonate the user to whatever third-party service the key belongs to), the encrypted documents and the keys used to encrypt them, user session tokens and credentials, and the service's own master key or key-management-service (KMS) key used to protect everything else.

2. Actors. Who legitimately or illegitimately interacts with the system: the authenticated end user (owns their own secrets, should never reach anyone else's), an external, unauthenticated attacker attempting to reach the service directly, and the service's own operators or administrators, who hold elevated access and are therefore both a legitimate actor and a potential insider-risk actor.

3. Entry points. Every place an outsider can touch the system: the login/authentication endpoint, the application programming interface (API) endpoints that create, retrieve, or delete a user's stored API keys, the document upload and download endpoints, and any administrative panel used for support or operations.

4. Trust boundaries. Where the level of trust actually changes, not merely where a network hop happens: the boundary between the public internet and the authentication layer (nothing is trusted yet); the boundary between "successfully authenticated" and "authorized for this specific resource," which is the boundary a small service most often gets wrong, since being logged in proves who you are but says nothing about which records you should be allowed to touch; and the boundary between the application backend and the KMS or database holding the actual secret material, which should require its own scoped credential rather than inheriting the application's general database access.

5. Attack scenarios, one plausible path per major risk:

• Credential stuffing against the login endpoint, using credentials leaked from an unrelated breach, to gain a legitimate session and then reach that user's own stored secrets legitimately (from the system's point of view).
• Broken authorization on the key-retrieval endpoint (an insecure direct object reference, where the endpoint checks that a request is authenticated but not that the requested key actually belongs to the requesting user), letting an authenticated attacker enumerate and read other users' API keys just by changing an identifier in the request.
• Secrets leaking into logs or error messages, where a stack trace or debug log inadvertently includes a plaintext API key or document content during a failure, creating a copy of the secret outside the system's actual protection boundary.
• Admin panel compromise, where an attacker who gains access to an operator account (phishing, credential reuse) inherits whatever broad access that panel grants, potentially including the ability to read secrets directly rather than only manage accounts.

6. Mitigations, mapped to the scenarios above:

• Rate limiting and multi-factor authentication (MFA) on the login endpoint blunts credential stuffing even when the attacker holds valid, leaked credentials.
• Explicit per-resource authorization checks on every key and document endpoint (confirming the authenticated user actually owns the specific record requested, not only that they are logged in) closes the broken-authorization path; this needs to be enforced consistently for every operation, not only the ones that seemed obviously sensitive during initial development.
• Structured logging with automatic secret redaction, and treating any logging or error-handling code path that touches a secret value as security-sensitive code requiring its own review, prevents the accidental-leak path.
• Scoping admin access narrowly (support staff should not, by default, be able to view raw secret values, only metadata needed for support) and requiring a separate, logged, deliberate action for the rare case where raw access is genuinely needed, reduces both the insider-risk surface and the value of a single compromised admin account.

Worked example

Trace the broken-authorization scenario concretely, since it is the one most specific to this exact system and the easiest to introduce accidentally. The API key retrieval endpoint is implemented as GET /api/keys/{keyId}, and the handler checks that the request carries a valid session token before returning the key, but does not check that keyId belongs to the session's user, an easy omission when the same handler pattern is copied from an earlier endpoint that happened not to need per-owner scoping. An authenticated attacker, who only needs their own valid, low-privilege account to reach the endpoint at all, can then increment or guess keyId values across other users' records and retrieve API keys that were never theirs, entirely within what looks like a normal authenticated request from the system's perspective, since authentication succeeded correctly every time. The mitigation is not "add more authentication," since the failure was never in authentication, it was in authorization: the fix is adding an explicit ownership check, confirming the key referenced by keyId belongs to the authenticated session's user before returning it, and applying that same check pattern to every other resource-scoped endpoint (documents, any future secret type) rather than fixing this one endpoint in isolation.

Trade-offs and pitfalls

The most common mistake on a service like this is conflating authentication with authorization, treating "the request has a valid session" as equivalent to "the request should see this specific data," which is exactly the gap the worked example exploits; the two checks need to be separate, deliberate steps on every resource-scoped endpoint. A second pitfall is under-scoping trust boundaries to only the perimeter (public internet versus backend) and skipping the internal one between "authenticated" and "authorized," which is where this class of bug actually lives on most small services, not at the network edge. A third, easy to miss on a small team, is treating logging and error handling as separate from the security review process; the code path that formats an error message is not obviously security-sensitive, but if it can ever include a secret value in its output, it is exactly as sensitive as the code that stores that secret in the first place, and deserves the same scrutiny.

Approach (brief)

• Implement RFC 2315 / PKCS#7: padding bytes all equal to the number of padding bytes (1..block_size).
• Unpad must validate length and that all trailing bytes equal the pad value.
• To avoid padding-oracle risks: use authenticated encryption (encrypt-then-MAC) so padding errors are never revealed; additionally validate padding in constant-time to limit timing leaks.

Code:

from typing import ByteString

class PaddingError(ValueError):
    pass

def pad(data: bytes, block_size: int) -> bytes:
    if block_size < 1 or block_size > 255:
        raise ValueError("block_size must be 1..255")
    pad_len = block_size - (len(data) % block_size)
    return data + bytes([pad_len]) * pad_len

def unpad(data: bytes, block_size: int) -> bytes:
    if not data or len(data) % block_size != 0:
        raise PaddingError("invalid padding length")
    pad_len = data[-1]
    if pad_len < 1 or pad_len > block_size:
        raise PaddingError("invalid padding value")
    # Constant-time check: accumulate differences without early return
    diff = 0
    for b in data[-pad_len:]:
        diff |= b ^ pad_len
    if diff != 0:
        raise PaddingError("invalid padding bytes")
    return data[:-pad_len]

Validation & side-channel guidance

• Prefer encrypt-then-MAC (or AEAD) so padding is never exposed: verify MAC before attempting to unpad; return a generic failure on any error.
• Use constant-time comparisons (as above) to reduce timing leakage when unpad runs in contexts where MAC isn't used.
• Never return different error messages or timings for padding vs. auth failures.

Definition — AEAD (what & why)
Authenticated Encryption with Associated Data (AEAD) provides confidentiality, integrity and authenticity in one primitive: it encrypts plaintext and produces a tag that covers both ciphertext and optional associated data (AAD) such as headers. Examples: AES‑GCM, ChaCha20‑Poly1305.

Why prefer AEAD vs ad‑hoc composition

• Single primitive avoids subtle ordering/IV/tag misuse.
• Auth and confidentiality are tied: tag verifies ciphertext before use, preventing malleability/bit‑flipping attacks.
• Implementations are constant‑time and vetted; performance is optimized (e.g., hardware GCM, vectorized ChaCha20).

Compare compositions

• Encrypt‑then‑MAC (preferred): MAC computed on ciphertext, verify MAC before decrypt. Offers strong security (CCA).
• MAC‑then‑encrypt: MAC on plaintext, then encrypts both — vulnerable if encryption leaks structural info or malleability allows MAC tampering to be hidden (can enable forgery).
• Encrypt‑and‑MAC: Both done independently — can be secure but tricky: must ensure MAC covers correct material and keys isolated.

Real‑world pitfalls with AES‑CBC + HMAC

• Using same key for HMAC and AES (key separation failure).
• Verifying MAC after decryption (padding oracle: attackers exploit padding errors to recover plaintext).
• Not authenticating AAD (e.g., IV, headers) or using predictable IVs.
• Truncating MACs excessively.
• Rolling your own order/constant‑time checks; subtle bugs lead to CVEs (e.g., TLS 1.0/1.1 issues).

Use standardized AEAD modes and libraries, verify tags before any plaintext usage, and follow key‑separation and nonce/IV rules.

Solution outline (CRT formula)

We want x satisfying:

• x ≡ 2 (mod 3)
• x ≡ 3 (mod 5)
• x ≡ 2 (mod 7)

Let N = 3·5·7 = 105. For each modulus n_i let N_i = N / n_i and find y_i with N_i·y_i ≡ 1 (mod n_i). Then

x ≡ Σ a_i·N_i·y_i   (mod N)

Compute N_i and inverses

• n1 = 3, a1 = 2: N1 = 105/3 = 35. Compute 35 mod 3 = 2. Inverse y1 of 2 mod 3 satisfies 2·y1 ≡ 1 (mod 3) ⇒ y1 = 2.
• n2 = 5, a2 = 3: N2 = 105/5 = 21. 21 mod 5 = 1 ⇒ inverse y2 = 1.
• n3 = 7, a3 = 2: N3 = 105/7 = 15. 15 mod 7 = 1 ⇒ inverse y3 = 1.

Assemble solution

Compute contribution terms:

• a1·N1·y1 = 2·35·2 = 140
• a2·N2·y2 = 3·21·1 = 63
• a3·N3·y3 = 2·15·1 = 30

Sum:

x ≡ 140 + 63 + 30 = 233  (mod 105)

Reduce modulo 105: 233 ≡ 23 (mod 105).

Answer

x ≡ 23 (mod 105). This is the unique solution modulo 105.

Cryptographic note

CRT constructions like this are fundamental in optimizing RSA private-key operations (using prime-power moduli and recombination), so correctly computing N_i and modular inverses is a routine cryptographic primitive.

Direct answer

Name two or three concrete, structural conditions, not vague dissatisfaction, and frame them as things you'd first try to fix rather than immediate exits: a persistent mismatch between the role you were hired for and the work you're actually doing, an integrity or ethics issue, or a growth blocker that doesn't move despite you raising it.

The framework

1. Role-reality mismatch: the day-to-day work is structurally different from what was described (scope, ownership, the kind of problems), and stays that way after you raise it.
2. Integrity issues: being asked to cut corners on something non-negotiable (safety, compliance, honesty with users or stakeholders), a pattern rather than a single mistake.
3. Structural growth blockers: no path to the kind of ownership, mentorship, or technical investment the role implied, and it doesn't change after you propose a concrete fix.
4. The credibility move: pair each condition with "and I'd raise it and try to fix it first," because a values-conflict answer that jumps straight to leaving reads as low commitment, not high standards.

Worked example

I joined expecting to own a defined piece of a system or process, and instead found most of my time going to unplanned, reactive work with no path back to the original scope. I raised it with my manager directly, proposed a specific plan, a scoped project that would let me demonstrate the ownership I was hired for, and gave it a defined window. If that structural mismatch persisted after a genuine attempt to fix it, that's when I'd seriously consider leaving, not on day one of noticing the gap.

Trade-offs and pitfalls

Interviewers are listening for whether your deal-breakers are reasonable and specific or a red flag about how you'll behave when something normal and fixable goes wrong in the first few months; a list that's too long or too easily triggered reads as risk, not self-awareness.

Clarify goals & constraints

• Migrate from unsalted SHA-1(password) → Argon2id without forcing password resets, preserve login UX, limit exposure window, support rollback, and be compliant with NIST/Bcrypt/Argon2 best practices.

High-level strategy

• Adopt lazy re-hash on successful authentication + opportunistic background rehash for active accounts + batched rehash for dormant accounts via secure reset tokens if needed.

Storage format (per-user)

• Keep existing sha1_hash field until migrated.
• Add new column password_scheme ENUM {sha1, argon2} and argon2_hash TEXT.
• Add metadata: salt_version, argon2_params JSON (time, memory_kb, parallelism), migrated_at timestamp.

Example record:

• password_scheme = "sha1"
• sha1_hash = "<hex>"
• argon2_hash = NULL

After migration:

• password_scheme = "argon2"
• sha1_hash = NULL (or retained for audit only, hashed server-side)
• argon2_hash = "$argon2id$v=19$m=65536,t=3,p=4$...$..."

Authentication flow

1. User submits username + password.
2. Load user record.
3. If password_scheme == "argon2":
   • Verify with Argon2id using stored params.
   • If success, return session.
4. Else if "sha1":
   • Compute SHA-1(password) and compare constant-time to stored.
   • If success:
     • Immediately compute Argon2id(password) with current params (perform async but ensure success before marking migrated).
     • Store argon2_hash, set password_scheme="argon2", clear sha1_hash in atomic DB write.
     • Return session.
   • If failure: deny.

Background / bulk migration

• For active users: trigger rehash on next login.
• For heavy-duty migration: send time-limited signed migration link that allows one-step password rehash after user authenticates via token; do not accept password in URL.
• For dormant accounts beyond TTL: force password reset after X months.

Fallbacks & rollback

• Keep SHA-1 verification available for a limited, auditable window.
• Log and monitor rehash success rates; if Argon2 service or parameters cause latency, temporarily degrade Argon2 params (maintain backward compatibility).
• Use feature flag to enable/disable migration path.

Security considerations

• Use Argon2id with conservative parameters (e.g., m=65536KB, t=3, p=4) tuned to service hardware; store params per-user for future upgrades.
• Use constant-time comparisons and rate-limiting.
• Remove or encrypt legacy sha1_hash values when migration completes.
• Audit and rotate secrets; protect DB backups.

Operational notes

• Bench test Argon2 costs; adjust instance types.
• Monitor auth latency, CPU/memory, and migration rate.
• Communicate to users: no forced resets, improved security.

Direct answer
Restate the instruction in your own words as a quick confirmation before acting, framed as checking your own understanding rather than doubting them, so it reads as diligence rather than not having listened.

Structured elaboration

• Frame it as confirming your own plan, not re-asking their request. "Just to make sure I act on the right thing, my plan is to do X, does that match what you meant?" reads very differently from "wait, what did you want again?"
• Be specific in the paraphrase, not generic. A vague paraphrase ("okay, got it, I'll handle it") gives them nothing to correct if you actually misunderstood; a specific one gives them an easy, fast way to say "actually, no" if needed.
• Do it briefly and move on. One sentence of confirmation, not a lengthy negotiation over wording; the goal is a fast check, not a renegotiation of the request.
• If genuinely rushed, confirm asynchronously right after rather than not at all: a one-line follow-up message restating what you understood, sent immediately after the quick instruction, still catches a misunderstanding before you've acted on it.

Worked example
Instruction given quickly in passing: "Can you get that report over to finance today?"

Weak version: "Yep, will do." (No confirmation of which report, which finance contact, or what today means if it's late in the day.)

Better version: "On it, I'll send the Q3 variance report to Priya in finance by end of day, that's the one you mean?"

This surfaces, in one sentence, exactly which report, which recipient, and what "today" means, giving them a fast chance to correct any of the three if you guessed wrong, without making them repeat the whole instruction.

Trade-offs and pitfalls

• Doing this for every trivial instruction can come across as needing excessive hand-holding; reserve the explicit paraphrase for instructions with real ambiguity or real consequences if you get it wrong.
• A paraphrase that's too close to a verbatim repeat of their words doesn't actually test whether you understood the intent, only whether you can repeat words back; try to restate it in language that shows you grasped the underlying goal, not just the surface phrasing.
• If they seem rushed or impatient with the confirmation, a very short version ("Q3 report to Priya today, correct?") gets the same benefit with almost no added time.

Direct answer

When a security or compliance team has the authority to block work and uses it, the goal isn't to overpower them, it's to give them a way to say yes that they would defend to their own leadership. That means understanding the actual concern, proposing controls that address it directly, and building a record that makes the eventual approval easy to justify upward, rather than skipping the concern to hit a deadline.

Structured elaboration

1. Understand the veto, not just the outcome

Ask what specifically drives the block: a known threat pattern, a regulatory obligation, a past incident. A block framed as 'this is too risky' usually decomposes into something concrete once you ask what evidence would change their mind.

2. Propose compensating controls, not blanket reassurance

Bring specific mitigations that map to the stated concern: scoped access, monitoring, a rollback plan, data masking, a smaller blast radius. 'Trust me' rarely moves a team whose job is to not just trust people; a control they can point to in an audit does.

3. Phase the ask so risk and trust build together

Instead of asking for full approval up front, propose a smaller, monitored first step, then expand once it holds up. This gives the blocking team evidence rather than a promise, and it gives you a faster initial yes.

4. When you need executives to sponsor it, not just the compliance team to approve it

Sometimes getting to yes isn't about convincing the blocking team at all, it's about persuading senior executives, without formal authority over them, to sponsor a security or compliance investment that trades short-term revenue for long-term risk reduction. That's a different move: build the case in terms an executive already weighs (the cost of the exposure versus the cost and timeline of the fix), find a credible sponsor who already has their ear, and time the ask to a moment they're already thinking about risk, such as a renewal, an audit, or a near-miss. State the trade-off plainly rather than downplaying either the revenue impact or the risk.

5. When the conflict runs the other direction

The pressure isn't always compliance blocking a launch. Sometimes compliance demands collecting more data for audit purposes, and that request conflicts with the team's own privacy commitments to users. Handle this the same way: scope exactly what the audit requirement needs, then look for a way to satisfy it without violating the privacy commitment, such as aggregating instead of storing per-user data, sampling instead of full capture, or purpose-limited access with automatic expiry. If a genuine conflict remains after that, escalate it as a policy conflict for someone empowered to decide between the two obligations, rather than either side unilaterally overriding the other.

Worked example

A security team initially blocks a new integration on a financial product, citing customer-data exposure risk. Working sessions with security and the app owner map the specific risk to two things: a broad data scope and no kill switch. The team proposes scoped test accounts, data masking, and a remote kill switch, then agrees to a phased rollout: verify the low-risk paths first, escalate to the higher-risk ones only after the first phase holds up under monitoring. Security signs off on the phased plan. Separately, when the same team later wants to expand data collection to satisfy a new audit requirement, they find that a sampled, time-limited collection window satisfies the auditors just as well as full, indefinite collection, so the privacy commitment to users doesn't have to give.

Trade-offs and pitfalls

• Working around a block quietly (shipping a smaller version without telling the blocking team) buys short-term speed and damages the relationship you will need next time; always close the loop even when you find a narrower path.
• Compensating controls that never get revisited become permanent scaffolding; agree upfront on when the phased approach graduates to full trust, not just how it starts.
• On the upward-influence path, leading with fear rather than a clear trade-off tends to get budget approved once and then quietly deprioritized later, because the executive never actually weighed the cost against the risk. Naming the trade-off explicitly is what makes the commitment durable.
• Overriding a genuine policy conflict (audit needs versus privacy commitments) unilaterally, instead of escalating it, tends to resurface as a bigger trust problem with users or regulators later than the original block would have cost in time.

Clarify goal (one line)
Design a secure, scalable lifecycle for TLS private keys in Kubernetes that prevents plaintext exposure while enabling automated issuance, rotation, and service-level use (mTLS, signing).

High-level design

• Root/CA protection: keep long‑term root/intermediate keys in HSMs (PKCS#11) or cloud HSM. Use them only for signing CSRs; never export private key material.
• Operational certs: issue short‑lived leaf certs (minutes–hours) via centralized CA signing service backed by HSM/KMS or by SPIRE (SPIFFE) for workload identities.
• Certificate automation: use cert-manager/SPIRE + ACME or internal CA; integrate with cloud KMS Sign APIs or HSM signing via a signing microservice.

Storage & usage options

• HSM / Cloud HSM: store root/intermediate keys; perform all signing inside HSM. Best for highest assurance.
• Cloud KMS with signing: keep private key non-exportable; workloads call a signing endpoint (KMS EKM) or a signed CSR flow.
• Sidecar proxies (Envoy/Linkerd): terminate mTLS at sidecar which has access to cert material via a secure volume or in-memory mount; reduces app complexity.
• In-process in-memory keystores: for services that perform crypto, mount keys into tmpfs or use in‑memory PKCS#11 providers (e.g., SoftHSM in-memory) and ensure zero disk persistence.

Secure delivery to pods

• Use CSI Secrets Store driver to fetch secrets directly from Vault/KMS into pod memory (tmpfs) with short TTLs.
• Use pod identity (IAM/K8s SA + Workload Identity) so pods authenticate to Vault/KMS with limited-scoped tokens.
• Prefer signing APIs: pod generates private key locally in-memory and sends CSR to CA; CA returns cert. Private key never leaves pod memory.
• If private key must be provided, ensure it is written only to tmpfs, with restrictive permissions, and removed on shutdown.

Rotation & lifecycle

• Short-lived certs (e.g., 1–24h) reduce impact of compromise.
• Automated renewal: cert-manager/SPIRE monitors expiry and reissues via CA; rolling updates coordinated with readiness probes to avoid traffic loss.
• Revocation: use short TTLs + CRLs/OCSP stapling for longer certs; for immediate revocation, revoke via CA and use service mesh to fetch updated CRL/ocsp.

Autoscaling & deployment protections

• Ensure onboarding uses ephemeral credentials: during scale-up, init container or sidecar performs key gen/CSR; no long-lived bootstrap secrets.
• Limit KMS/Vault rate and enforce per-pod quotas to avoid stampeding—use cached signed certs with short TTLs if needed.
• Avoid logging secrets; restrict kubelet/node access; use node attestation for hardware-backed identity.

Defensive controls & monitoring

• Enforce RBAC + KMS policies; separate CA operator privileges.
• Use HSM/KMS audit logs, Vault audit devices, and service mesh telemetry to detect anomalous certificate/signing usage.
• Regular key ceremonies, crypto algorithms reviews, and key rotation policy (e.g., algorithm migration).

Why this works (cryptographer view)

• Non‑exportable keys + server‑side signing reduce attack surface.
• Short-lived certs and in-memory private keys limit plaintext longevity.
• Sidecars or in‑process PKCS#11 providers allow secure use without exposing keys to app code.
• Automated, policy‑driven lifecycle ensures correctness, scalability, and cryptographic hygiene.

High-level goal
Prevent extensions from weakening core guarantees (confidentiality, integrity, authentication, key confirmation) while preserving safe, negotiated extensibility.

Specification language

• Domain-specific manifest (signed) per extension listing: capabilities, intended state changes, cryptographic primitives used, required security properties (e.g., “does not bypass key-confirmation”), explicit side-effects, and formal pre/post conditions.
• Small, typed DSL with capability tokens (read-only, auth-modify) and an effect system; machine-checkable semantics to enable static analysis.

Static checks (pre-deployment)

• Syntax and type checks for the DSL.
• Semantic checks: enforce invariants (e.g., key-confirmation must be performed unless extension provides an equivalent proof).
• Automated formal verification: translate to models for ProVerif/Tamarin to prove no downgrade of authentication/confidentiality properties; require threat-model annotations.
• Cryptographic review: confirm primitives, randomness, key usage, anti-replay.

Runtime guards

• Capability negotiation: server enforces least privilege; extensions request capabilities, server grants subset.
• Monotonic security lattice: extensions cannot lower security level; any operation that would disable a core step is rejected.
• Fail-closed policy: unknown/invalid extension causes handshake failure unless allowlist present.
• Runtime attestations and auditing: log extension usage, enforce rate limits, and runtime checks that post-handshake key-confirmation occurred (e.g., explicit confirmation messages cryptographically bound).

Vetting & deployment

• Multi-stage process: design review → formal verification → crypto peer-review → lab fuzzing and interoperability tests → staged canary rollout with telemetry.
• Require signed manifests and reproducible builds; use feature flags and short-lived canaries; ability to hot-disable extensions (kill-switch) and emergency rollback.
• Incident process: exploit triage, revoke extension manifests, push revocation to clients/servers, and publish security advisories with indicators and mitigations.

This policy balances principled formal verification, conservative runtime enforcement, and operational controls so extensions can evolve without undermining core cryptographic guarantees.