Chapter 19 — Identity and cryptography | Engineering Authorized offensive security and red team

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 19 — Identity and cryptography

Lesson map

Lesson 19 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["19.1 Auth configuration"]
  N2["19.2 Evidence hashing"]
  N3["19.3 Secrets in tools"]
  N4["19.2b What a hash does not prove"]
  N5["19.3b Algorithm choices"]
  N6["19.1b Certificate inventory"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["19.1 Auth configuration"]
  N2["19.2 Evidence hashing"]
  N3["19.3 Secrets in tools"]
  N4["19.2b What a hash does not prove"]
  N5["19.3b Algorithm choices"]
  N6["19.1b Certificate inventory"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[Learning outcomes]
    |
    v
[19.1 Auth configuration]
    |
    v
[19.2 Evidence hashing]
    |
    v
[19.3 Secrets in tools]
    |
    v
[19.2b What a hash does not prove]
    |
    v
[19.3b Algorithm choices]
    |
    v
[19.1b Certificate inventory]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) assess auth configuration without attacking crypto; (2) use hashing for evidence integrity; (3) handle secrets safely in tooling.

19.1 Auth configuration

Ask: which IdP, which factors, which roles, which token lifetimes? Read configuration and logs under authorization. Breaking TLS or cracking password hashes is outside this book's labs and usually outside student scope.

Configuration and logs under a granted role answer lifetime, factors and role maps without turning the lab into crypto breaking. Token lifetime findings are operational and fixable. Sam records the IdP product and version beside each auth finding so remediation aims at the right console. Password-hash cracking requests are refused with a pointer to this boundary.

19.2 Evidence hashing

Hash evidence files (SHA-256) and store the digests in the ticket. Re-hash later to detect tampering. The lab shows a mismatch when a file changed.

"""Verify integrity of a synthetic evidence package."""
import hashlib, json
files = {
    "roe.pdf": b"SYNTHETIC-ROE-v1",
    "scope.csv": b"host,port\n10.20.1.10,443\n",
    "findings.json": b'[{"id":"SYN-001"}]',
}
expected = {n: hashlib.sha256(b).hexdigest()[:16] for n,b in files.items()}
# Simulate tampering of findings.json
current = dict(expected)
current["findings.json"] = hashlib.sha256(b'[{"id":"SYN-001"},{"id":"TAMPERED"}]').hexdigest()[:16]
print(json.dumps(expected, indent=1))
for n in sorted(expected):
    status = "OK" if expected[n] == current[n] else "MISMATCH"
    print(f"{n:16} {status}")

Expected output:

{
 "roe.pdf": "18d74983d403e7db",
 "scope.csv": "01cc4815eddf3de6",
 "findings.json": "7f5f178ab43ef00f"
}
findings.json    MISMATCH
roe.pdf          OK
scope.csv        OK

Digests in the ticket make later tampering visible even if the file store is altered. Re-hashing at review time is a one-line check. The lab's mismatch case trains the reflex to dig when hashes disagree. Sam refuses to close a finding whose current digest differs from the ticket without an AUTH note explaining the change.

19.3 Secrets in tools

Assessment credentials live in a vault; tools fetch short-lived tokens. No secrets in git, screenshots or chat. Rotate at engagement end.

Synthetic case — Riverstone Transit. The hash lab showed findings.json mismatched — someone had edited a severity field after sealing. Sam restored from the sealed store and opened a process finding about uncontrolled edits.

Short-lived tokens limit how long a leaked string works. Git and chat are permanent enough to treat any secret pasted there as burned. Rotation at close-out is on the same checklist as account disable. Sam's CI greps for token-shaped strings and fails the build when they appear.

19.4 Errors and limits

Hashes detect change, not malice versus accident. Pair them with access logs.

A changed file might be an edited screenshot or a malicious swap; the hash alone cannot say which. Access logs show who touched the object and when. Sam always files hash and log reference together before calling evidence sealed, and he treats a missing log as an incomplete seal even when the digest still matches. Accident versus malice is then a question for the access log and the people who hold it.

19.2b What a hash does not prove

A matching digest says the bytes are the same as when sealed; it does not say the bytes were obtained lawfully, that the account was authorized, or that the interpretation in the finding text is correct. Pair hashes with the ROE version, actor id and a short method note so a reviewer can reconstruct the claim, not only the file.

Reviewers who stop at a green checkmark miss unlawful collection and wrong interpretation. ROE version and actor id tie the bytes to permission and person. A short method note explains what the file is supposed to show. Sam's seal checklist has four boxes: digest, ROE, actor, method.

19.3b Algorithm choices

Prefer SHA-256 or stronger for evidence manifests; avoid MD5/SHA-1 for new work. Document the algorithm in the manifest so a future reader does not guess. Cryptographic agility here is a version field, not a silent swap mid-engagement.

MD5 and SHA-1 collisions are teaching history, not a base for new manifests. Naming the algorithm in the manifest stops a future reader from assuming MD5 because a legacy tool printed it. Silent swaps mid-engagement split the evidence set into incompatible digests. Sam pins the algorithm in TrackScope config and rejects uploads that omit it.

19.1b Certificate inventory

For TLS-facing assets, record presented certificates (subject, issuer, notAfter) under authorization. Expired or mismatched certs are findings about operations integrity; do not turn the exercise into a research-grade TLS attack.

Subject, issuer and notAfter under authorization are enough to flag expiry and name mismatch. Sam stores the PEM fingerprint in the ticket so a re-test can see whether the cert changed. Inventory runs are scheduled, not improvised during a noisy scan. Certificates that expire inside the engagement window are reported to the client contact the same day rather than held for the final report.

Exercises

EX055 — Auth questions. List five configuration questions for Riverstone's staff SSO. Rubric: 3 = five concrete (IdP, MFA, roles, lifetime, admin path); 2 = three; 1 = one; 0 = none.
EX056 — Hash lab. Which file mismatched and what do you do? Rubric: 3 = findings.json; restore/re-seal; investigate who wrote; 2 = file only; 1 = vague; 0 = wrong.
EX057 — Secret rule. Write a one-line policy for assessment passwords in tickets. Rubric: 3 = never in ticket body; reference vault id; 2 = "don't share"; 1 = weak; 0 = allows paste.

Synthesis

Read identity config; hash evidence; keep secrets in a vault.

Continue studying — chapter 19 of 50

← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →