Web Security / Advanced: assurance, supply chain, and recovery / Lesson 14

Secrets, keys, and lifecycle boundaries

Separate public configuration, sensitive credentials, cryptographic claims, and recovery dependencies across the web application.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Define secret purpose, access, rotation, revocation, and recovery.
Distinguish hashing, MACs, signatures, and encryption claims.

Identify where authority actually lives

API credentials, session secrets, signing keys, database credentials, and recovery material grant different capabilities. Classify each by purpose and consequence, assign an owner, and minimize where it is copied. Browser bundles and public build variables cannot protect a privileged server secret from the user receiving that code. A client-side environment prefix is not a vault. Keep secrets out of source history, public assets, ordinary logs, and support tickets. Use the platform’s approved secret and key facilities with narrowly scoped identities rather than distributing one shared administrator credential to every component.

Inventory metadata without collecting the secret

A secret inventory should record purpose, owning service, allowed use, storage reference, rotation or review, and compromise response without exporting the secret value. The example is descriptive metadata and points to no real vault or account. Review who may use a secret versus administer its policy, and how access ends when a service or staff role changes. Avoid granting broad read access merely because a deployment tool is convenient. A stored reference needs its own authorization and audit path. Evidence should show that the intended consumer gets the required capability while unrelated consumers do not.

json A fictional secret-lifecycle inventory item

{
  "secretLabel": "synthetic-note-service-key",
  "purpose": "approved-service-operation",
  "ownerRole": "service-key-maintainer",
  "storageReference": "fictional-managed-reference",
  "allowedConsumer": "specific-service-role",
  "compromiseAction": "approved-revocation-and-review",
  "containsMaterial": false
}

No secret is generated, read, stored, rotated, or revoked. The reference is a teaching label only. A real process must verify identity, permissions, auditability, and recovery under the selected platform’s documented behavior.

Choose the property before the primitive

A hash can support change detection when its expected value is trusted. A MAC uses a shared secret key for message authentication among key holders; a digital signature has a public-key verification and trust model. Encryption protects confidentiality under its supported protocol, while authenticated encryption adds integrity requirements that must be used correctly. None automatically establishes business authorization or accurate content. Do not assemble a home-made protocol from individual library calls. Password storage needs its own supported hashing design. Key purpose, nonce and freshness rules, identity binding, and safe error behavior belong in the reviewed system, not in a copied code fragment.

Demonstrate a keyed comparison with public lab bytes

The complete example calls the standard HMAC construction with a deliberately public classroom key. It checks the original and changed benign message under that key without reading any credential. Because the key is public, the result provides no real protection and must not be copied into production. Even a protected shared MAC key cannot identify which authorized holder produced a tag. A real protocol needs safe key distribution, lifecycle, message interpretation, and replay handling. The local assertion is useful for distinguishing integrity/authenticity mechanics from the broader trust and authorization questions.

python A complete offline HMAC property example

import hashlib
import hmac

lab_key = b"public-classroom-key-not-a-credential"
message = b"synthetic note revision: 1"
tag = hmac.new(lab_key, message, hashlib.sha256).digest()
assert hmac.compare_digest(tag, hmac.new(lab_key, message, hashlib.sha256).digest())
assert not hmac.compare_digest(tag, hmac.new(lab_key, b"synthetic note revision: 2", hashlib.sha256).digest())

Both assertions operate on invented public bytes. No credential service, signature provider, encrypted file, or account is involved. The demonstration is not a production token implementation or a complete replay defense.

Treat loss and disclosure as different failures

Losing a decryption key can make retained data unusable, while disclosure can invalidate confidentiality or authenticity assumptions. Rotation must consider old ciphertext, verification needs, caches, replicas, and backups. A new active key does not automatically preserve access to historical material. Define authorized revocation, replacement, re-encryption, investigation, and recovery as appropriate to purpose. Removing a secret from the latest commit does not revoke it or erase historical copies. Use the owner’s exposure-response process and test recovery with synthetic material in an isolated approved environment, not real keys in a course or diagnostic attachment.

Common errors and fixes

A client build variable contains a server master key

Why it happens: Public configuration is confused with protected secret storage.
How to fix it: Remove exposure and follow the owner’s revocation/recovery process.
Prevent it next time: Review all client-visible values and artifacts.

Rotation makes retained backups unreadable

Why it happens: Historical key requirements were omitted.
How to fix it: Review approved retained versions and recovery dependencies.
Prevent it next time: Exercise key recovery with the data lifecycle.

A correct primitive is treated as a complete protocol

Why it happens: Key, identity, and freshness requirements are hidden.
How to fix it: Use an approved supported design and review the entire boundary.
Prevent it next time: State the exact claim of every cryptographic example.

Check your understanding

1. A secret is removed from source. What can remain unresolved?

Show worked solution

The credential may still be valid and copied into history, artifacts, caches, or another user’s clone. Follow authorized revocation and investigation, then repair storage and release practices. File removal alone is not credential response.

2. Why does the HMAC example with its publicly known lab key provide no actual authenticity?