Skip to main content
Identity Authority
Category: Passwords & Hashing

Credential Storage

Also known as: Credential Store, Credential Locker, Secure Credential Storage
Simply put

Credential storage is the practice of keeping authentication secrets, such as passwords, API keys, certificates, and access tokens, in a protected place so they are safe when not in use. Some storage methods are secured against compromise, while others, like plain-text files, offer little to no protection. How well credentials are protected depends heavily on the specific tool and configuration used.

Formal definition

Credential storage refers to the system, datastore, or repository used to persist authentication secrets at rest, including passwords, API keys, certificates, OAuth 2.0 access tokens, and similar material. Implementations vary widely in their security posture and configuration: platform-integrated mechanisms such as the Windows Credential Locker are designed to store and retrieve credentials securely, whereas Git's 'store' mode writes credentials to a plain-text file on disk that never expires until the underlying credential is changed. Note that credential storage concerns protection of secrets at rest and is distinct from the authentication and authorization flows that later consume those secrets; the specific protections applied (for example encryption at rest versus plain-text persistence) depend on the vendor and deployment.

Why it matters

Authentication secrets are only as safe as the place they are kept when not in use. A password, API key, certificate, or OAuth 2.0 access token that is meticulously validated at runtime still becomes a liability if it is persisted insecurely at rest. The gap between well-protected and poorly-protected storage is wide: platform-integrated mechanisms such as the Windows Credential Locker are designed to store and retrieve credentials securely, whereas some tooling defaults write secrets to plain text. Git's 'store' credential mode, for example, saves credentials to a plain-text file on disk that never expires until the underlying credential itself is changed, meaning a single file read can hand an attacker a long-lived secret.

Because credential storage protects secrets at rest, it sits upstream of nearly every access decision an organization makes. A compromised credential store can undermine authentication and authorization flows that are otherwise sound, since those flows trust the secrets the store hands them. The security posture is not uniform across tools; it depends heavily on the specific mechanism and its configuration, so teams cannot assume that using a 'credential store' by name guarantees strong protection. In most deployments, the difference between encryption at rest and plain-text persistence is a configuration choice that determines the blast radius of a host or file-level compromise.

Who it's relevant to

IAM Engineers
IAM engineers select and configure the mechanisms that persist secrets such as passwords, API keys, certificates, and access tokens. They need to understand that storage security varies by tool and configuration, choosing a platform-integrated secure store like the Windows Credential Locker over a plain-text default such as Git's 'store' mode can materially change exposure at rest.
System Administrators
Administrators operate the hosts and tooling where credentials come to rest. Recognizing that some modes, like Git's 'store' mode, write secrets to a plain-text file that never expires until the credential is changed helps them avoid long-lived, easily-read secrets on disk and prioritize secure storage options where available.
Security Architects
Architects design where authentication secrets are persisted and how that layer is separated from the flows that consume them. Since credential storage protects secrets at rest and is distinct from runtime authentication and authorization, architects must account for the storage layer's protections, or lack thereof, as part of the overall attack surface.
Compliance Officers
Compliance leads assess whether secrets are protected at rest according to policy. Because protections depend heavily on the specific tool and configuration, ranging from encryption at rest to plain-text persistence, they need to verify actual storage behavior rather than assume a component labeled a 'credential store' provides adequate protection.

Inside Credential Storage

Password Hashing
The practice of storing passwords as one-way, computationally expensive hashes rather than plaintext or reversibly encrypted values. Modern deployments typically use algorithms designed to resist brute-force attacks, such as bcrypt, scrypt, Argon2, or PBKDF2, with the specific choice depending on policy and available libraries.
Salting
A unique random value added to each credential before hashing so that identical passwords produce different hash outputs, defeating precomputed lookup (rainbow table) attacks. Salts are typically stored alongside the hash and need not be secret.
Peppering
An optional secret value applied in addition to a salt, but held separately from the credential store (for example in an HSM or application configuration) so that a database compromise alone does not expose it. Its use and implementation vary by deployment.
Encryption at Rest
Protection of the underlying credential store or secrets vault using encryption so stored data is unreadable without the appropriate keys. Note that encryption is distinct from hashing: encryption is reversible with a key, whereas password hashing is intentionally one-way.
Secrets and Key Management
Systems such as vaults, key management services, or hardware security modules (HSMs) used to store non-password credentials like API keys, private keys, and encryption keys, and to control access to peppers or encryption keys protecting the credential store.
Credential Types
The distinct classes of secrets a store may hold, including user passwords, machine and service credentials, API keys, and cryptographic key material. These often warrant different storage and handling controls; for example, FIDO2/WebAuthn deployments store public keys server-side rather than shared secrets.
Access Controls on the Store
Authorization and least-privilege restrictions governing which principals and services may read or write to the credential store, plus auditing of that access. This is an enforcement concern separate from how credentials themselves are cryptographically protected.

Common questions

Answers to the questions practitioners most commonly ask about Credential Storage.

