skip to content

A departing contractor copies their laptop's credential stores — which artefacts are usable as-is?

level: seniorimportance: should knowfreq 52%

answer

  1. ask what each still needs
  2. plaintext files need nothing
  3. some need the user's session
  4. some need only guessing
  5. the insider collapses two tiers

basics

~20 s

Rank by what each artefact still needs. Plaintext bearer material — a cloud credentials file, a passphrase-less private key, tokens in dotfiles — works immediately. Password-chained stores need the user's context. Cached domain verifiers only yield to offline guessing.

solid answer

~50 s

Three tiers. **Usable as-is**: anything written in the clear — `~/.aws/credentials` with a long-lived access key, an unencrypted SSH private key, an API token in a config file, a kubeconfig with an embedded token. No password, no cracking, works from anywhere. **Chained to the user**: the browser profile's logins and cookie store, and the platform secret store behind them, which unwrap only for that user's session or with their password. **Crack-only**: cached domain logon verifiers, and a passphrase-protected private key. The `SAM` hive sits alongside, needing the `SYSTEM` hive's boot key to unseal before its fast-cracking unsalted hashes are even readable. The trap is that for a signed-in insider the first two tiers collapse into one — the operating system unwraps tier two for them for free. Teams guard the hashes and ignore the cookie jar and the cloud key file, which are the two that need nothing.

code

text · 7 lines
text
~/.aws/credentials                          -> access key id + secret, plain text   : nothing
~/.ssh/id_ed25519  (no passphrase)          -> private key, plain text              : nothing
<browser profile>/...Cookies                -> session values, profile-key sealed   : the user's session, or their password
%APPDATA%\Microsoft\Protect\<SID>\<GUID>    -> DPAPI master key                     : password-derived material, or the domain backup key
%SystemRoot%\System32\config\SECURITY       -> cached domain logon verifiers        : offline guessing only
%SystemRoot%\System32\config\SAM + SYSTEM   -> local hashes, sealed by the boot key  : both hives, then fast offline guessing
...

go deeper

for a junior

Know that a laptop holds several different kinds of credential material and that some of it, such as a cloud credentials file or an unprotected private key, is simply plain text a copy makes usable.

for a middle

Be able to sort a list of artefacts into needs-nothing, needs-the-user, and needs-guessing, and say what mechanism puts each one there.

for a senior

Show the insider collapse: for someone signed in as themselves the password-chained tier costs nothing, so the ranking that matters for a departing employee is different from the one that matters for a stolen laptop.

for a principal

Own the resulting order of investment across a fleet — retiring long-lived static credentials, mandating passphrases and hardware-bound keys, and being explicit that encryption at rest buys the lost-device case and no other.

