Skip to content

Credential Storage

Windows support

Secrets are stored in portions of the secondary storage that can only be read by the SYSTEM account. Such portions are either certain registry keys or certain files in certain directories, depending on the specific key considered.

The bootkey is stored in the registry (split in four different parts).

System secrets:

  • The computer account credentials (necessary only for domain-joined computers) are stored encrypted with a key derived from the bootkey (the LsaKey).
  • User keys (actually, the hashes of their password) are stored in the SAM, encrypted with a key derived from the bootkey (the SAM key).

Application secrets (passwords, encryption keys, service keys and so on):

  • Managed through a family of system calls called DPAPI. Secrets stored with DPAPI are encrypted with a master key associated with the user.
  • The user key is stored encrypted with the user key (password hash) and with a machine master key. Either key suffices for decrypting the master key and, thus, obtain the DPAPI secrets of the user. The reason why either key suffices is to allow decryption either when the user is logged in (user key path) or by SYSTEM for recovery (machine key path). The machine master key is stored encrypted with the LsaKey.

Browser secrets (cookies, passwords)

Each browser stores secrets (cookies, passwords, form data and alike) in a database.

Up to 2024, Chromium-based browsers encrypted the database with a browser_key associated with the user and stored with DPAPI.

A malware running with the user identity could thus obtain the browser_key, by simply querying DPAPI.

Application-bound encryption

The database is encrypted with an app_bound_key. The key of a given user is stored with DPAPI but is accessible only to SYSTEM.

Actual access to the key occurs through a service running with the SYSTEM identity and high integrity. This "ElevatedService" runs as a separate process. The ElevatedService associates each app_bound_key with the user identity and with the process that created that key (executable path and other properties).

When the browser needs to read/write a key, it does so by communicating with the ElevatedService. The ElevatedService ascertain the identity of the invoking process in a secure way, by checking the above properties through OS mechanisms.

A malware running with the user identity, thus, cannot obtain the app_bound_key` unless it injects within the browser process. Malicious extensions are a possibility.

A malware running with SYSTEM identity may potentially obtain the key, either by interacting with the ElevatedService, or directly with DPAPI, or by injecting into the browser process.

Device-bound session protection

An attacker that manages to steal a cookie is able to use that cookie from any other location, until the cookie expires. Device-bound session protection (DBSC) makes it impossible to use a stolen cookie from a location different from the original one; more precisely, a stolen cookie may be used from any location but it is guaranteed to expire within a few minutes.

This functionality requires:

  • Hardware support at the client side in the form of a TPM: Trusted Platform Module (mandatory in Windows 11 machines). It can store encryption keys and execute cryptographic operations.
  • Support at the server side.

A webapp that supports DBSC indicates this to the browser by returning an HTTP response header:

Secure-Session-Registration: (ES256); path="/dbsc/register"; challenge="abc123"

The browser:

  • generates a private-public keypair;
  • associates the keypair with the session and stores it in the TPM;
  • signs the challenge with the private key;
  • sends signature and public key to the webapp, at the indicated path;

The webapp:

  • associates the public key with the session;
  • issues a new short-lived cookie;

Whenever a new short-lived cookie has to be issued, browser and application will execute an interaction similar to the above, so that the browser proves possession of the correct private key. They usually will do that proactively, before the short-lived cookie actually expires.

A malware might be able to steal the short-lived cookie but it will expire quickly.