Is storing a credential in hashed form the same as storing it encrypted?
No. Hashing and encryption are distinct operations with different purposes. Password hashing (typically with a purpose-built, adaptive algorithm and a per-credential salt) is a one-way transformation intended so that the original value cannot be feasibly recovered, even by the system that stores it. Encryption is a reversible operation that requires a key to decrypt back to plaintext. Passwords are generally hashed, not encrypted, precisely because the stored system never needs to recover the original value, it only needs to verify a presented value against the stored hash. Reserving encryption for secrets that must be retrieved later (such as certain API keys or tokens) is a common design distinction, though specifics depend on the use case and deployment.
Does encrypting stored credentials mean they are also signed, or that their integrity is guaranteed?
Not necessarily. Encryption provides confidentiality, it protects the value from being read without the key, but encryption alone does not inherently guarantee integrity or authenticity. Whether tampering can be detected depends on the specific mode and construction used (for example, authenticated encryption modes provide integrity protection, while some older modes do not). Signing is a separate concern from encryption. Do not assume that because a stored credential is encrypted it is also protected against undetected modification; the integrity properties depend on the exact cryptographic construction and configuration in use.
Where should application secrets and machine credentials be stored rather than passwords?
Machine credentials, API keys, and service secrets are typically kept in a dedicated secrets management system rather than in application source code, configuration files, or a general-purpose user directory. Because these secrets often must be retrieved in usable form at runtime, they are generally stored encrypted (rather than hashed like user passwords) so the value can be recovered when needed. The exact approach depends on the platform, the sensitivity of the secret, and operational requirements such as rotation and access auditing.
How does salting affect credential storage, and should salts be kept secret?
A salt is a per-credential value combined with the password before hashing so that identical passwords do not produce identical stored hashes, which frustrates precomputed lookup attacks. Salts are typically unique per credential and are generally stored alongside the resulting hash; they are not required to be secret to serve their primary purpose. Some designs additionally use a separate secret value held apart from the credential store to add another layer, but that is a distinct mechanism from the salt itself and depends on the deployment.
What should happen to stored credentials during account lifecycle events like deprovisioning?
Credential storage intersects with identity lifecycle management, but the two are distinct concerns. During deprovisioning, credentials associated with an account are typically invalidated or removed so they can no longer be used to authenticate. How this is handled, immediate deletion, disabling, or retention under a defined policy, depends on the system, retention requirements, and any audit or compliance obligations. Coordinating credential invalidation with broader deprovisioning workflows is generally an identity governance and administration (IGA) responsibility, separate from the runtime enforcement that rejects the now-invalid credential.
What considerations apply when migrating or upgrading a credential store's hashing scheme?
Because password hashes are one-way, a stored hash generally cannot be re-hashed with a stronger algorithm without the original plaintext. A common approach is to upgrade opportunistically: when a user authenticates successfully against the existing hash, the presented plaintext is re-hashed with the newer scheme and the stored value is replaced. This allows gradual migration without forcing a mass password reset, though older hashes may persist for inactive accounts until they authenticate or a reset is enforced. The exact strategy depends on the algorithms involved and operational constraints.

Common misconceptions

Encrypting stored passwords is as secure as hashing them.
Encryption is reversible: anyone with the key can recover the plaintext, so a compromise of both the store and the key exposes passwords. Password hashing is intentionally one-way and, when combined with a per-credential salt and a suitably slow algorithm, does not permit recovery of the original password. These serve different purposes and should not be treated as interchangeable.
A salt must be kept secret to be effective.
A salt's purpose is to ensure uniqueness across hashes and defeat precomputed attacks such as rainbow tables; it typically does not need to be secret and is usually stored alongside the hash. A pepper, by contrast, is the value intended to be kept separate and secret.
All credentials in a store are shared secrets that must be protected the same way.
Different credential types call for different handling. Passwords are typically salted and hashed, encryption and signing keys are managed in key stores or HSMs, and public-key credentials such as those used by FIDO2/WebAuthn store only public keys server-side, which are not sensitive shared secrets in the same way.

Best practices

Store user passwords using a modern, deliberately slow password-hashing algorithm (for example bcrypt, scrypt, Argon2, or PBKDF2) with a unique per-credential salt, and tune work factors as hardware improves.
Never store passwords in plaintext or as reversibly encrypted values, and avoid substituting encryption for password hashing since the two solve different problems.
Manage non-password secrets such as API keys and cryptographic key material in a dedicated secrets vault or HSM rather than in the same table as hashed passwords.
Consider adding a separately stored, secret pepper where the deployment supports secure isolation of that value, so a database-only compromise does not directly enable offline cracking.
Apply least-privilege access controls and audit logging to the credential store, limiting which services and principals can read or write credential data.
Prefer public-key-based mechanisms such as FIDO2/WebAuthn where feasible, so the server stores public keys rather than shared secrets, reducing the impact of a store compromise.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.