## Ask one question of every artefact Not "is it encrypted" but **what does this still need before it authenticates something, and can the person holding the copy supply it?** That single question produces the ranking, and the ranking is the whole point of this material. ## Tier 1 — bearer material, usable as-is Written in the clear, on disk, by design, because the program that reads it needs it back: - `~/.aws/credentials` and its equivalents: a long-lived access key identifier and secret, valid from any network unless the account policy constrains source or requires a second factor for the calls that matter. - `~/.ssh/id_ed25519` with no passphrase — the default outcome when someone presses enter twice. It authenticates to every host with the matching public key in `authorized_keys`. - Tokens written into dotfiles and config files by command-line clients; a kubeconfig with an embedded bearer token; a personal access token in a git credentials file. These need nothing. No password, no host, no session. Copy the file, use it elsewhere. Lifetime is their only real defence, and long-lived is precisely what these tend to be. ## Tier 2 — chained to the user's password or session The browser profile's saved logins and cookie store, and the platform secret store that wraps their key: DPAPI on Windows, the login keychain on macOS. The unwrap condition is "be this user": running as them, or holding their password-derived material plus the master key file, or holding the domain backup key. Note what a **cookie** is once unwrapped, though: bearer material that carries an already-authenticated session, needing neither the password nor a second factor. The store has a lock; the contents do not. ## Tier 3 — offline guessing only - **Cached domain logon verifiers** from the `SECURITY` hive: a salted, heavily iterated derivation that no protocol accepts. Guessing is the only route, and a long passphrase makes it hopeless. - **A passphrase-protected private key**: modern key formats use a deliberately slow key-derivation step, so this is a guessing problem too. A passphrase is the single cheapest thing that moves a key from tier 1 to tier 3. ## The awkward one: local account hashes The `SAM` hive holds local account password hashes, sealed with a boot key derived from the `SYSTEM` hive — which is why both are always taken together and why `SAM` alone is useless. Once unsealed, the hashes are unsalted and fast to attack, so cracking economics here are the opposite of tier 3. ## The insider collapse — the part interviewers are listening for The tiers describe cost **to a thief with the disk and not the session**. A departing contractor is not that person. They are signed in, as themselves, on their own machine. For them the operating system satisfies tier two's unwrap condition on request: the profile secrets come out as plaintext with no password, no master key parsing and no guessing. Tiers one and two collapse into a single "free" tier, and only the crack-only material resists. That is why "just encrypt the disk" — or "encrypt the credential file" one layer down — misses. Every protection whose unwrap condition is *this user's session* is transparent to the one adversary guaranteed to be inside it. ## What the ranking implies for the control choice Rank the estate the same way and the priorities invert from the usual instinct: 1. **Kill the tier-1 population.** Long-lived static keys in files are the highest-value, lowest-effort haul; short-lived credentials issued on demand make a copy stale. Passphrases on private keys move them two tiers down for the cost of a policy. 2. **Narrow unwrap conditions.** Bind material to a specific program or, better, to hardware that will *use* a key and never export it. A hardware-held authentication credential cannot be copied off a disk at all, which is a categorically different property from being encrypted on one. 3. **Shorten sessions that matter.** A cookie is bearer material; its exposure window is its lifetime. 4. **Only then worry about the hashes**, which are the tier everyone reaches for first and which needs the most work to convert into access. The short version to say out loud: *encryption at rest answers the lost-laptop adversary; it answers nothing about the signed-in one, and the material that hurts most is the material that was never protected in the first place.*

  • Why are the SAM and SYSTEM hives always taken together?
    The password hashes in `SAM` are sealed with a boot key that is assembled from material in the `SYSTEM` hive. Without `SYSTEM` there is nothing to unseal them with, so a copy of `SAM` on its own yields account names and structure but no usable hashes.
  • Which tier does putting a passphrase on an SSH private key move it to?
    From tier one straight to tier three. An unprotected key is bearer material that works the moment it is copied; a passphrase-protected key in a modern format is wrapped by a deliberately slow key derivation, so it becomes an offline guessing problem. It is the cheapest single change available on this whole list.
  • The platform team says the real fix is encrypting each credential file at rest. What do you tell them?
    Ask what unwraps it and who can reach that. If the program reading the file can decrypt it in the user's context, so can anything else in that context, and the copy is as good as plaintext. Protection improves only when the unwrap condition narrows — a specific program, hardware that will not export the key — or when the material expires quickly.
  • Why is a session cookie often worth more than a password hash to whoever holds the copy?
    A hash is an input to more work: crack it, or find a service that accepts the derivative. A live cookie is already the end state — it carries an authenticated session, so it needs no password and satisfies no second factor challenge. Its only limits are its expiry and the server deciding the session is over.

saying these in an interview costs you the question

  • Ranks password hashes as the most valuable thing on disk
  • Ignores plaintext cloud credential files and unprotected private keys
  • Assumes the user's own session cannot open password-chained stores
  • Says every artefact needs cracking before it is useful
  • Treats encryption at rest as equal to non-exportable key material

context

resolving links…