Skip to main content

Credentials

Definitions​

Two words this page uses a lot, and they don't mean quite the same thing:

  • Credential — anything that proves identity or authorization. Broader than it sounds: a username is part of a credential pair without being secret at all, and a passkey's public half is registered openly with the site precisely because only its private half needs to stay hidden.
  • Secret — anything whose value depends entirely on staying confidential. Narrower than "credential" in one direction (a username isn't one) and wider in another — an encryption key is a secret without being a credential at all, since it decrypts rather than proves who you are.

No clean third word covers both. In practice the industry has settled on "secret" anyway — secrets management, a secrets manager — as the loose umbrella term for this whole category, imprecision included.

Concepts​

Not specific to any tool or credential type — general enough to double as a checklist for how well an organisation is actually doing this, not just what practices it claims to follow:

  • Least privilege — a credential should grant only the minimum access its job actually needs, nothing more. The smaller the scope, the less damage its leak can do.
  • Blast radius — the same concept backups uses: how much is actually exposed if this one credential is compromised, not how bad the compromise itself is. A narrowly scoped credential and a broadly scoped one can be equally leaked, with very different consequences.
  • Encryption at rest — a credential sitting in storage is only as safe as whatever protects that storage itself. Encrypting it there means a copy of the raw disk or database alone isn't enough to read it.
  • Secure secret injection — resolving a credential straight into a process's environment at the moment it's needed, rather than writing it to disk first, means there's never a file sitting there for anything else to stumble into.
  • Rotation — credentials expire and get replaced on a schedule, not left valid indefinitely. One that's rotated soon after a leak stops being useful even if the leak itself is never noticed.
  • Segregation of duties — no single credential should be able to unilaterally do the most damaging things alone; the most sensitive actions need more than one credential's cooperation.
  • Credential sprawl — the same secret copied into more places than necessary is a new leak surface each time, not a convenience. Resolved once at the point of use is safer than the same value pasted everywhere.
  • Centralised secrets management — one place holding every credential, rather than scattered across flat files, notes, and chat logs, is what actually makes rotation, auditability, and revocation possible at all. You can't rotate what you can't find.
  • Short-lived credentials — access that expires automatically after a set window is a smaller target than the alternative, standing privilege: access left valid all the time whether or not it's actually being used.
  • Auditability and monitoring — knowing who or what used a credential, and when, turns "something leaked" into "here's exactly what it touched," rather than having to assume the worst about everything it could have reached. That only works if something's actually watching for it, too — an audit log nobody looks at is just as blind as no log at all.
  • Incident response planning — knowing in advance what actually happens when a credential leaks — who's notified, what gets rotated, in what order — is what turns a leak into a contained event instead of a scramble. Deciding this after the fact is deciding it too late.

Types of credentials​

Not interchangeable — each has a different shape, and that shape determines how it has to be handled. Split by who actually holds them:

Human​

  • Passwords — the classic shared secret, and the weakest link by default: reuse, phishing, and weak choices are all user-side failure modes no amount of server-side security fixes.
  • TOTP — not a credential by itself, a second factor: a shared seed derives a time-limited code, proving possession of a device rather than just knowledge of a secret, alongside whatever the first factor already proved.
  • Passkeys — an asymmetric keypair, bound to the specific site it was created for. Replaces password and TOTP together with one factor that's actually phishing-resistant, since the private key never leaves the device and can't be typed into the wrong site by mistake.

Machine​

  • SSH keys — an asymmetric keypair, not a shared secret: the private half should never leave wherever it's held (an agent socket, ideally, not a file on disk), and only the public half ever gets distributed or trusted anywhere.
  • API keys — a bearer secret: whoever holds the string can act as that identity, with no separate proof of possession required. Scoping what it can actually do matters more here than almost anywhere else, since the string alone is the entire credential.
  • Encryption keys — decrypts data already at rest, rather than proving identity to log in. Losing it doesn't just lock you out the way a password does — whatever it encrypted becomes permanently unreadable, with no reset option.

Tooling​

Dedicated tooling for credentials stopped being optional the moment AI agents entered the workflow. A secret sitting in a flat file used to be a problem a careful person could mostly get away with — a discipline issue, not a structural one. An agent with shell access changes that: it reads whatever's on disk, credentials included, and can echo them straight into a log or a chat transcript.

There are two kinds of tool for this. A password manager is built for a person to unlock — logins, personal secrets, an interface meant to be opened and read. A credential manager is built for a machine to read at runtime — environment variables, resolved without a human ever typing them. Not a hard boundary, though — either can end up doing some of the other's job, so it's worth checking a specific tool's actual feature set rather than assuming the category name settles it.

A third kind of tool helps from a different angle: an identity provider doesn't store credentials at all, it centralises who's allowed to log in where, so a service checks with it instead of holding its own user database. That's how SSO ends up reducing how many credentials exist in the first place, rather than just protecting the ones that do.

Credentials leak by accident too, not just by being stolen — a key hardcoded and committed to git, still recoverable from history even after a later commit deletes it. Secret-scanning tools exist specifically for this: checking commits, locally before they're even pushed or continuously against a whole repository afterward, for patterns that look like a credential, and flagging or blocking it before it ships anywhere further.

Protocol​

Concepts and tooling alone don't answer what to actually do when a credential is created or reviewed later — that's a separate, practical question worth defining explicitly rather than leaving implicit:

  • Granting — before adding any credential, decide what it actually needs: full access or a scoped subset; a login, or just a token. Grant exactly that, not whatever's most convenient to set up in the moment.
  • Rotation — every credential should have an expected lifetime, not just get created once and left indefinitely.
  • Auditing — periodically check what's actually authorized against what's actually still needed, not what was granted at some point and forgotten. A credential nobody's looked at since it was created is a liability whether or not it's ever misused.

Attack vectors​

What credentials actually need protecting from:

  • Brute force / guessing — repeatedly trying combinations until one works. Automatable, cheap, and doesn't require knowing anything about the target beyond that a login exists.
  • Credential stuffing — trying username/password pairs leaked from a different, unrelated breach, betting on reuse. No guessing involved — the credential is already known, just for the wrong service.
  • Phishing — tricking a person into handing a credential over directly. No guessing or interception needed; it targets the human, not the system.
  • Account recovery abuse — attacking the reset path instead of the credential itself: weak security questions, SMS-based reset interception, or compromising the one email account everything else resets through. Skips the credential entirely and goes after what replaces it.
  • Malware / infostealers — malicious software on the endpoint itself, capturing a credential as it's typed or lifting it straight out of local browser or password-manager storage. Doesn't need the person to act the way phishing does, and doesn't need the credential to be sitting somewhere externally readable the way exposure at rest does.
  • Interception in transit — capturing a credential while it's actually moving between two points, not sitting still anywhere: unencrypted HTTP, a rogue Wi-Fi access point, ARP spoofing, SSL stripping.
  • Exposure at rest — a credential sitting somewhere readable: a flat file, a git commit, a log, an unencrypted backup. Doesn't require attacking anything actively, just finding what's already sitting there.
  • Session/token theft — stealing something already-authenticated rather than the credential that produced it. The login already happened; what's stolen is the proof of it.
  • Insider / scope misuse — legitimate access used beyond what it was actually granted for. Not a breach in the traditional sense — the credential works exactly as intended, just in the wrong hands or for the wrong purpose.
  • Supply chain compromise — a dependency, plugin, or vendor that legitimately held a credential gets compromised itself, and that access gets used from there. Different from insider misuse — the access was granted correctly, to something else, which is what got compromised.