Security

44.0 What this chapter gives you#

1. You will be able to say what security actually means, using the five properties professionals name, and build a threat model in plain words.
2. You will be able to explain what a hash is, why MD5 and SHA-1 are dead, and read real hash values computed in front of you.
3. You will be able to store passwords correctly, choose Argon2id parameters that a working engineer would accept, and explain salt versus pepper.
4. You will be able to describe symmetric and asymmetric encryption, name the modes that are safe in 2026, and say why nonce reuse destroys everything.
5. You will be able to explain post-quantum cryptography, the standards NIST approved on 13 August 2024, and why “harvest now, decrypt later” matters.
6. You will be able to describe every common web vulnerability class, the flawed pattern behind it, and the fix that removes it by construction.
7. You will be able to explain memory safety, why C allows the bugs it does, and what the 2023 to 2025 government guidance actually asks for.
8. You will be able to name the realistic ways machines get infected, recognize social engineering, and run a first hour of incident response calmly.
9. You will read this as a defender. The chapter explains how attacks work so that you can stop them, and contains no working attack code by design.
10. You will build on two earlier chapters rather than repeat them: Chapter 32 covered TLS and certificates, and Chapter 42 covered SSH keys and tokens.

44.1 What security actually means#

PLAIN44.1.1 in simple words#

1. Security is not one thing. It is a small set of promises about your data.
2. Promise one: only the people who should see it can see it. That is confidentiality.
3. Promise two: nobody can change it without you noticing. That is integrity.
4. Promise three: when you need it, it is there. That is availability.
5. Those three together have a nickname in the trade: the CIA triad. It has nothing to do with any spy agency. The letters are just the three words.
6. Two more promises matter and are often left out.
7. Promise four: the thing claiming to be Ravi really is Ravi. That is authenticity.
8. Promise five: once Ravi signed something, he cannot later say he did not. That is non-repudiation.
9. Notice that these promises can fight each other.
10. Locking a file with a key nobody has protects confidentiality perfectly and destroys availability completely.
11. So security is always a set of trade-offs, never a single maximum.
12. And this is the sentence to carry with you: security is a property of a whole system in a particular situation. It is not a product you buy.
13. A very strong lock on a door with a glass panel next to it is not security. It is a strong lock.

PLAIN44.1.2 a picture in your head#

1. Think of a small jewellery shop on a busy street.
2. Confidentiality is the curtain in the back room, so passers-by cannot see the safe being opened.
3. Integrity is the sealed ledger, so nobody can quietly add a line saying they already paid.
4. Availability is the shop being open at ten in the morning, as promised.
5. Authenticity is checking the ID of the man who says he is from the insurance company.
6. Non-repudiation is the signed receipt the customer cannot later deny.
7. Now do the thing a security professional does. Ask three questions.
8. What am I protecting? The gold, the ledger, the customer list, the reputation.
9. From whom? A casual thief, a professional gang, a dishonest employee, a competitor, a government.
10. What happens if I fail? Money lost, customers gone, licence revoked, somebody physically harmed.
11. Those three questions, written down, are a threat model.

Where this comparison breaks: a shop thief must physically be on that street. A network attacker can be in another country, can try a million shops per hour, and can automate everything. Scale is the difference that changes everything. A lock that keeps out ninety-nine of a hundred thieves is a good lock in a street and a broken lock on the internet, because the internet will send you ten million thieves per day and only needs one to succeed.

PLAIN44.1.3 a worked example#

1. Let us threat model something real: the reader’s own laptop and its GitHub account, from the running example used in this book.
2. Assets, written plainly.

3. Adversaries, from cheapest to most expensive.
4. An automated scanner that tries known passwords on anything it finds. Cost to the attacker: near zero. Likelihood: certain, continuously.
5. A phishing email pretending to be GitHub. Cost: low. Likelihood: high.
6. A thief who steals the laptop from a cafe. Cost: moderate. Likelihood: low but real.
7. A targeted attacker who wants this specific person. Cost: high. Likelihood: low unless the person is unusually interesting.
8. Now score the risk. Risk = likelihood x impact. Both parts matter.
9. Stolen laptop: likelihood low, impact very high. Product: medium-high. So full disk encryption is worth it.
10. Automated password guessing: likelihood certain, impact high. Product: very high. So a hardware key or passkey on GitHub is worth it.
11. A nation-state adversary: likelihood very low for most readers. Do not spend your budget there first.
12. That last line is the whole discipline. You cannot defend everything, so you rank by likelihood times impact and start at the top.

PLAIN44.1.4 what is really happening inside#

1. Every system has an attack surface: the complete list of places where untrusted input can reach your code.
2. Open network ports are attack surface. So are file uploads, query parameters, environment variables, image parsers and USB sockets.
3. Attackers do not “hack in” the way films show. They find one place where your assumption about input was wrong.
4. The pattern is nearly always the same. A program expected data and received instructions, or expected a small thing and received a big one.
5. There is a second, equally common pattern: the program did the right check on the wrong thing, or forgot the check on one path out of twenty.
6. Attacks chain. A low-value flaw plus another low-value flaw often equals a total compromise.
7. Example of a chain: a public page leaks internal server names, one of those servers has an old unpatched service, that service runs as administrator, and administrator can read the database credentials.
8. No single link in that chain was catastrophic. The chain was.
9. Defenders therefore think in layers, not in walls. If one control fails, the next one should still be standing. That is called defence in depth.
10. And defenders think about blast radius: when this component is fully compromised, what exactly can the attacker now reach?
11. Reducing blast radius is usually cheaper and more reliable than trying to make a component unbreakable.

The honest version: “attackers exploit vulnerabilities” is only half true. In real incident data, most intrusions begin with valid credentials or a person being tricked, not with a clever technical exploit. The technical exploit usually comes later, to move sideways once inside.

TECHNICAL44.1.5 the engineer’s version#

1. The five properties are formalized in ISO/IEC 27000 and in NIST SP 800-53. Confidentiality, integrity and availability are the statutory triad in United States federal law under FISMA 2002.
2. Authenticity and non-repudiation are usually added as separate objectives; the combined five are sometimes called the Parkerian hexad when utility and possession are added as well, following Donn Parker’s 1998 formulation.
3. Threat modelling has named methodologies. STRIDE, created at Microsoft by Loren Kohnfelder and Praerit Garg in 1999, enumerates Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege.
4. PASTA (Process for Attack Simulation and Threat Analysis, 2012) and LINDDUN for privacy threats are the other two commonly taught.
5. Attacks are catalogued by MITRE ATT&CK, first published in 2013 and updated continuously. It maps real observed adversary behaviour into tactics and techniques with identifiers such as T1566 for phishing.
6. Vulnerabilities get CVE identifiers, run by MITRE since 1999. Severity is scored by CVSS, currently version 4.0, published by FIRST in November 2023.
7. Weakness classes get CWE identifiers. CWE-79 is cross-site scripting, CWE-89 is SQL injection, CWE-787 is out-of-bounds write.
8. Note the difference precisely: a CWE is a kind of mistake, a CVE is one specific instance of it in one specific product version.
9. Risk in formal work is expressed as annualized loss expectancy: ALE = single loss expectancy x annual rate of occurrence. In practice the inputs are estimates, so the number is used for ranking, not for accounting.
10. FAIR (Factor Analysis of Information Risk) is the main quantitative alternative and expresses risk as probability distributions rather than single numbers.

11. Tools that observe security posture on a machine you own: nmap for open ports, ss -tlnp on Linux or lsof -i -P on macOS for listening sockets, osqueryd for fleet-wide state, and lynis for host audit.
12. The word “secure” without a threat model attached is meaningless. Always ask: secure against whom, doing what, at what cost to them?

WORDS44.1.6 remember these#

Confidentiality — only the right people can read it — protection of data from unauthorized disclosure.

Integrity — nobody changed it secretly — assurance that data has not been modified in an unauthorized or undetected way.

Availability — it works when you need it — the property of being accessible and usable on demand by an authorized entity.

Authenticity — you are who you claim — verified identity of a principal or origin of data.

Non-repudiation — you cannot deny you did it — cryptographic proof binding an action to an identity, resistant to later denial.

Threat model — who might attack and how — structured enumeration of assets, adversaries, entry points and mitigations.

Attack surface — every way in — the complete set of points where an untrusted actor can supply input or influence behaviour.

Blast radius — how far damage spreads — the set of assets reachable after a given component is fully compromised.

Risk — likelihood times impact — expected loss, used to rank work rather than to predict exact outcomes.

44.2 Hashing#

PLAIN44.2.1 in simple words#

1. A hash function takes any amount of data and produces a short, fixed-length fingerprint.
2. Feed it one letter or a two-gigabyte film. The fingerprint is the same length every time.
3. It is a one-way street. From the data you can compute the fingerprint easily. From the fingerprint you cannot get the data back.
4. Change one single bit of the input and about half the bits of the output change, in an unpredictable way.
5. That effect has a name: the avalanche effect.
6. The same input always gives the same output, on any machine, forever. It is not random.
7. Four properties matter, and they are worth learning in order.
8. One: it is fast to compute forwards.
9. Two: preimage resistance. Given a fingerprint, you cannot find any input that produces it.
10. Three: second preimage resistance. Given one file, you cannot find a different file with the same fingerprint.
11. Four: collision resistance. You cannot find any two different files with the same fingerprint, even if you get to choose both.
12. Collision resistance is the hardest of the four, and it is always the first one to fall when a hash function is broken.
13. A hash is good for checking that something did not change. A hash by itself is not a secret and not encryption. It hides nothing you can guess.

PLAIN44.2.2 a picture in your head#

1. Imagine a machine that turns any book into a six-word summary.
2. The summary is always six words, whether the book is a pamphlet or a thousand pages.
3. From the six words nobody can reconstruct the book.
4. Change one comma in the book and the six words come out completely different, not slightly different.
5. So if a friend tells you the six words over the phone, you can check that the copy of the book you received is exactly the one they sent.
6. That is what people do when they publish a checksum next to a download.
7. A collision is two genuinely different books producing the same six words. If that ever happens, the summary can no longer prove anything.

Where this comparison breaks: a six-word summary of a book is related to the book’s meaning. A cryptographic hash is deliberately not. Two files that differ by a single byte give summaries with no visible relationship at all, and that unpredictability is the entire point. Also, a real hash has a fixed tiny output while the input is unlimited, so collisions must mathematically exist. The claim is only that nobody can find one.

PLAIN44.2.3 a worked example#

1. Here are real hashes, computed in the sandbox used to write this chapter, with OpenSSL 3.0.13.
2. The input is the seven characters kedbyte, with no newline.

md5      31d826fc69ac61899d792d7c21411dd5
sha1     ea431b1d4e594752169a04adea3245395d4ea7eb
sha256   7e88ddebb634ffbb28b3037dd122c08cf849ce53bd
         f3a8d0a08e13ac5b0eab3f
sha3-256 72c5e9c053ffabec027977d730987430dc98f9b553
         ac1aa248bc683385b532b1
blake2s  03b9df1f134bdbf34740d2353323dd58f48360c23c
         3af7b393fda6e52c6c14af

3. Note the lengths. MD5 is 32 hex characters, which is 128 bits. SHA-1 is 40 characters, 160 bits. SHA-256 is 64 characters, 256 bits.
4. Now change the last letter only, from kedbyte to kedbytf, and hash again with SHA-256.

kedbyte -> 7e88ddebb634ffbb28b3037dd122c08c...
kedbytf -> 718433d73cc98a937bdfce4a6c2e4d90...

5. Counted properly, 123 of the 256 output bits differ. The ideal is 128, which is exactly half. That is the avalanche effect measured.
6. SHA-256 of the empty input is a constant worth recognizing, because it turns up in logs and in Git internals: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
7. On the machine used here, openssl speed sha256 measured 400 megabytes per second on 8 kilobyte blocks, on one core.
8. That speed is wonderful for verifying downloads and terrible for storing passwords, which is the subject of the next section.

PLAIN44.2.4 what is really happening inside#

1. Most classic hash functions work by chewing the input in fixed-size blocks.
2. SHA-256 uses 512-bit blocks. It keeps eight 32-bit working values, called the state, that start from fixed constants.
3. For each block it runs 64 rounds of mixing: rotations, exclusive-or, additions and a few nonlinear choices between bits.
4. After each block, the mixed values are added back into the state. That step is what makes the process irreversible.
5. At the end, the eight state values are written out as the digest.
6. The padding rule matters. The message gets a single 1 bit, then zeros, then the original length in bits. Without the length, different messages could collide trivially.
7. This design is called Merkle-Damgard, after Ralph Merkle and Ivan Damgard, both 1979 to 1989 era work.
8. It has a known quirk called length extension: if you know the hash of a secret message and its length, you can compute the hash of that message with extra data appended, without knowing the secret.
9. That quirk is exactly why you must never authenticate a message by hashing a secret joined to the message. You use HMAC instead, which is built to resist it.
10. SHA-3 has a completely different internal shape called a sponge. It absorbs input into a large 1600-bit state and squeezes output back out, and it is immune to length extension by design.
11. BLAKE3 goes further and splits the input into 1 kilobyte chunks arranged in a tree, so many cores can hash different chunks at the same time.
12. When a hash is “broken”, it almost never means someone can reverse it. It means someone found a shortcut to produce collisions faster than brute force. That is still fatal for signatures and certificates.

TECHNICAL44.2.5 the engineer’s version#

1. MD5 was published by Ron Rivest in 1992 as RFC 1321, output 128 bits.
2. Practical MD5 collisions were announced by Wang Xiaoyun, Feng Dengguo, Lai Xuejia and Yu Hongbo at the CRYPTO 2004 rump session in August 2004.
3. By 2008 a research team used chosen-prefix MD5 collisions to forge a working certificate authority certificate. In 2012 the Flame malware used the same class of attack to forge a Microsoft code-signing certificate.
4. SHA-1 was published by NIST in 1995, output 160 bits. Theoretical attacks appeared in 2005, also from Wang’s group.
5. The first public SHA-1 collision, named SHAttered, was announced on 23 February 2017 by CWI Amsterdam and Google. It cost roughly nine quintillion SHA-1 computations, about 6,500 CPU-years and 110 GPU-years.
6. In 2020 Gaetan Leurent and Thomas Peyrin demonstrated a chosen-prefix SHA-1 collision for a rented compute cost in the tens of thousands of dollars.
7. SHA-2 is a family standardized in FIPS 180-4: SHA-224, SHA-256, SHA-384, SHA-512, and the truncated SHA-512/224 and SHA-512/256. No practical break exists as of 2026.
8. SHA-3 is Keccak, by Guido Bertoni, Joan Daemen, Michael Peeters and Gilles Van Assche. It won the NIST competition in October 2012 and was published as FIPS 202 in August 2015. It is a complement to SHA-2, not a replacement.
9. BLAKE3 was released in January 2020 by Jack O’Connor, Jean-Philippe Aumasson, Samuel Neves and Zooko Wilcox-O’Hearn. It is not a NIST standard.
10. Security levels, stated honestly. A hash with n bits of output gives about n bits against preimage attacks and only n/2 bits against collisions, by the birthday bound. SHA-256 therefore offers 128-bit collision resistance.

11. Where each is still acceptable: MD5 and SHA-1 only for non-security uses such as cache keys and non-adversarial deduplication. Never for signatures, certificates, integrity against an attacker, or passwords.
12. Git historically used SHA-1 for object names and has a SHA-256 object format available since Git 2.29 in 2020, still not the default in 2026. Git also ships a hardened SHA-1 that detects the SHAttered attack pattern.
13. Commands to observe: sha256sum file and md5sum file on Linux, shasum -a 256 file on macOS, openssl dgst -sha256 file anywhere, certutil -hashfile file SHA256 on Windows.
14. For message authentication use HMAC (RFC 2104, 1997), for example HMAC-SHA-256, or use a modern AEAD cipher which includes authentication.

WORDS44.2.6 remember these#

Hash function — a fingerprint machine — a deterministic map from arbitrary input to fixed-length output.

Digest — the fingerprint itself — the output value of a hash function.

Collision — two inputs, one fingerprint — two distinct messages producing the same digest.

Preimage resistance — cannot work backwards — infeasibility of finding any input matching a given digest.

Avalanche effect — one bit in, half the bits out — small input change causes statistically independent output.

Length extension — appending without the secret — a Merkle-Damgard weakness allowing extension of a hashed message.

HMAC — a hash with a key done properly — keyed message authentication code defined in RFC 2104.

Checksum — a change detector — a short value used to detect accidental corruption, not necessarily cryptographic.

44.3 Password storage done properly#

PLAIN44.3.1 in simple words#

1. If you build a login system, you must store something that lets you check a password without storing the password.
2. Storing the password itself, readable, is the worst possible choice. One database leak and every user is exposed everywhere they reused it.
3. So we store a hash instead. The user types a password, we hash it, we compare hashes. We never need the original.
4. But a plain fast hash is almost as bad, and here is why.
5. An attacker who steals the database can guess billions of passwords per second on one graphics card and hash each guess.
6. Worse, if everyone’s password is hashed the same way, the attacker can precompute a giant table once and reuse it against every stolen database.
7. Those precomputed tables are called rainbow tables.
8. The fix for that is a salt: a random value, different for every user, mixed in before hashing and stored alongside the hash.
9. Two users with the same password now get completely different stored values, so a precomputed table is useless and every user must be attacked separately.
10. A salt is not a secret. It is stored in the database in plain view. Its job is uniqueness, not secrecy.
11. Then there is a second idea: a pepper, a single secret value added for everyone, stored somewhere other than the database.
12. If the attacker steals only the database, the pepper is missing and the guessing cannot even start.
13. And the last idea is the important one: make the hash deliberately slow and memory-hungry.
14. If checking one password takes a quarter of a second and a lot of memory, a legitimate login is unaffected and mass guessing becomes uneconomic.

PLAIN44.3.2 a picture in your head#

1. Think of a hotel that must check whether you know the door code, without keeping a list of door codes.
2. Fast hash: the clerk has a machine that instantly turns a code into a coloured token, and keeps only the tokens. A thief who steals the tokens buys the same machine and tries every code in an afternoon.
3. Salt: each guest’s code is combined with a printed sticker number unique to that guest before the machine runs. The thief must now redo the whole afternoon separately for each guest.
4. Pepper: the machine also needs a small key that the manager keeps at home. Stealing the tokens gets you nowhere without visiting the manager.
5. Slow hash: the machine takes a quarter of a second per attempt and needs a whole desk covered in paper to work. One guest checking in does not care. A thief trying a billion codes now needs a warehouse and years.

Where this comparison breaks: the hotel thief cannot buy a hundred thousand machines. A password attacker can rent that many in a cloud for an hour. The slow hash is not making attack impossible; it is changing the price. Price is the real currency of security, and it is a moving target because hardware gets faster. Parameters chosen in 2015 are too weak in 2026.

PLAIN44.3.3 a worked example#

1. Real timings, measured in the sandbox for this chapter, single core.

2. Read the first row again. A raw SHA-256 took 740 nanoseconds. That is roughly 1.3 million guesses per second on one Python core.
3. On a graphics card the numbers are far worse for the defender. Published hashcat benchmarks on an NVIDIA RTX 5090 report about 220 billion MD5 hashes per second and about 28 billion SHA-256 hashes per second.
4. The same card manages only about 300,000 bcrypt hashes per second at a low work factor. That is roughly a hundred thousand times slower per guess.
5. That single ratio is the entire argument for slow password hashing.
6. Now watch the salt work. The same password, PBKDF2-HMAC-SHA256 with 600,000 iterations, with two different salts.

salt 00000000... -> 0460eeec7ddf8b5f91f2037b3e2ab248
salt a3f10000... -> 52e0053a9dda9d910cb58befaafe9e67

7. Same password, unrelated results. No shared precomputation is possible.
8. A stored record in practice looks like this. It is one string containing the algorithm, its parameters, the salt and the hash, so you can change parameters later without breaking old accounts.

$argon2id$v=19$m=19456,t=2,p=1$c29tZXNhbHQ$aG...
 |        |    |                |          |
 algo     ver  parameters       salt       hash

9. The parameters live inside the record on purpose. When you raise them next year, old users still verify with the old settings, and you re-hash their password at their next successful login.

PLAIN44.3.4 what is really happening inside#

1. On registration: generate a fresh random salt of at least 16 bytes from a cryptographic random source, run the slow hash, store algorithm, parameters, salt and result.
2. On login: read the stored record, take the salt and parameters out of it, hash the submitted password the same way, compare.
3. Compare in constant time. A comparison that stops at the first different byte leaks information through timing. Every good library has a constant-time compare function.
4. Never tell the user which part was wrong. “Wrong username or password” and nothing more, or you have built an account enumeration tool.
5. The slow hash resists attack in three different ways, and they are not the same thing.
6. Time hardness: many sequential iterations, so you cannot go faster than the chain allows.
7. Memory hardness: the algorithm needs a large block of memory that must stay filled during the computation. Graphics cards have thousands of small cores but limited memory per core, so memory cost hurts attackers far more than defenders.
8. Parallelism resistance: the memory accesses depend on earlier results, so the work cannot simply be split.
9. bcrypt has time hardness and a small fixed 4 kilobyte memory need. scrypt and Argon2 add real memory hardness.
10. The pepper is applied differently in good designs: not concatenated into the password, but used as an HMAC key over the password before hashing, or used to encrypt the resulting hash. Both keep it separable and rotatable.
11. Where does the pepper live? A hardware security module, a cloud key management service, or at minimum an environment variable on the application server that is not in the database backup.

The honest version: the pepper only helps in the specific case where the database leaks but the application server does not. That case is common, from SQL injection and stolen backups, so peppering is worth doing. But it is a second line, not a substitute for a proper slow hash.

TECHNICAL44.3.5 the engineer’s version#

1. bcrypt: Niels Provos and David Mazieres, USENIX 1999, based on the Blowfish key schedule. Cost parameter is a power of two. OWASP recommends a work factor of at least 10 as of the current Password Storage Cheat Sheet.
2. bcrypt truncates input at 72 bytes. Enforce a 72-byte maximum, or pre-hash with SHA-256 and base64 the result before feeding bcrypt, being careful about null bytes.
3. scrypt: Colin Percival, 2009, standardized as RFC 7914 in 2016. Parameters N (cost), r (block size), p (parallelism).
4. Argon2: winner of the Password Hashing Competition in July 2015, by Alex Biryukov, Daniel Dinu and Dmitry Khovratovich. Standardized as RFC 9106 in September 2021. Three variants: Argon2d, Argon2i, and Argon2id.
5. Use Argon2id. It is the hybrid: data-independent memory access in the first pass to resist side-channel attacks, data-dependent afterwards to resist time-memory trade-offs.
6. Current OWASP recommended parameters, any one of which is acceptable and equivalent in strength.

7. PBKDF2 is the fallback where FIPS validation is required. OWASP currently lists 600,000 iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512. PBKDF2 is defined in RFC 8018.
8. Salt: 16 bytes minimum from a CSPRNG. Every modern library generates and embeds it for you. Do not hand-roll this.
9. Attack taxonomy, defensively stated. A dictionary attack tries a wordlist plus rules such as appending digits. A brute force tries all combinations, feasible only for short passwords. Credential stuffing replays username and password pairs stolen from another site.
10. Credential stuffing is the dominant real attack because password reuse is near universal. The attacker does not need to break your hashes at all if the user used the same password somewhere weaker.
11. That is the actual disaster of reuse: your security becomes equal to the security of the worst site the user ever signed up for.
12. Defences against stuffing: rate limiting per account and per network, device fingerprinting, checking submitted passwords against known-breached lists using a k-anonymity range API, and above all offering MFA.
13. NIST SP 800-63B revision 4, published 31 July 2025, is the current authority. Its key rules for verifiers: require at least 8 characters and encourage at least 15; allow at least 64; allow all printable characters including spaces and Unicode.
14. The same document says verifiers shall not impose composition rules such as requiring mixed character types, and shall not require periodic password rotation without evidence of compromise.
15. The reasoning is empirical, not aesthetic. Forced rotation causes predictable transformations such as incrementing a trailing digit, and composition rules push users toward the same small set of substitutions.
16. Practical advice to give a user: use a password manager, generate long random passwords per site, and use a long passphrase only for the few secrets you must type from memory, such as the manager’s own master password and the disk encryption password.
17. Length beats complexity. A five-word random passphrase from a large word list carries roughly 64 bits of entropy; an eight-character password with the usual substitutions carries far less in practice.

WORDS44.3.6 remember these#

Salt — a unique random extra per user — public per-record value preventing precomputation and hash reuse.

Pepper — one secret extra for everyone — site-wide secret kept outside the password database, applied via HMAC or encryption.

Rainbow table — a precomputed cracking table — time-memory trade-off structure for reversing unsalted hashes.

Work factor — the slowness dial — a tunable cost parameter of a password hashing function.

Memory hardness — needs a lot of RAM to compute — property that raises the cost of parallel hardware attacks.

Credential stuffing — reusing stolen logins elsewhere — automated replay of breached username and password pairs.

Argon2id — the current recommended choice — hybrid memory-hard password hash, RFC 9106, winner of the 2015 Password Hashing Competition.

Account enumeration — learning which users exist — information leak from differing error messages or response times.

44.4 Symmetric encryption#

PLAIN44.4.1 in simple words#

1. Symmetric encryption means both sides share one secret key. The same key locks and unlocks.
2. It is fast, which is why every real system uses it for the actual data.
3. There are two shapes of symmetric cipher.
4. A block cipher transforms a fixed-size chunk at a time, typically 16 bytes, and you must decide how to handle a message longer than one chunk.
5. A stream cipher produces an endless keystream of pseudo-random bytes which you combine with the message one byte at a time.
6. The dominant block cipher is AES, with key sizes of 128, 192 or 256 bits. Its block is always 128 bits regardless of key size.
7. The way you chain blocks together is called a mode of operation, and choosing it wrongly is the most common cryptographic mistake in the world.
8. The worst mode is ECB, which encrypts every block independently. Identical input blocks give identical output blocks, so the shape of your data leaks straight through.
9. Modern practice is not to choose a cipher and a mode separately. You choose an authenticated encryption scheme that also detects tampering.
10. Encryption without authentication is not enough. An attacker who cannot read your message can still flip bits in it and change what it says when decrypted.
11. Almost every cipher mode also needs a per-message unique value called an IV or a nonce. Reusing one with the same key is catastrophic.

PLAIN44.4.2 a picture in your head#

1. Think of a stencil-based code where each 16-letter chunk of your message is replaced by a scrambled 16-letter chunk, using a fixed rule set by the key.
2. ECB mode is applying that stencil to each chunk independently.
3. Now imagine a photograph converted this way. Every patch of plain white sky becomes the same scrambled patch. The scrambled version still shows the outline of the picture.
4. That is why the encrypted penguin image is famous in every cryptography course. The bird is still clearly visible after ECB encryption.
5. CBC mode fixes it by mixing each chunk with the previous encrypted chunk before scrambling, so identical inputs stop looking identical.
6. CTR mode does something different: it does not encrypt your data at all. It encrypts a counter to make a keystream, then combines that with your data.
7. GCM is CTR plus a running checksum computed with the key, so any change to the ciphertext is detected on decryption.

Where this comparison breaks: real block ciphers are not letter substitution. AES mixes bits across the whole block through several layers, so one changed input bit changes the whole output block. The stencil picture also suggests the key changes the alphabet, when in reality the key changes a schedule of operations applied over many rounds.

PLAIN44.4.3 a worked example#

1. Here is ECB failing, computed in the sandbox for this chapter with a real AES-128 key.
2. The plaintext is YES YES YES YES YES YES YES YES, which is exactly two identical 16-byte blocks.

AES-ECB block 1: 15516924691d0a3e5f81ff297ad6c86e
AES-ECB block 2: 15516924691d0a3e5f81ff297ad6c86e
identical: True

AES-CBC block 1: 15516924691d0a3e5f81ff297ad6c86e
AES-CBC block 2: 234d8347677995c4547c148bbfa58f4f
identical: False

3. Look at the ECB output. The repetition in the plaintext is visible in the ciphertext with no key and no effort at all.
4. CBC produced different blocks for identical input because each block was mixed with the previous ciphertext block first.
5. Now the nonce reuse problem, stated without giving an attack recipe.
6. In CTR and GCM, the ciphertext is the plaintext combined with a keystream derived from key and nonce.
7. Encrypt two different messages with the same key and the same nonce, and both use the identical keystream.
8. Combining the two ciphertexts cancels the keystream out entirely, leaving a direct relationship between the two plaintexts.
9. For GCM specifically, nonce reuse does something worse: it leaks the authentication subkey, which lets an attacker forge messages that your system will accept as genuine.
10. The rule that follows is absolute. Never reuse a nonce with the same key. Generate it randomly with enough bits, or use a strict counter you can prove never repeats.

PLAIN44.4.4 what is really happening inside#

1. AES works on a 4 by 4 grid of bytes called the state.
2. Each round does four steps: substitute every byte through a fixed lookup table, shift the rows sideways by different amounts, mix each column mathematically, and add the round key with exclusive-or.
3. AES-128 does 10 rounds, AES-192 does 12, AES-256 does 14.
4. The key schedule expands the single key into one distinct round key per round, so no two rounds are the same.
5. The substitution table is the only nonlinear step. Without it the whole cipher would collapse into simple algebra and be trivially breakable.
6. In CBC mode, encryption is a chain: block n is combined with ciphertext n-1 before encryption, and the first block uses the IV. Chains cannot be parallelized when encrypting, though decryption can be.
7. In CTR mode, block n of the keystream is the encryption of nonce plus n. No chain, so everything parallelizes and you can decrypt from the middle.
8. GCM adds GHASH, a multiplication in a finite field over the ciphertext and any associated data, producing a 16-byte authentication tag.
9. On decryption, GCM computes the tag again and compares. If it does not match, it returns an error and no plaintext. That refusal is the whole value of authenticated encryption.
10. ChaCha20 is a different design: 20 rounds of additions, rotations and exclusive-ors on a 4 by 4 grid of 32-bit words, producing 64 bytes of keystream per invocation.
11. It uses no lookup tables, so it has no cache-timing side channel and it is fast in plain software on processors without AES hardware instructions.
12. Poly1305 is its companion authenticator, a one-time message authentication code using arithmetic modulo a large prime.

TECHNICAL44.4.5 the engineer’s version#

1. AES is Rijndael, by Joan Daemen and Vincent Rijmen. It won the NIST competition in October 2000 and was published as FIPS 197 in November 2001.
2. Modern processors have hardware support: Intel AES-NI since Westmere in 2010, ARMv8 cryptographic extensions since 2011. Throughput on a single modern core is commonly several gigabytes per second.
3. Mode summary, with the practical verdict for 2026.

4. AES-GCM is specified in NIST SP 800-38D (2007). Its nonce is 96 bits by convention, and the standard limits a single key to about 2^32 random nonces before collision risk becomes unacceptable.
5. AES-GCM-SIV, RFC 8452 (2019), is nonce-misuse resistant: repeating a nonce leaks only whether two plaintexts were equal, not the keystream. Use it when you cannot guarantee nonce uniqueness.
6. ChaCha20-Poly1305 is RFC 8439 (2018), by Daniel J. Bernstein. It is a TLS 1.3 mandatory-to-implement suite alongside AES-GCM and is preferred on mobile processors without AES acceleration.
7. XChaCha20-Poly1305 extends the nonce to 192 bits, making random nonce generation safe without counters.
8. CBC without authentication enabled the padding oracle class of attacks, including the 2002 Vaudenay result and the 2010 attacks on ASP.NET. That history is why encrypt-then-MAC or AEAD is mandatory now, not optional.
9. Key sizes in practice: AES-128 gives 128-bit classical security and is fine. AES-256 is chosen for long-term data and for regulatory reasons, and is the sensible default against future quantum search attacks.
10. Grover’s algorithm, published by Lov Grover in 1996, would give a quantum computer a square-root speed-up on key search, notionally halving AES-256 to 128 bits of effective strength. Doubling the key size answers it.
11. Never write your own mode, your own padding, or your own comparison of authentication tags. Use libsodium, the Go crypto/cipher AEAD interface, Java’s javax.crypto with GCM, or Python cryptography’s AESGCM class.
12. Commands to observe: openssl enc -aes-256-cbc for files, openssl speed -evp aes-256-gcm for throughput, cryptsetup benchmark on Linux for disk encryption performance including AES-XTS.
13. Disk encryption uses XTS mode rather than GCM, because a disk sector has no room to store an authentication tag. That is a real trade-off: disk encryption protects confidentiality, not integrity.

WORDS44.4.6 remember these#

Symmetric encryption — one shared key both ways — encryption where the same key encrypts and decrypts.

Block cipher — scrambles fixed chunks — a keyed permutation over a fixed block size, 128 bits for AES.

Mode of operation — how chunks are chained — the construction turning a block cipher into a scheme for arbitrary-length messages.

ECB — the mode that leaks patterns — Electronic Codebook, encrypts each block independently, never acceptable.

IV / nonce — the per-message unique value — initialization vector or number used once, must never repeat under one key.

AEAD — encryption that also detects tampering — Authenticated Encryption with Associated Data, for example AES-GCM.

Authentication tag — the tamper seal — short value verified on decryption, causing refusal if the ciphertext changed.

ChaCha20-Poly1305 — the software-fast alternative — stream cipher plus one-time authenticator, RFC 8439.

44.5 Asymmetric encryption, signatures and the quantum question#

PLAIN44.5.1 in simple words#

1. Symmetric encryption has one hard problem: how do two strangers agree on a shared key over a network anyone can read?
2. Asymmetric encryption solves it with a pair of matched keys.
3. The public key can be published to the whole world. The private key never leaves its owner.
4. Anything encrypted with the public key can only be decrypted with the private key.
5. That direction gives you confidentiality: anyone can write to you, only you can read it.
6. Run it the other way and you get something different and equally useful.
7. If you transform a message with your private key, anyone with your public key can check it. That is a digital signature.
8. A signature proves three things at once: the message came from the holder of that private key, it has not been altered, and the signer cannot plausibly deny it later.
9. Encryption alone proves none of those. Anyone with your public key can encrypt to you, so a decrypted message tells you nothing about who sent it.
10. There is also a way to agree a shared secret without either side sending it: Diffie-Hellman key exchange.
11. Asymmetric operations are slow, hundreds to thousands of times slower than symmetric ones.
12. So every real system is hybrid: use asymmetric maths once to agree a symmetric key, then use the fast symmetric cipher for all the data.
13. That is exactly what TLS does, which Chapter 32 covered in detail.

PLAIN44.5.2 a picture in your head#

1. Picture an open padlock that you hand out freely, of which you alone keep the key.
2. Anyone can put a letter in a box, snap your padlock shut, and post it. Only you can open it.
3. Signing is the mirror image: you press a seal that only your ring can make, and anyone with a picture of your seal can confirm it is genuine.
4. Diffie-Hellman is a different trick. Two people each mix a private colour into a shared public colour, swap the mixtures in the open, then each mix their own private colour into the mixture they received.
5. Both end with the same final colour. An observer saw the two mixtures but cannot unmix them to reach it.

Where this comparison breaks: paint mixing is only a metaphor for a one-way mathematical operation. Real Diffie-Hellman uses exponentiation in a group where reversing it is the discrete logarithm problem. Also, a physical padlock protects against a person with a hacksaw, while a cryptographic one protects only against computation, and computation gets cheaper every year.

PLAIN44.5.3 a worked example#

1. RSA rests on multiplication being easy and factoring being hard.
2. Multiplying two 1024-bit primes takes microseconds. Recovering those primes from the 2048-bit product is beyond any known machine.
3. The largest RSA modulus ever publicly factored is RSA-250, a 829-bit number, broken in February 2020 using about 2,700 core-years.
4. That is why 2048-bit RSA keys are still standard and 1024-bit ones were deprecated by browsers around 2013 to 2014.
5. Elliptic curves get the same strength from much smaller numbers.

6. Read the last row. To match a 512-bit curve you would need a 15,360-bit RSA key. That is why modern systems moved to curves.
7. Curve25519, published by Daniel J. Bernstein in 2005, gives roughly 128-bit security with 32-byte keys and is the default in SSH, Signal and TLS 1.3.
8. Its signature counterpart is Ed25519, standardized in RFC 8032 in 2017, with 64-byte signatures.
9. A sense of the speed gap: on a typical modern core, an X25519 key agreement takes tens of microseconds while an AES-GCM operation on a kilobyte takes well under one microsecond. Hence the hybrid design.

PLAIN44.5.4 what is really happening inside#

1. RSA key generation: pick two large random primes p and q, multiply to get the modulus n, choose a public exponent e, usually 65537, and compute the matching private exponent d.
2. Encryption raises the message to the power e modulo n. Decryption raises the result to the power d modulo n. The maths brings you back to the start.
3. Raw RSA is unsafe. Real use requires padding: OAEP for encryption, PSS for signatures. The old PKCS#1 v1.5 padding produced the Bleichenbacher attack family from 1998 onwards and its many modern echoes.
4. Signing does not actually sign the message. It hashes the message first, then signs the hash. That is why a broken hash breaks signatures, which is what SHA-1 collisions meant for certificates.
5. Elliptic curve cryptography replaces “multiply numbers” with “add points on a curve”. The private key is a number, the public key is a point reached by adding a fixed base point to itself that many times.
6. Going forwards is fast; recovering the number from the point is the elliptic curve discrete logarithm problem, and no efficient classical method is known.
7. Diffie-Hellman in curve form is simple: each side multiplies the other’s public point by their own private number, and both land on the same point.
8. Forward secrecy comes from throwing the Diffie-Hellman private values away after the session. An attacker who later steals the long-term key still cannot decrypt yesterday’s recorded traffic.
9. Now the quantum part. Peter Shor published an algorithm in 1994 that, on a sufficiently large fault-tolerant quantum computer, factors integers and computes discrete logarithms in polynomial time.
10. That breaks RSA, finite-field Diffie-Hellman and every elliptic curve scheme at once. It does not break symmetric ciphers or hashes in the same way; those need only larger sizes.
11. No such machine exists in 2026. Published estimates for breaking 2048-bit RSA remain in the range of millions of physical qubits with error correction, against current devices measured in the low thousands.
12. But traffic recorded today can be stored and decrypted later. That is harvest now, decrypt later, and it makes migration urgent for any data that must stay secret for ten or twenty years.

TECHNICAL44.5.5 the engineer’s version#

1. Diffie-Hellman was published by Whitfield Diffie and Martin Hellman in 1976 in “New Directions in Cryptography”. Ralph Merkle’s related work preceded it. RSA followed in 1977 from Ron Rivest, Adi Shamir and Leonard Adleman.
2. Elliptic curve cryptography was proposed independently by Neal Koblitz and Victor Miller in 1985.
3. British researchers at GCHQ, James Ellis, Clifford Cocks and Malcolm Williamson, developed equivalent ideas between 1969 and 1974; the work was classified until 1997.
4. NIST approved three post-quantum standards on 13 August 2024.

5. ML-KEM was submitted as CRYSTALS-Kyber, ML-DSA as CRYSTALS-Dilithium, SLH-DSA as SPHINCS+. The initial announcement was 6 August 2024 and the Secretary of Commerce approved them on 13 August 2024.
6. A fourth signature scheme, FN-DSA, based on FALCON, was still in draft as FIPS 206 as of 2026. On 11 March 2025 NIST selected HQC as a fifth algorithm and a backup key encapsulation mechanism, with its own standard expected around 2027.
7. Sizes are the practical cost. ML-KEM-768 has a 1,184-byte encapsulation key and a 1,088-byte ciphertext, against 32 bytes each for X25519.
8. ML-DSA-65 signatures are about 3,309 bytes and SLH-DSA signatures range from roughly 7,856 bytes to about 49,856 bytes, against 64 bytes for Ed25519. That is why signature migration lags key exchange migration.
9. SLH-DSA exists as insurance. It relies only on hash function security, so if lattice mathematics turns out to have an unexpected weakness, hash-based signatures still stand.
10. Deployment state as of 2026, separating fact from claim. Established fact: the hybrid key agreement X25519MLKEM768 is on by default in current Chrome, Firefox and Edge. Cloudflare reported in late October 2025 that over half of human-initiated traffic to its network used post-quantum key agreement.
11. Also established: signatures and certificates have barely moved, because they need certificate authorities, root programmes and every client to change together.
12. Active research: how to shrink post-quantum certificate chains, and how to do post-quantum authentication for constrained devices.
13. Marketing claim: any product described as “quantum-proof” or “unbreakable” without naming FIPS 203, 204 or 205. Ask which standard, which parameter set, and whether it is hybridized with a classical algorithm.
14. Hybrid is the current professional consensus: run the classical and the post-quantum algorithm together, so a break in either alone is not fatal. Experts disagree on how long to keep hybrids. Some say they add complexity and should be retired soon; others argue for a decade.
15. Commands to observe: openssl s_client -connect host:443 and read the negotiated group, openssl list -kem-algorithms on OpenSSL 3.5 and later, and ssh -Q kex to list key exchange algorithms your SSH build supports.

WORDS44.5.6 remember these#

Public key — the half you publish — the shareable component of an asymmetric key pair.

Private key — the half you never share — the secret component whose exposure destroys the pair’s security.

Digital signature — proof of who and unaltered — a value verifiable with a public key, providing authenticity and non-repudiation.

Key exchange — agreeing a secret in the open — a protocol producing a shared secret without transmitting it, such as ECDH.

Forward secrecy — yesterday stays safe — property where compromise of long-term keys does not expose past sessions.

Hybrid encryption — asymmetric once, symmetric after — the standard construction combining key agreement with an AEAD cipher.

Shor’s algorithm — the quantum threat to RSA — polynomial-time quantum factoring and discrete logarithm, published 1994.

ML-KEM — the new key exchange standard — FIPS 203, lattice-based key encapsulation, approved 13 August 2024.

Harvest now, decrypt later — record today, break tomorrow — the threat model justifying migration before quantum computers exist.

44.6 Authentication and identity#

PLAIN44.6.1 in simple words#

1. Authentication answers one question: are you who you claim to be?
2. There are three classic kinds of evidence, called factors.
3. Something you know: a password, a PIN, an answer to a question.
4. Something you have: a phone, a hardware key, a smart card.
5. Something you are: a fingerprint, a face, a voice.
6. Multi-factor authentication means using evidence from two different kinds, not two things of the same kind.
7. A password plus a security question is not two factors. Both are things you know, and both leak in the same database breach.
8. Not all second factors are equally strong, and the gap between them is much wider than most people think.
9. A six-digit code from an app is decent. A code sent by text message is weak. A hardware key is in a different class entirely.
10. The reason hardware keys are different is that they refuse to be phished. The others can all be relayed by an attacker in real time.
11. A passkey is that same phishing-resistant technology, with the secret stored on your phone or laptop and unlocked by your fingerprint or face.

PLAIN44.6.2 a picture in your head#

1. Think of collecting a parcel from a counter.
2. The password is knowing the reference number. Anyone who overhears it can collect your parcel.
3. The app code is a slip of paper that changes every thirty seconds. Better, but if someone phones you and talks you into reading it out within those thirty seconds, they can still collect the parcel.
4. The hardware key is different in kind. It is a stamp that only works on that one counter, in that one building.
5. Take the stamp to a fake counter in the next street and it produces nothing, because it checks the address of the counter before stamping.
6. That address check is why phishing fails against it. The user can be fully fooled and the attack still does not work.

Where this comparison breaks: a stamp can be stolen physically. A hardware key can too, which is why it usually also requires a PIN or a fingerprint. And the key does not check a street address but the exact web origin, which the browser supplies and the user cannot override by being persuaded.

PLAIN44.6.3 a worked example#

1. Here is how the six-digit code in your authenticator app is actually made.
2. When you scan the QR code, the site gives your app a shared secret, usually 20 bytes, encoded in base32.
3. Both sides take the current Unix time in seconds and divide by 30, throwing away the remainder. That gives a counter that changes every 30 seconds.
4. Both compute HMAC-SHA-1 of that counter using the shared secret.
5. That produces 20 bytes. A truncation step picks 4 bytes from a position determined by the last nibble of the hash, giving a 31-bit number.
6. Take that number modulo 1,000,000 and pad to six digits. That is your code.

secret + floor(unixtime / 30)
   -> HMAC-SHA-1
   -> dynamic truncation (31 bits)
   -> mod 1000000
   -> "042318"

7. Nothing is transmitted to generate it. That is why the app works on a plane with no signal.
8. Servers usually accept the previous and next window too, to tolerate clocks being a little out.
9. Now see the weakness clearly. The code is just six digits typed by a human. A convincing fake login page collects it and replays it within 30 seconds.
10. That is not a flaw in the maths. It is a flaw in the shape of the interaction, and no amount of better hashing fixes it.

PLAIN44.6.4 what is really happening inside#

1. SMS one-time codes are weaker still, for reasons outside your control.
2. SIM swapping: an attacker persuades a mobile operator to move your number to their SIM, using social engineering on a support agent. Your codes now arrive on their phone.
3. The mobile signalling network itself has known interception weaknesses, and messages travel through third parties in plain form.
4. Push-approval prompts fixed the typing problem but created a new one: MFA fatigue, where an attacker with your password sends prompt after prompt until you approve one to make it stop, often at three in the morning.
5. This is not theoretical. The September 2022 Uber breach began with a contractor’s stolen password plus repeated push prompts, finished off by a message pretending to be internal IT support.
6. Number matching, where the login screen shows two digits you must type into the prompt, is the standard mitigation and is now on by default in the major identity providers.
7. Now the hardware key. Registration: the key generates a fresh key pair for that one website, keeps the private key inside the hardware, and sends the public key to the site.
8. Login: the site sends a random challenge. The browser adds the exact origin it is talking to. The key signs both together.
9. If the origin is a look-alike domain, the signature is over the wrong origin and the real site rejects it. There is no code for a human to relay.
10. The private key never leaves the device. There is no shared secret in the site’s database, so a breach of the site leaks only public keys.
11. A passkey is the same protocol with the key material held by the operating system or password manager and typically synchronized across your devices through your platform account.
12. That synchronization is the trade-off. It makes recovery practical, at the cost of the cloud account becoming part of the security boundary.

TECHNICAL44.6.5 the engineer’s version#

1. HOTP is RFC 4226 (2005), counter-based. TOTP is RFC 6238 (2011), time-based, with a default 30-second step and 6 digits. The default HMAC is SHA-1, which is acceptable here because HMAC-SHA-1 is not broken by collisions.
2. FIDO2 combines two specifications: W3C Web Authentication, WebAuthn Level 2 became a W3C Recommendation in April 2021 with Level 3 in progress, and CTAP2 from the FIDO Alliance for the link between browser and authenticator.
3. WebAuthn signs a client data structure containing the challenge, the origin and the type. Origin binding is the phishing resistance, and it is a property of the protocol, not of user training.
4. Attestation optionally proves what kind of authenticator was used. Enterprises use it to require certified hardware; consumer sites usually should not, for privacy reasons.
5. Passkeys are discoverable WebAuthn credentials. The FIDO Alliance State of Passkeys report of 7 May 2026 put around 5 billion passkeys in use, with 75 percent of surveyed consumers having enabled at least one and 68 percent of surveyed organizations deploying them.
6. Comparison of second factors, ranked honestly.

7. NIST SP 800-63B revision 4, published 31 July 2025, classifies restricted authenticators and requires that risks of the public switched telephone network be assessed; SMS remains permitted but discouraged.
8. Biometrics are convenient and have real limits. They are not secrets, they cannot be revoked, and matching is probabilistic with a false accept rate and a false reject rate that trade against each other.
9. Apple published a figure of roughly 1 in 50,000 false accept for Touch ID and 1 in 1,000,000 for Face ID, per attempt, with limited retries.
10. The right mental model: on a phone, the biometric unlocks a key stored in secure hardware locally. It is a convenient local gate, not an identity sent over the network.
11. Session management matters as much as login. Rotate session identifiers on privilege change, set HttpOnly, Secure and SameSite on cookies, and give tokens the shortest lifetime the product can tolerate.
12. Account recovery is where most authentication systems actually fail. If a help desk can reset MFA after a phone call, the strength of your authenticator is irrelevant. The 2023 MGM Resorts intrusion is the textbook case.

WORDS44.6.6 remember these#

Authentication — proving who you are — verification of a claimed identity against registered authenticators.

Factor — a category of evidence — knowledge, possession or inherence.

TOTP — the app’s six-digit code — time-based one-time password, RFC 6238, derived from a shared secret and the clock.

SIM swap — hijacking your phone number — social engineering a carrier into porting a number to an attacker’s SIM.

MFA fatigue — approving to stop the buzzing — repeated push prompts intended to wear the user down.

WebAuthn — the browser standard for hardware login — W3C API binding a signature to a challenge and an origin.

Passkey — a synchronized hardware-grade credential — discoverable WebAuthn credential held by an OS or password manager.

Origin binding — the key checks the address — protocol-level inclusion of the verified origin in the signed data.

44.7 Authorization and access control#

PLAIN44.7.1 in simple words#

1. Authentication asks who you are. Authorization asks what you may do.
2. They are different questions, they fail differently, and mixing them up causes a large share of real breaches.
3. Being logged in is not permission. Every request must be checked, not just the first one.
4. There are four common ways to decide.
5. Discretionary access control: the owner of a thing decides who may use it. This is how files on your laptop work.
6. Mandatory access control: a central policy decides, and even the owner cannot override it. This is how classified military systems work.
7. Role-based access control: permissions attach to roles, and people get roles. Editor, viewer, administrator.
8. Attribute-based access control: a rule engine decides from facts about the user, the resource, the action and the context.
9. Two principles run through all of them.
10. Least privilege: every person and every program gets the minimum access needed to do its job, and no more.
11. Separation of duties: the person who requests a payment is not the person who approves it.
12. And one classic trap, the confused deputy: a program with more privilege than you does something on your behalf that you were not allowed to ask for.

PLAIN44.7.2 a picture in your head#

1. A hospital. Authentication is the badge reader at the door confirming you are Dr Sharma.
2. Authorization is the separate question of which wards, which drug cabinets and which patient records Dr Sharma may open.
3. Discretionary control is a doctor lending their office key to a colleague.
4. Mandatory control is the pharmacy safe, where policy overrides everyone, including the head of the department.
5. Role-based control is the badge saying “consultant”, and consultants have a fixed list of doors.
6. Attribute-based control is a rule saying: a doctor may open a record if they are the treating clinician, on shift, in this hospital, today.
7. Least privilege is not giving the night cleaner a master key to the drug store.
8. Separation of duties is two signatures for a controlled substance.
9. The confused deputy is the porter who is trusted to enter any room, being asked by a stranger to fetch a file from a locked office. The porter has the right; the stranger did not.

Where this comparison breaks: a hospital has physical friction, and a human porter might feel that a request is odd. Software has no instinct. A service with broad rights will carry out a strange request a million times a second without hesitating once.

PLAIN44.7.3 a worked example#

1. Here is a real least-privilege event from the running example in this book.
2. The reader’s GitHub personal access token could push code, but one push was refused because the change touched a CI workflow file and the token did not carry the workflow scope.
3. That refusal is authorization working exactly as designed.
4. The token was authenticated perfectly. GitHub knew whose token it was. It simply was not authorized for that class of change.
5. Notice the security value. If that token had leaked, an attacker could have pushed ordinary code, which review would catch, but could not have silently rewritten the pipeline that builds and deploys.
6. Now a broken example, stated as a pattern rather than a recipe. A web application shows an invoice at a path containing an invoice number, and the server checks that you are logged in but never checks the invoice belongs to you.
7. Changing the number in the address bar then shows somebody else’s invoice. That is an insecure direct object reference, and it is the single most common serious web flaw found in real assessments.
8. The fix is not to hide or scramble the number. The fix is that every lookup asks the database for the invoice with that number and that owner.
9. Compare the two designs in one table.

PLAIN44.7.4 what is really happening inside#

1. Access decisions have a standard shape with two named parts.
2. The policy decision point works out the answer. The policy enforcement point actually blocks or allows the request.
3. If the enforcement point sits only in the user interface, you have no security at all. Hiding a button does not remove the endpoint behind it.
4. Enforcement belongs on the server, as close to the data as possible.
5. The strongest pattern is to make the check impossible to forget: scope every query by owner at the data layer, so an unscoped query cannot even be written.
6. Row-level security in PostgreSQL, or a mandatory tenant filter in the object-relational mapper, both achieve this.
7. Confused deputy in software, concretely. Your service holds cloud credentials that can read any file in a bucket. A user supplies a file name. Your service reads it and returns it.
8. The user has borrowed your privilege. The service was authorized; the user was not. Server-side request forgery is the same disease with network access instead of file access.
9. The cure is to never let untrusted input select the target of a privileged operation directly. Map user input through a list of allowed values that you control, and check ownership before acting.
10. Capability-based systems attack the problem from the other side. Instead of saying “who are you, and are you allowed”, you hold an unforgeable token that already names exactly what you may do.
11. A pre-signed cloud storage URL is a capability. It carries its own authority, is scoped to one object and one action, and expires.

TECHNICAL44.7.5 the engineer’s version#

1. The Bell-LaPadula model, published in 1973 by David Bell and Leonard LaPadula, formalized mandatory confidentiality: no read up, no write down.
2. The Biba model, 1977, is its integrity mirror: no write up, no read down.
3. Role-based access control was formalized by David Ferraiolo and Richard Kuhn in 1992 and standardized as ANSI INCITS 359-2004.
4. Attribute-based access control is described in NIST SP 800-162 (2014). XACML is the long-standing policy language; Open Policy Agent with its Rego language is the common modern implementation.
5. The confused deputy problem was named by Norm Hardy in a 1988 paper about a compiler that could be tricked into overwriting its own billing file.
6. In cloud practice: AWS IAM policies, Azure RBAC and Google Cloud IAM are all attribute-flavoured RBAC. The recurring failure is an over-broad wildcard in the action or resource field.
7. OAuth 2.0, RFC 6749 (2012), is a delegation framework, not an authentication protocol. OpenID Connect layers authentication on top of it. Confusing the two produces real vulnerabilities.
8. Scopes in OAuth are coarse permissions granted to an application. They are not a substitute for per-object ownership checks inside your service.
9. Broken Access Control is ranked A01 in the OWASP Top 10 for both the 2021 and 2025 editions, and in the 2025 edition server-side request forgery was folded into it.
10. Practical controls to implement: deny by default, centralize the authorization function rather than scattering conditionals, log every denial, and write tests that assert a user cannot reach another user’s objects.
11. Commands and tools to observe: aws iam simulate-principal-policy for AWS, kubectl auth can-i for Kubernetes, getfacl and ls -l for POSIX file permissions, getenforce and ausearch -m avc for SELinux decisions.
12. On Linux, capabilities split the historic all-or-nothing root privilege into pieces such as CAP_NET_BIND_SERVICE. Granting only that is far better than running a web server as root to bind port 80.

WORDS44.7.6 remember these#

Authorization — what you are allowed to do — the decision about permitted actions on resources, distinct from identity.

Least privilege — only what the job needs — granting the minimum rights required, for the minimum time.

Separation of duties — two people, two steps — splitting a sensitive operation so no single actor can complete it.

RBAC — permissions through job titles — role-based access control, ANSI INCITS 359-2004.

ABAC — permissions from rules and facts — attribute-based access control, NIST SP 800-162.

Confused deputy — borrowing someone else’s power — a privileged component misused by a less privileged caller.

IDOR — changing the number in the URL — insecure direct object reference, a missing per-object ownership check.

Policy enforcement point — where the block happens — the component that actually denies or permits a request.

44.8 The web application vulnerability classes, defensively#

PLAIN44.8.1 in simple words#

1. Almost every web vulnerability is one of two mistakes.
2. Mistake one: data supplied by a user was treated as instructions.
3. Mistake two: a check that should have happened did not happen on this path.
4. Injection is mistake one against a language: SQL, shell, LDAP, XPath.
5. Cross-site scripting is mistake one against a browser: your page ends up carrying somebody else’s script.
6. Cross-site request forgery is a browser being tricked into sending a request it should not, using cookies it already holds.
7. Broken access control is mistake two: the user is logged in but nobody checked the thing belongs to them.
8. Server-side request forgery is your server being used as a proxy to reach places the user cannot reach.
9. Path traversal is a file name from a user escaping upwards out of the directory you intended.
10. Insecure deserialization is rebuilding an object graph from untrusted bytes, which in many languages can run code as a side effect.
11. XML external entities is an XML parser being told to fetch files or URLs while parsing.
12. Mass assignment is a form binder copying every submitted field onto your object, including the one called is_admin.

PLAIN44.8.2 a picture in your head#

1. Imagine a clerk who reads out a sentence you wrote on a form, into a machine that obeys sentences.
2. You write your name. The clerk reads “Ravi” and the machine files it.
3. Someone else writes a name that continues into a new sentence, and the machine obeys that too, because the clerk never knew where the name ended.
4. The bad fix is to inspect names for suspicious words. Attackers write sentences you did not think of.
5. The good fix changes the shape of the conversation. The clerk hands the machine the sentence template and the name through a separate slot.
6. The machine now knows, structurally, that the name is a name. It cannot become an instruction no matter what is written in it.
7. That is exactly the difference between building a query by gluing strings together and using a parameterized query.

Where this comparison breaks: the clerk analogy suggests the danger is only in one direction. In reality the same data may pass through several machines with different rules, a database, then a browser, then a shell, and each needs its own correct handling. Data safe for one is not automatically safe for another.

PLAIN44.8.3 a worked example#

1. The flawed pattern for SQL injection, shown so you can recognize it in a code review. This is the shape to reject, not code to run.

# WRONG: query text is built from user input
q = "SELECT * FROM users WHERE email = '" + email + "'"
db.execute(q)

2. Because the value is glued into the query text, a value containing a quote character can end the string early and the rest is parsed as query structure. Nothing after that is under your control.
3. The correct version, which removes the class of bug entirely.

# RIGHT: structure and data travel separately
q = "SELECT * FROM users WHERE email = ?"
db.execute(q, (email,))

4. Why this fixes it by construction: the database receives the query structure first and compiles it, then receives the value as a typed parameter. The value can never be reinterpreted as syntax.
5. Escaping and filtering are weaker answers. They depend on getting every edge case right, in every encoding, forever. Parameterization does not.
6. The same principle applies to shell commands. Do not build a command string; pass an argument list to the operating system directly, so the shell never parses your data.
7. The real-world consequence of getting this wrong: the MOVEit Transfer incident of May 2023 began with a SQL injection flaw, CVE-2023-34362, which the Cl0p group used at scale. Public tracking put the total above 2,600 organizations and tens of millions of individuals.

PLAIN44.8.4 what is really happening inside#

1. Cross-site scripting comes in three shapes, and the difference matters for the fix.
2. Stored: the attacker’s text is saved in your database, and every later visitor receives it. Highest impact.
3. Reflected: the text comes in on the request and is echoed straight back in the response. Needs a victim to follow a crafted link.
4. DOM-based: the server never sees it. Client-side JavaScript reads part of the page address and writes it into the page.
5. The fix is contextual output encoding. Encode when writing out, not when reading in, because the correct encoding depends on where the value lands: HTML body, attribute, JavaScript string, URL or CSS each differ.
6. Modern frameworks encode by default. The vulnerabilities cluster around the escape hatches, the functions with names like dangerouslySetInnerHTML or v-html.
7. A Content Security Policy header is the second layer. It tells the browser which script sources are allowed, so injected inline script does not execute even if it reaches the page.
8. A strict policy uses per-response nonces or hashes rather than a domain allowlist, because allowlists are routinely bypassed through permissive files on the allowed domains.
9. Cross-site request forgery works because browsers attach cookies for a site automatically, whatever page triggered the request.
10. The modern structural defence is the SameSite cookie attribute. Lax is the default in current Chrome and Firefox and blocks cookies on cross-site POST requests. Strict is stronger and sometimes inconvenient.
11. Keep anti-CSRF tokens as well, because SameSite behaviour varies across browsers and versions and does not protect against same-site attackers.

TECHNICAL44.8.5 the engineer’s version#

1. The current edition is the OWASP Top 10:2025, presented at OWASP Global AppSec on 6 November 2025, built from data across more than 2.8 million applications plus roughly 175,000 CVE-to-CWE mappings.

2. The remaining five in 2025 are A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, and A10 Mishandling of Exceptional Conditions.
3. Two categories are new or newly framed: Software Supply Chain Failures, and Mishandling of Exceptional Conditions. Server-side request forgery, which had its own slot in 2021, was consolidated into Broken Access Control.
4. Defences by class, stated as the fix a reviewer should insist on.

5. Path traversal, CWE-22: resolve the path to its canonical absolute form first, then confirm it starts with the intended base directory. Checking for the literal two-dot sequence before resolving fails against encodings.
6. XXE, CWE-611: disable document type definitions entirely in the parser. In Java that means setting disallow-doctype-decl to true; in Python use defusedxml. Many parsers changed to safe defaults after 2018, but not all.
7. Insecure deserialization, CWE-502: never deserialize untrusted data into arbitrary types. Use a data-only format such as JSON with an explicit schema. Java native serialization, Python pickle, PHP unserialize and .NET BinaryFormatter are all unsafe on untrusted input by design.
8. Mass assignment, CWE-915: bind to an explicit allowlist of fields, or use a separate data transfer object per endpoint rather than the database model.
9. SSRF, CWE-918: block link-local metadata addresses such as 169.254.169.254, re-validate after every redirect, and resolve the hostname once and connect to that exact address to avoid time-of-check to time-of-use tricks.
10. Log4Shell, CVE-2021-44228, disclosed 9 December 2021 with a CVSS score of 10.0, was an injection flaw in a logging library: attacker-controlled text that reached a log call could trigger a remote lookup. It is the clearest reminder that logging is also an input-handling path.
11. Tools that observe: zap and Burp Suite for interactive testing, semgrep and CodeQL for static analysis, sqlmap only against systems you own or are authorized in writing to test.

WORDS44.8.6 remember these#

Injection — data treated as instructions — untrusted input reaching an interpreter as part of its command structure.

Parameterized query — structure and data kept apart — precompiled statement with typed placeholders, immune to SQL injection.

XSS — someone else’s script on your page — cross-site scripting, stored, reflected or DOM-based.

Content Security Policy — a browser rulebook for scripts — response header restricting which sources may execute.

CSRF — your browser sending a request it should not — forged cross-site request riding on ambient cookies.

SameSite — the cookie’s travel restriction — cookie attribute limiting sending on cross-site requests, Lax by default.

SSRF — your server fetching what the user cannot — server-side request forgery against internal or metadata endpoints.

Mass assignment — the form that set is_admin — automatic binding of request fields to object properties without an allowlist.

44.9 Memory safety#

PLAIN44.9.1 in simple words#

1. Some languages let a program read and write memory outside the space it asked for. C and C++ are the important ones.
2. They do this on purpose. Bounds checking costs time, and these languages were designed when every cycle mattered.
3. A buffer overflow happens when a program copies more bytes into a space than that space can hold, and the extra bytes land on whatever is next.
4. What is next, on the stack, is often bookkeeping: saved registers and the address the function will return to.
5. Overwrite that return address and the processor jumps somewhere the programmer never intended when the function finishes.
6. Use-after-free is using a pointer to memory that was already released. The allocator may have handed that space to someone else.
7. Double-free is releasing the same block twice, which corrupts the allocator’s own bookkeeping.
8. Integer overflow is a size calculation wrapping around past the largest representable value, producing a tiny allocation for a huge copy.
9. All four are the same underlying story: the program lost track of how big something is or how long it lives.

PLAIN44.9.2 a picture in your head#

1. Think of a row of numbered pigeonholes on a wall, each one letter wide.
2. You are told to write an eight-letter word into a four-letter hole.
3. Nothing stops you. The last four letters spill into the next holes.
4. Now suppose the hole immediately after yours holds the room number the messenger will visit next.
5. You have just changed where the messenger goes, without touching the messenger.
6. A stack canary is a small agreed word placed just before that room number. Before leaving, the messenger checks the word is unchanged. If your spill overwrote it, the program stops.

Where this comparison breaks: real overflows are not always sequential and not always on the stack. Heap corruption works by damaging the allocator’s own records, which is subtler and does not pass through a canary at all. And the canary only detects a contiguous overwrite, not a targeted single-word write.

PLAIN44.9.3 a worked example#

1. A stack frame, drawn as it grows downwards in memory on a typical system.

   higher addresses
   +----------------------------+
   |  caller's data             |
   +----------------------------+
   |  return address            |  <- overwriting this
   +----------------------------+     redirects execution
   |  saved frame pointer       |
   +----------------------------+
   |  stack canary              |  <- checked before return
   +----------------------------+
   |  local buffer [64 bytes]   |  <- copy starts here
   +----------------------------+     and grows upwards
   lower addresses

2. The copy starts at the bottom of the buffer and moves up towards the canary, the frame pointer and the return address.
3. So a copy of 80 bytes into a 64-byte buffer reaches exactly the fields that control what happens when the function returns.
4. Integer overflow feeding an allocation, shown as a pattern to reject.

/* WRONG: count * size can wrap around */
buf = malloc(count * size);
memcpy(buf, src, count * size);

5. If count times size exceeds the maximum of the type, the product wraps to a small number. The allocation succeeds at that small size, and the copy then writes far past it.
6. The correct pattern checks for overflow first, or uses a checked helper such as calloc, or uses a language where sizes cannot silently wrap.

PLAIN44.9.4 what is really happening inside#

1. Four defences are standard on modern systems, and each raises cost rather than removing the bug class.
2. Stack canaries, from StackGuard in 1998: a random value written before the return address and verified before returning.
3. Non-executable memory, called NX or DEP: pages are either writable or executable, not both, so injected data cannot be run as code.
4. Attackers answered with return-oriented programming, which chains together small fragments of code that already exist in the program. Nothing new is injected, so NX does not help.
5. Address space layout randomization: load the program and its libraries at unpredictable addresses so the attacker cannot know where anything is.
6. Attackers answer with information leaks that reveal one address, from which the rest follows.
7. Control flow integrity: check at run time that every indirect jump goes to a legitimate target. ARM Pointer Authentication and Intel CET are hardware support for this idea.
8. Honest summary: each of these turns a reliable exploit into an unreliable or expensive one. None of them makes the underlying bug disappear.
9. The real fix is a language that cannot express the bug. Rust checks lifetimes and ownership at compile time. Go, Java, C#, Python and JavaScript check bounds at run time and manage memory automatically.
10. That is not free. Garbage collection has pauses, run-time checks cost a few percent, and Rust’s rules are hard to learn. But the cost is bounded and the bug class is gone.

TECHNICAL44.9.5 the engineer’s version#

1. Scale, from vendor data. Microsoft reported at BlueHat in 2019 that about 70 percent of the CVEs it assigned each year since 2006 were memory safety issues. Google reported a similar proportion for Chrome.
2. Google’s Android security team reported that memory safety vulnerabilities fell from about 76 percent of Android vulnerabilities in 2019 to about 24 percent in 2024, as new code was written in Rust and Java rather than C++.
3. Government guidance, with dates. CISA, the NSA, the FBI and international partners published “The Case for Memory Safe Roadmaps” in December 2023.
4. The United States Office of the National Cyber Director published “Back to the Building Blocks: A Path Toward Secure and Measurable Software” in February 2024, explicitly recommending memory-safe languages.
5. The NSA and CISA published “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development” in June 2025.
6. None of these are laws. They are procurement pressure and expectation setting, and they are already changing what buyers ask for.

7. Heartbleed, CVE-2014-0160, disclosed 7 April 2014, was an out-of-bounds read in OpenSSL’s TLS heartbeat handling. It leaked up to 64 kilobytes of process memory per request, including private keys, and it left no trace in ordinary logs.
8. Tools that find these before shipping: AddressSanitizer and MemorySanitizer, UndefinedBehaviorSanitizer, Valgrind, the compiler flags -fstack-protector-strong and -D_FORTIFY_SOURCE=3, and fuzzing with libFuzzer, AFL++ or OSS-Fuzz.
9. Check a binary’s own defences with checksec --file=./binary on Linux, or otool -hv on macOS. Confirm ASLR is enabled system-wide with sysctl kernel.randomize_va_space, where 2 means full randomization.
10. Where experts disagree: whether to rewrite existing C code, or only write new code in safe languages. The rewrite camp cites persistent bug rates; the incremental camp cites the risk of reintroducing logic bugs in mature, heavily tested code. Practice mostly favours the incremental route.

WORDS44.9.6 remember these#

Memory safety — the program cannot stray outside its own memory — guaranteed absence of out-of-bounds and lifetime errors.

Buffer overflow — writing past the end of a space — out-of-bounds write, often CWE-787.

Use-after-free — using something already returned — dereferencing a pointer to released memory, CWE-416.

Stack canary — a tripwire before the return address — random guard value verified before function return.

ASLR — moving the furniture every boot — address space layout randomization.

NX / DEP — memory is writable or runnable, not both — hardware-enforced non-executable pages.

Control flow integrity — checking every jump is legitimate — run-time or hardware validation of indirect branch targets.

Sanitizer — a bug detector built into a test build — instrumentation such as AddressSanitizer that reports violations at run time.

44.10 Network attacks conceptually#

PLAIN44.10.1 in simple words#

1. Three network attacks matter for a working engineer.
2. Man-in-the-middle: someone sits between you and the server, reading and possibly changing what passes.
3. Spoofing: someone lies about an address, so your traffic goes to them instead of the real destination.
4. Denial of service: someone sends so much traffic or so many expensive requests that the real users cannot get through.
5. TLS answers the first one. It encrypts, so a listener sees nothing useful, and it authenticates the server by certificate, so an impostor cannot pass.
6. Chapter 32 covered how that certificate check works. The one-line version: the server proves it holds the private key for a name signed by an authority your device already trusts.
7. Spoofing works at two levels. On your local network, ARP spoofing lets a machine claim to be the router.
8. On the wider internet, DNS spoofing makes a name resolve to the wrong address.
9. Denial of service comes in three flavours: raw volume, connection exhaustion, and expensive requests that cost the server far more than the attacker.
10. Amplification is the nastiest volume trick: send a small question with a faked return address to a public server, and it sends a large answer to the victim.

PLAIN44.10.2 a picture in your head#

1. Picture a post room in an office building.
2. ARP spoofing is somebody standing up and repeatedly announcing “I am the mail chute”, until everyone believes them and hands over their post.
3. There is no verification step in the announcement, by design. The protocol simply believes the last thing it heard.
4. DNS spoofing is somebody rewriting the internal phone directory, so calls for accounts reach a different desk.
5. Amplification is posting a one-line letter that says “send me your full catalogue”, with the victim’s return address on it, to ten thousand companies at once.
6. Each catalogue is heavy, none of them is your problem, and all of them arrive at the victim.

Where this comparison breaks: office post is slow and physical, so the flood is visible. On a network the same trick delivers terabits per second within seconds, and there is no time for a human to react. That is why the defences must be automatic.

PLAIN44.10.3 a worked example#

1. Amplification factors, measured by researchers and widely published.

2. Read the last row. A single byte sent can produce tens of thousands of bytes delivered to the victim.
3. That is not theoretical. On 28 February 2018 GitHub absorbed a 1.35 terabit per second memcached amplification attack, the record at the time. It was mitigated within about ten minutes by routing traffic through a scrubbing provider.
4. Scale has moved a long way since. Cloudflare reported mitigating attacks of 22.2 terabits per second in September 2025, 29.7 in October 2025, and 31.4 during December 2025. All were attributed to the Aisuru botnet family, running largely on compromised consumer devices.
5. The December record lasted about 35 seconds. There is no human response time available in that window.
6. Attacks are not only about volume. In October 2023 the HTTP/2 Rapid Reset technique, CVE-2023-44487, produced request-rate records by opening and immediately cancelling streams, costing the server far more than the client.

PLAIN44.10.4 what is really happening inside#

1. ARP has no authentication. A device asks “who has 192.168.0.1”, and any machine on that network segment can answer. Most systems accept unsolicited answers and cache them.
2. That is why untrusted local networks matter, and why a VPN or plain TLS everywhere is the practical answer for a laptop in a cafe.
3. DNS cache poisoning aims to get a false answer accepted and cached by a resolver, so every later user of that resolver is sent to the wrong place.
4. Classic DNS used a 16-bit transaction identifier and no signatures, which Dan Kaminsky showed in July 2008 was far too little entropy.
5. The immediate fix was source port randomization, which multiplied the guessing space. The structural fix is DNSSEC, which signs records.
6. The reader’s own machine uses 1.1.1.1 as its resolver rather than the router. That reduces exposure to a compromised or mis-configured home router, and it moves trust to Cloudflare instead. It is a trade, not a removal of trust.
7. Encrypted DNS, DNS over HTTPS in RFC 8484 and DNS over TLS in RFC 7858, hides the query from the local network and from the internet provider. It does not prove the answer is correct; only DNSSEC does that.
8. For denial of service, the defences are layered and none works alone.
9. Rate limiting by address, by account and by expensive operation.
10. Filtering at the network edge, dropping obviously forged or malformed packets before they reach an application.
11. Anycast, where the same address is announced from many locations, so an attack is split across dozens of data centres instead of hitting one.
12. Scrubbing, where traffic is diverted through a provider that removes attack packets and forwards the rest.
13. And the structural fix nobody can do alone: source address validation at the internet provider, described in BCP 38, published as RFC 2827 in 2000. Amplification only works because forged source addresses still get forwarded.

TECHNICAL44.10.5 the engineer’s version#

1. What TLS does and does not do against interception. It authenticates the server’s name and protects the channel. It does not protect against a client that has been made to trust an extra certificate authority, which is how corporate interception proxies work, as Chapter 32 described.
2. Certificate Transparency, RFC 6962 and its successor RFC 9162, provides public append-only logs so that mis-issued certificates for your domain can be detected after the fact. Monitoring those logs is a real control.
3. HSTS, RFC 6797, removes the plaintext first request. Preloading puts your domain in a list shipped inside browsers.
4. Layer 2 defences: dynamic ARP inspection and DHCP snooping on managed switches, and 802.1X port authentication for wired and wireless access.
5. DNS defences: DNSSEC validation on the resolver, DNS cookies in RFC 7873, and response rate limiting on authoritative servers.
6. Denial of service categories map to network layers. Volumetric floods saturate bandwidth, protocol attacks such as SYN floods exhaust connection state, and application-layer attacks exhaust processing.
7. SYN cookies, invented by Daniel J. Bernstein in 1996, remove the need to keep state for half-open connections. Enable with sysctl net.ipv4.tcp_syncookies=1 on Linux.
8. Observation commands: tcpdump -i any -n and Wireshark for packet capture, arp -a to see the current address table, dig +dnssec example.com to check signature records, mtr for continuous path measurement, and ss -s for socket state counts under load.
9. Historical scale markers, for calibration.

10. Mirai was notable for what it infected: consumer routers and cameras with factory default passwords. Its source code was published in September 2016, which is why variants are still active a decade later.

WORDS44.10.6 remember these#

Man-in-the-middle — someone sitting between you and the server — an active interception attack on a communication channel.

ARP spoofing — claiming to be the router — forged address resolution replies poisoning a local network’s address cache.

DNS cache poisoning — putting a lie in the phone book — injecting a forged record that a resolver stores and reuses.

Amplification — a small question, a huge answer — reflection attack exploiting protocols with large response-to-request ratios.

Anycast — one address, many locations — routing technique spreading traffic across distributed sites.

Scrubbing — cleaning the traffic elsewhere — diverting traffic through a provider that filters attack packets.

BCP 38 — stop forged source addresses at the door — RFC 2827 ingress filtering, the structural cure for amplification.

SYN cookies — answering without remembering — stateless response encoding that defeats half-open connection floods.

44.11 Malware and how infection actually happens#

PLAIN44.11.1 in simple words#

1. Malware is any program written to work against the interests of the person whose machine it runs on.
2. A virus attaches itself to another file and spreads when that file is run by a person.
3. A worm spreads by itself across a network, needing no human at all.
4. A trojan pretends to be something useful so you install it willingly.
5. Ransomware encrypts your files and demands payment for the key.
6. Spyware watches you: keystrokes, screenshots, messages, location.
7. A rootkit hides other malware by lying to the operating system about what files and processes exist.
8. A bootkit goes lower still and loads before the operating system does, so the system it lies to never sees the truth.
9. A botnet is many infected machines taking orders from one place.
10. A cryptominer quietly spends your electricity and processor on mining.
11. Fileless malware never writes a program to disk; it lives in memory and in legitimate system tools, so file scanning finds nothing.

PLAIN44.11.2 a picture in your head#

1. Think of a building and the ways an unwanted person gets in.
2. Someone posts a package that a staff member opens: that is a malicious attachment.
3. Someone phones pretending to be head office and gets a door code: phishing.
4. A supplier’s cleaning contractor is bribed, and their key still works: supply chain compromise.
5. A window at the back has been unlocked for two years because nobody checked: an unpatched internet-facing service.
6. Someone leaves a labelled envelope in the car park hoping it gets carried inside: removable media.

Where this comparison breaks: a building has one entrance list. A modern company has thousands of accounts, hundreds of cloud services and dozens of suppliers, and no single person knows all of them. The unlocked window is usually one nobody remembered existed.

PLAIN44.11.3 a worked example#

1. Realistic infection routes, ranked by how often they appear in incident reports, with the control that actually helps.

2. Ransomware in particular follows a pattern that has barely changed since 2019: get in, look around quietly for days or weeks, steal a copy of the data, find and destroy the backups, then encrypt everything at once.
3. Stealing the data first is deliberate. It creates a second threat, to publish, so that having good backups is no longer a complete answer.
4. Chainalysis reported that tracked ransomware payments fell about 35 percent in 2024, to roughly 813 million dollars, as more victims refused to pay.
5. The FBI Internet Crime Complaint Center reported 20.9 billion dollars in total reported losses for 2025, from more than one million complaints, in its annual report published in April 2026.

PLAIN44.11.4 what is really happening inside#

1. Detection works in three different ways, and each fails differently.
2. Signatures: match known bad bytes or known bad file hashes. Precise, no false alarms, and useless against anything new or repacked.
3. Heuristics: score suspicious structure, such as packed code that unpacks itself, or a document containing a macro that reaches the network.
4. Behaviour: watch what the program does at run time. A process that enumerates files, opens each one, writes back encrypted content and deletes shadow copies is ransomware regardless of what its bytes look like.
5. EDR, endpoint detection and response, is the behavioural approach with central recording. It keeps a timeline of process launches, network connections and file changes so an analyst can reconstruct what happened.
6. That recording is often more valuable than the blocking. Without it you cannot answer the only question that matters after an incident: what did they touch?
7. Why antivirus alone is not enough: it is mostly signature and heuristic, it sees one machine, and it cannot judge whether a legitimate administrator tool is being used legitimately.
8. Attackers exploit exactly that gap with living off the land: using PowerShell, certutil, wmic, rundll32 and remote management tools that are already installed and already trusted.
9. For ransomware, the honest advice is unglamorous. Backups are the only reliable answer, and only if they are tested, versioned, and stored where the production credentials cannot delete them.
10. The rule of thumb is three copies, on two kinds of media, with one held offline or immutable. A backup that a compromised administrator account can erase is not a backup.

TECHNICAL44.11.5 the engineer’s version#

1. History markers. The Morris worm of 2 November 1988 infected several thousand machines and led to the founding of the first CERT.
2. ILOVEYOU spread by email in May 2000. Code Red and Nimda hit in 2001. SQL Slammer in January 2003 doubled its population every 8.5 seconds.
3. Stuxnet, discovered June 2010, used four zero-day flaws and stolen code-signing certificates to damage centrifuges. WannaCry, 12 May 2017, and NotPetya, 27 June 2017, both used the EternalBlue SMB exploit; NotPetya caused damages widely estimated above 10 billion dollars.
4. Persistence mechanisms to look for on a compromised host: scheduled tasks, systemd units, launch agents, registry Run keys, WMI event subscriptions, browser extensions, and shell profile files.
5. Firmware and boot-level threats are real but rare. LoJax in 2018 was the first UEFI rootkit found in the wild; BlackLotus in 2023 was the first observed to bypass UEFI Secure Boot on patched systems.
6. Ransomware defensive controls that measurably work: phishing-resistant MFA on all remote access, patching internet-facing services within days, network segmentation so one workstation cannot reach every server, least-privilege service accounts, and immutable backups.
7. Tools that observe: ps, lsof, netstat, Sysinternals Process Explorer and Autoruns on Windows, osquery for fleet inspection, YARA for writing your own detection rules, and VirusTotal for reputation checks on hashes.
8. Never analyze suspicious samples on a working machine. Use an isolated virtual machine with no network path back to anything you care about.

WORDS44.11.6 remember these#

Worm — spreads without a human — self-propagating malware exploiting network services directly.

Trojan — useful on the outside, hostile inside — malware disguised as legitimate software.

Ransomware — your files held hostage — encrypting malware, now usually combined with data theft and threatened publication.

Rootkit — malware that hides other malware — code that subverts the operating system’s view of files and processes.

Fileless malware — nothing on disk to scan — in-memory execution using existing signed system tools.

EDR — a flight recorder for endpoints — endpoint detection and response, behaviour-based with central telemetry.

Living off the land — using your own tools against you — abuse of legitimate administrative binaries to avoid detection.

44.12 Social engineering#

PLAIN44.12.1 in simple words#

1. Most breaches do not start with clever code. They start with a person being helpful.
2. Phishing is a message designed to make you click, log in or pay.
3. Spear phishing is the same, tailored to you personally, using details from your company website and social media.
4. Pretexting is inventing a believable story: a new supplier, an audit, a delivery problem, a colleague locked out before a big meeting.
5. Business email compromise is a targeted fraud in which someone with apparent authority instructs a payment or a change of bank details.
6. Vishing is the same by voice call. Smishing is the same by text message.
7. MFA fatigue is pushing approval prompts until someone approves one.
8. Every one of these works by putting a person under pressure and giving them a way to make the pressure stop.
9. The three levers are always the same: authority, urgency, and a plausible reason not to follow the normal process.

PLAIN44.12.2 a picture in your head#

1. Imagine a new employee on their third day.
2. An email arrives from the finance director, who is travelling, about a confidential acquisition, asking for a transfer today, before close.
3. Every element is designed to disable the normal check: seniority, secrecy, time pressure, and a reason the usual approver is unreachable.
4. The employee is not stupid. They are being professional in a situation engineered so that professionalism produces the wrong action.
5. That is why blaming users is both unkind and useless. The attack was designed against the process, using the person as the tool.

Where this comparison breaks: the picture suggests one dramatic moment. Most real social engineering is patient and boring, a few emails over weeks establishing that the sender is a normal part of the working day.

PLAIN44.12.3 a worked example#

1. Real costs, from published figures.
2. The FBI Internet Crime Complaint Center recorded 2.77 billion dollars in business email compromise losses in 2024 and 3.04 billion dollars in 2025.
3. Phishing remained the most-reported crime type in the 2025 report, with 191,561 complaints and 215.8 million dollars in direct losses.
4. The September 2022 Uber intrusion combined a purchased contractor password, repeated push prompts, and a message claiming to be internal IT support.
5. The September 2023 attacks on MGM Resorts and Caesars Entertainment began with phone calls to help desks, persuading staff to reset credentials and MFA for real employees. MGM disclosed an effect of roughly 100 million dollars on quarterly results.
6. Recognition signs worth teaching, in plain language.

PLAIN44.12.4 what is really happening inside#

1. Attackers do reconnaissance first: company website, LinkedIn, job adverts, conference talks, code repositories, and out-of-office replies.
2. Job adverts leak the technology stack. Out-of-office replies leak who is away and who covers for them. Both are used directly.
3. Domain look-alikes are cheap. A domain differing by one character, or using a different top-level domain, costs a few dollars and reads correctly to a tired human.
4. Since 2023, generative AI has removed the last easy signal: bad grammar. Convincing text in any language, and cloned voices from short public audio samples, are both established capability now, not speculation.
5. So detection must move away from “does it look wrong” to “is this the normal process”.
6. The organizational answers, in order of effectiveness.
7. Phishing-resistant authentication, meaning FIDO2 or passkeys, which removes credential phishing as a category rather than reducing it.
8. Out-of-band verification for money and for access: any change of bank details or any MFA reset is confirmed by calling a number already on file, never a number in the message.
9. A named, blameless reporting route, with a target of reporting in minutes. The measure that matters is time to report, not click rate.
10. Removing single points of authority, so no one person can move money or reset an executive’s access alone.
11. Help desk identity proofing: for high-privilege accounts, require a verification step the caller cannot talk their way around, such as a manager callback or an in-person or video check against a record.

TECHNICAL44.12.5 the engineer’s version#

1. Email authentication is the technical floor. SPF, RFC 7208, lists which servers may send for a domain. DKIM, RFC 6376, signs messages. DMARC, RFC 7489, ties the two to the visible From address and sets a policy.
2. Publish DMARC with p=reject once alignment is confirmed. A monitoring-only policy of p=none left in place for years is a common half-measure.
3. These stop exact-domain spoofing. They do not stop look-alike domains or compromised legitimate accounts, which is where most real fraud now lives.
4. Add external sender banners, attachment sandboxing, link rewriting with time-of-click checks, and lookalike-domain monitoring through certificate transparency logs.
5. MITRE ATT&CK identifiers to use in reporting: T1566 phishing, T1566.001 spearphishing attachment, T1598 phishing for information, T1621 multi-factor authentication request generation.
6. Training works only in a specific form: short, frequent, role-relevant, and focused on process rather than on spotting fakes. Punitive simulated phishing programmes reliably reduce reporting, which makes things worse.
7. Measure two things: median time from first delivery to first report, and the proportion of high-risk transactions confirmed out of band.

WORDS44.12.6 remember these#

Phishing — a message engineered to make you act — social engineering by email or messaging, MITRE T1566.

Spear phishing — phishing written just for you — targeted variant using researched personal or organizational detail.

Pretexting — a believable cover story — fabricated scenario used to justify an unusual request.

Business email compromise — fraud by fake authority — payment or data fraud using impersonated or compromised business accounts.

Vishing and smishing — the phone and text versions — voice and SMS social engineering.

Out-of-band verification — confirm on a different channel — validating a request using contact details held independently of the request.

DMARC — the policy that ties email checks together — RFC 7489 alignment and enforcement policy over SPF and DKIM.

44.13 Supply chain security#

PLAIN44.13.1 in simple words#

1. Your program is mostly other people’s code. A typical application pulls in hundreds of packages, and those pull in more.
2. You trust every one of them, and everyone who can publish an update to any of them.
3. Dependency confusion: your build tool asks for an internal package name and a public registry answers first, with a package somebody else uploaded.
4. Typosquatting: a package with a name one character away from the one you meant, waiting for a typing mistake.
5. Compromised maintainer: a real package, a real author, a stolen account.
6. Malicious update: version 3.4.1 is fine and 3.4.2 is not, and your build accepted it automatically because you asked for “the latest”.
7. The uncomfortable part is that this attacks the trusted path. The code is signed, the download is over TLS, and the certificate is valid. Everything is correct except the contents.

PLAIN44.13.2 a picture in your head#

1. Think of a kitchen buying ingredients from many suppliers.
2. Typosquatting is a sack labelled almost like your usual flour brand.
3. Dependency confusion is a stranger delivering to your door claiming to be your in-house supplier, and your staff accepting because the name matched.
4. Compromised maintainer is your genuine supplier, whose delivery van was taken over last night.
5. A lock file is writing down the exact batch number you accepted, so tomorrow’s delivery must match or be questioned.
6. An SBOM is the ingredient list on the finished product, so when a contamination notice is issued you can tell in minutes whether you used it.

Where this comparison breaks: a kitchen can smell bad flour. Malicious code is designed to behave normally until a condition is met, and often only in the published archive rather than in the source repository everyone reads.

PLAIN44.13.3 a worked example#

1. Four real incidents, with the mechanism and the lesson.

2. event-stream, November 2018: a popular npm package’s maintainer handed the project to a volunteer who then added a dependency containing code targeting a specific cryptocurrency wallet application. Downloads were in the millions per week.
3. SolarWinds, disclosed December 2020: attackers compromised the build pipeline for Orion and inserted the SUNBURST backdoor into signed releases. Roughly 18,000 customers installed it; a much smaller number were then targeted. The signature was valid because the build itself was subverted.
4. Codecov, April 2021: a flaw in a Docker image creation process leaked credentials, which were used to modify the Bash Uploader script. The change sat undetected from 31 January to 1 April 2021 and exfiltrated environment variables, meaning secrets, from users’ CI runs.
5. xz-utils, March 2024: CVE-2024-3094, CVSS 10.0. An account building trust since 2021 became a co-maintainer and placed a backdoor targeting OpenSSH in release tarballs of versions 5.6.0 and 5.6.1. Andres Freund found it on 29 March 2024, from half a second of extra CPU time on SSH logins.
6. Read that last sentence again. The most sophisticated open-source supply chain attack yet found was caught by one engineer noticing a performance anomaly, not by any scanner.

PLAIN44.13.4 what is really happening inside#

1. Dependency confusion, explained defensively, was published by Alex Birsan in February 2021 after he reached more than 35 companies including Apple and Microsoft, earning over 130,000 dollars in bug bounties.
2. The mechanism is resolution order. Many package managers, given a name, consult both an internal registry and the public one and prefer the highest version number. Publishing a very high version publicly wins.
3. The fixes are configuration, not vigilance: scope internal packages under a namespace you own, configure the client to use exactly one source per scope, and reserve your internal names publicly so nobody else can take them.
4. Lock files record the exact resolved version and a hash of each package’s contents. package-lock.json, poetry.lock, Cargo.lock, go.sum.
5. Install in continuous integration with the command that refuses to update the lock file, such as npm ci rather than npm install.
6. Pinning to exact versions removes surprise updates but creates a second duty: something must tell you when a pinned version becomes vulnerable.
7. An SBOM, software bill of materials, is a machine-readable list of every component and version in a build. Its value is answering “are we affected” in minutes rather than weeks, which was the actual pain of Log4Shell.
8. Signing and provenance answer a different question: not what is inside, but who built it, from which source, on which machine.

TECHNICAL44.13.5 the engineer’s version#

1. SBOM formats: SPDX, an ISO standard as ISO/IEC 5962:2021, and CycloneDX from OWASP. United States Executive Order 14028 of 12 May 2021 pushed SBOMs into federal procurement, which is why they spread.
2. Sigstore, launched in 2021 under the Open Source Security Foundation, provides keyless signing: a short-lived certificate is issued against an OpenID Connect identity, the signature is recorded in the public Rekor transparency log, and the key is discarded. cosign is the common tool.
3. SLSA, Supply-chain Levels for Software Artifacts, defines build integrity levels. Level 3 requires a hardened, non-falsifiable build service that produces signed provenance describing exactly what it built and from where.
4. npm provenance, generally available since 2023, publishes signed statements linking a published package to the exact commit and workflow that built it.
5. Reproducible builds mean identical source yields byte-identical output, so independent parties can rebuild and compare. Debian has driven this since 2013 and reports well over 90 percent reproducibility for its main archive.
6. Practical checklist for a team, in priority order: commit and honour lock files; run npm audit, pip-audit, cargo audit or Dependabot in CI; pin base container images by digest, not tag; scope internal packages; generate an SBOM per release; require signed provenance for anything you deploy.
7. Software Supply Chain Failures is A03 in the OWASP Top 10:2025, promoted and broadened from the 2021 category on vulnerable and outdated components.
8. Tools to observe: syft to generate an SBOM, grype or trivy to scan it, cosign verify to check signatures, and osv-scanner against the Open Source Vulnerabilities database.

WORDS44.13.6 remember these#

Dependency confusion — the public registry answering an internal name — a resolution-order attack on package managers.

Typosquatting — a package named almost like yours — malicious package relying on a typing or memory error.

Lock file — the exact batch numbers you accepted — a record of resolved versions and content hashes for reproducible installs.

SBOM — the ingredient list — machine-readable inventory of components, in SPDX or CycloneDX format.

Provenance — who built it, from what — signed attestation linking an artifact to its source and build process.

Sigstore — signing without long-lived keys — keyless signing with certificate issuance and a public transparency log.

Reproducible build — same source, same bytes — property allowing independent verification that a binary matches its source.

44.14 Defence in depth for a real system#

PLAIN44.14.1 in simple words#

1. Defence in depth means assuming each control will fail and putting another one behind it.
2. Network segmentation divides a network into zones so a compromised laptop cannot reach the database directly.
3. A firewall decides which traffic may pass between zones. Default deny, with a short list of allowed paths, is the only sane setting.
4. Zero trust means dropping the idea that being inside the network proves anything. Every request is authenticated and authorized on its own merits.
5. Secure boot makes the machine refuse to load unsigned early software.
6. A TPM is a small chip that stores keys and measurements the main processor cannot forge.
7. Measured boot records a hash of each stage into the TPM, so the machine can later prove which software it actually booted.
8. Disk encryption protects data on a powered-off device. It does nothing at all once the machine is running and unlocked.
9. Sandboxing and containers limit what a compromised process can reach.
10. And the highest-value activity of all, which almost nobody does properly: patching, quickly and everywhere.

PLAIN44.14.2 a picture in your head#

1. A castle is the traditional image, and it is the wrong one, because it suggests one wall with everything soft inside.
2. Use a ship instead. A ship has watertight compartments.
3. A hole in one compartment floods that compartment. The ship stays up.
4. Segmentation is the bulkheads. Least privilege is each compartment holding only what belongs in it.
5. Zero trust is the rule that a door between compartments needs a valid reason every single time, not just because you are already aboard.

Where this comparison breaks: bulkheads are physical and permanent. Network segments are configuration, and configuration drifts. The temporary firewall rule opened for a migration in 2022 is still open, and nobody knows why.

PLAIN44.14.3 a worked example#

1. What disk encryption actually protects against, stated honestly.

2. That table is the whole point. FileVault on macOS, BitLocker on Windows and LUKS on Linux all defend the same narrow, real, valuable case: physical loss of a powered-off device.
3. The key is normally sealed to the TPM or Secure Enclave and released only if measured boot matches. That is why changing firmware settings can trigger a recovery key prompt: the measurements changed, so the seal did not open.
4. Sandboxing and containers, honestly. A container is a process with restricted namespaces and control groups, sharing one kernel.
5. That is a real boundary and a useful one. It is not the same boundary as a virtual machine, because one kernel flaw crosses it.
6. Where isolation must be strong, use virtual machines, or lightweight hypervisor-backed sandboxes such as Firecracker or gVisor.

PLAIN44.14.4 what is really happening inside#

1. Zero trust in practice is three concrete changes, not a product.
2. One: identity is checked at every request, for users and for services alike.
3. Two: device health is part of the decision. Is the disk encrypted, is the operating system current, is the endpoint agent reporting?
4. Three: access is per-application rather than per-network, so being on the VPN does not grant everything on the subnet.
5. Google’s BeyondCorp, published from 2014 onwards, is the reference implementation. NIST SP 800-207, published August 2020, is the reference architecture.
6. Patching is the highest-value activity because most successful intrusions use a flaw that was fixed months earlier.
7. Measure two numbers: how long from a fix being published to it being installed on internet-facing systems, and what fraction of your fleet is current. Days and percentages, not intentions.
8. CISA’s Known Exploited Vulnerabilities catalogue, started November 2021, is the practical priority list. It contains only flaws with confirmed exploitation, and it is short enough to act on.
9. The reason patching does not happen is never ignorance. It is fear of breakage, and the answer is automated testing and staged rollout, which is an engineering investment, not a security one.

TECHNICAL44.14.5 the engineer’s version#

1. Layers, with a concrete control at each.

2. UEFI Secure Boot verifies signatures on the bootloader and kernel. Measured boot extends PCR registers in the TPM with hashes of each stage, enabling remote attestation.
3. TPM 2.0 has been an ISO standard as ISO/IEC 11889 since 2015 and is a Windows 11 requirement. Apple’s equivalent is the Secure Enclave.
4. Container hardening: run as a non-root user, drop all Linux capabilities and add back only what is needed, set a read-only root filesystem, apply a seccomp profile restricting system calls, and never mount the Docker socket into a container.
5. Kubernetes specifics: Pod Security Admission at restricted, network policies that default to deny, and short-lived projected service account tokens rather than long-lived secrets.
6. Egress filtering is underrated. Most malicious activity needs to call out. A default-deny outbound policy with a small allowlist blocks a large share of post-compromise activity and makes SSRF far less useful to an attacker.
7. Secrets belong in a manager such as HashiCorp Vault, AWS Secrets Manager or the cloud equivalent, retrieved at run time, with automatic rotation.
8. Commands to observe: nft list ruleset or iptables -L -n for firewall state, tpm2_pcrread for boot measurements, cryptsetup status for LUKS, docker inspect for container privileges, and kubectl auth can-i --list.

WORDS44.14.6 remember these#

Defence in depth — assume each layer fails — overlapping independent controls so no single failure is fatal.

Segmentation — watertight compartments — dividing networks so compromise does not spread laterally.

Zero trust — being inside proves nothing — architecture where every request is authenticated and authorized on its own merits.

TPM — the small chip that keeps secrets honestly — hardware root of trust storing keys and boot measurements, ISO/IEC 11889.

Measured boot — a signed record of what actually loaded — hashing each boot stage into TPM registers for later attestation.

Egress filtering — controlling what may call out — outbound network policy limiting destinations a host may reach.

Patch window — how long you stay exploitable — time between a fix being published and being installed.

44.15 Detection and response#

PLAIN44.15.1 in simple words#

1. You will not prevent everything. So you must be able to notice, and then act, without making it worse.
2. Logging is recording what happened. Useful logs answer who, what, when, from where, and did it succeed.
3. A SIEM collects logs from everywhere into one searchable place and raises alerts on patterns.
4. Intrusion detection watches network traffic or host behaviour for known bad patterns or unusual activity.
5. A honeypot is a deliberately attractive fake system. Nobody has a legitimate reason to touch it, so any interaction is a real signal.
6. The response process has six steps, and they are always taught in this order: prepare, identify, contain, eradicate, recover, learn.
7. The first hour matters most, and the most common expensive mistake is rushing to clean up before you understand what happened.

PLAIN44.15.2 a picture in your head#

1. Think of a shop after a break-in.
2. The instinct is to sweep up the glass and reopen. That destroys the evidence and tells you nothing about how they got in.
3. The professional sequence is: stop the bleeding, photograph everything, then clean.
4. Containment is boarding up the broken window. Eradication is changing every lock they might have copied.
5. Recovery is reopening. Learning is the meeting where you find out the alarm had been silenced for three months.

Where this comparison breaks: a burglar leaves. An intruder in a network is often still present, watching your response, including your incident channel. That is why serious responses move to an out-of-band communication channel.

PLAIN44.15.3 a worked example#

1. The first hour of a suspected breach, in order.

 0-10 min  Believe it. Start a timestamped written log.
10-20 min  Assemble: security, an owner who can decide, legal.
20-30 min  Contain: isolate hosts from the network,
           but DO NOT power them off. Memory is evidence.
30-40 min  Preserve: snapshot disks, export logs to a
           separate account the attacker cannot reach.
40-50 min  Revoke: rotate credentials, tokens, sessions,
           starting with anything highly privileged.
50-60 min  Scope: what did that identity touch, and when?
           Decide on notification duties and timers.

2. Two rules inside that hour. Do not power a machine off if memory may hold evidence; isolate the network interface instead.
3. Do not discuss the incident on the systems you suspect are compromised. Move to phones or a separate messaging service.
4. What good logging looks like, as fields rather than prose.

5. Add the outcome, success or failure, and a request identifier that follows the request across services. Without that identifier you cannot reconstruct anything in a distributed system.

PLAIN44.15.4 what is really happening inside#

1. Log what matters and only what matters: authentication successes and failures, privilege changes, access to sensitive data, configuration changes, and outbound connections to new destinations.
2. Never log secrets, passwords, full card numbers, tokens or session identifiers. Logs are widely readable and widely backed up.
3. Ship logs off the machine immediately. A log stored only on the compromised host is a log the attacker can edit.
4. Retention is a real decision. Median attacker dwell time before detection has fallen over the last decade but is still measured in days to weeks, so thirty days of logs is often not enough to answer basic questions.
5. Detection tuning is the hard part. An alert that fires fifty times a day is not an alert; it is background noise that teaches people to ignore it.
6. Honeypots and honeytokens are cheap and high signal. A fake credential placed in a document that nobody should use, wired to an alert, tells you the moment someone is looking.
7. Preparation is the step that actually determines outcome: contact lists, decision authority, pre-approved isolation actions, a written plan, and one rehearsal per year.
8. Rehearse with a tabletop exercise. Read a scenario aloud and make people say what they would do. It reliably exposes the missing phone number, the unclear authority, and the backup nobody has tested restoring.

TECHNICAL44.15.5 the engineer’s version#

1. The six-phase cycle is NIST SP 800-61, currently revision 3, published April 2025, which restructures incident response around the Cybersecurity Framework 2.0 functions. The older SANS six-step naming remains common.
2. Detection technologies: network intrusion detection with Suricata or Zeek, host detection with Wazuh or OSSEC, and endpoint detection and response agents for process-level telemetry.
3. Detection rules are shared as content: Sigma for log rules, YARA for file and memory patterns, and Suricata rules for network traffic.
4. Log pipelines in common use: the Elastic Stack, Splunk, Grafana Loki, or a cloud-native pairing such as CloudWatch with Athena. The important property is a separate trust boundary from the systems being logged.
5. Time synchronization is not optional. Without NTP and a single time zone, usually UTC, correlation across systems is guesswork.
6. Forensic preservation order, from most to least volatile: CPU registers and caches, memory, network state, running processes, disk, then archived logs. Capture in that order.
7. Notification timers start whether or not you are ready. GDPR Article 33 requires notifying a supervisory authority within 72 hours of becoming aware. India’s DPDP Rules 2025 require intimation without delay and a fuller report to the Data Protection Board within 72 hours.
8. Tools to observe and preserve: journalctl, auditd with ausearch, dmesg, Velociraptor for remote forensics, and dd or cloud snapshot APIs for disk images. Record hashes of every image you take.

WORDS44.15.6 remember these#

SIEM — one searchable place for all logs — security information and event management with correlation and alerting.

IDS — a watcher for known bad patterns — intrusion detection system, network or host based.

Honeypot — bait with no legitimate use — deliberately exposed decoy whose every interaction is a signal.

Dwell time — how long they were inside unnoticed — interval between initial compromise and detection.

Containment — stopping the spread without destroying evidence — isolating affected systems while preserving volatile state.

Eradication — removing their access completely — eliminating footholds, credentials and persistence mechanisms.

Tabletop exercise — a rehearsal with no machines — discussion-based drill testing decisions and contacts.

44.16 Privacy and the law, briefly#

PLAIN44.16.1 in simple words#

1. Security is about stopping people who should not have access. Privacy is about limiting what you collect and what you do with it, even when you have every right to hold it.
2. You can be perfectly secure and badly privacy-invading at the same time.
3. Personal data is anything relating to an identified or identifiable person. That includes identifiers such as device numbers and addresses, not only names.
4. The core ideas of modern data protection law are short.
5. Have a lawful reason to process. Tell people plainly. Collect only what you need. Keep it only as long as you need it. Keep it secure. Let people see, correct and delete their data.
6. Data minimization is the one engineers control directly. Every field you do not collect is a field that cannot leak.
7. If a breach exposes personal data, you usually have a legal duty to tell a regulator, and often the affected people, on a clock measured in hours.

PLAIN44.16.2 a picture in your head#

1. Security is the lock on the filing cabinet.
2. Privacy is the decision about which forms go into the cabinet in the first place, who may open it and why, and when the papers are shredded.
3. A shop with an excellent safe that photographs every customer and keeps the images forever is secure and privacy-invading.
4. A shop that photographs nobody has nothing to lose in a burglary.

Where this comparison breaks: paper is finite and visible. Digital data is copied silently, spreads into backups, analytics systems and third-party tools, and the copy in the log aggregator is usually the one nobody deleted.

PLAIN44.16.3 a worked example#

1. Two regimes a working engineer meets most often.

2. GDPR fines have two tiers: up to 10 million euro or 2 percent of worldwide annual turnover for most obligations, and up to 20 million euro or 4 percent for the most serious. The higher of the fixed amount and the percentage applies.
3. India’s Digital Personal Data Protection Act was passed in August 2023. The Digital Personal Data Protection Rules were notified on 14 November 2025, with the substantive obligations, including breach reporting and security safeguards, phased in over about eighteen months from that date.
4. Under the DPDP Act, failure to take reasonable security safeguards carries a penalty of up to 250 crore rupees, and failure to notify a breach up to 200 crore rupees.
5. Under the DPDP Rules, affected individuals must be informed without delay, and a fuller report reaches the Data Protection Board within 72 hours.

PLAIN44.16.4 what is really happening inside#

1. The engineering consequences of these laws are concrete, not abstract.
2. You need a data inventory: what personal data exists, where it lives, who can reach it, and how long it stays. Most organizations cannot answer this.
3. You need deletion that actually works, including in backups, search indexes, analytics and every third-party processor.
4. You need to answer access requests, which means being able to find one person’s data across systems.
5. You need to record consent where consent is your lawful basis, including when it was given, for what, and how it can be withdrawn.
6. Pseudonymization replaces identifiers with tokens but remains personal data, because it can be reversed with the mapping table.
7. Anonymization means the person can no longer be identified by anyone, and it is much harder than it looks. Combining a few “anonymous” fields such as postcode, birth date and sex re-identifies most individuals.
8. The cheapest compliance strategy is the same as the cheapest security strategy: do not collect it, and if you must, delete it on a schedule that runs automatically.

TECHNICAL44.16.5 the engineer’s version#

1. GDPR is Regulation (EU) 2016/679, applicable from 25 May 2018. Article 5 sets the principles, Article 6 lawful bases, Articles 12 to 22 data subject rights, Article 25 data protection by design and by default, Article 32 security of processing, Articles 33 and 34 breach notification.
2. Article 33 requires notification to the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in risk. Article 34 requires telling the individuals when the risk is high.
3. The largest single GDPR fine to date is 1.2 billion euro against Meta in May 2023, concerning transfers of European user data to the United States.
4. Other regimes worth knowing by name: the California Consumer Privacy Act as amended by CPRA, Brazil’s LGPD, and sector rules such as HIPAA for United States health data and PCI DSS, currently version 4.0.1, for card data.
5. PCI DSS is a contractual standard, not a law, but it is enforced through card scheme agreements and behaves like one in practice.
6. Technical measures named in practice: encryption at rest and in transit, pseudonymization, access logging, retention policies enforced by automation, and documented data processing agreements with every processor.
7. Privacy and security overlap at Article 32 but are not the same duty. A system can satisfy every security control and still be unlawful because it collects data it has no basis to collect.

WORDS44.16.6 remember these#

Personal data — anything about an identifiable person — includes indirect identifiers such as device and network addresses.

Data minimization — do not collect what you do not need — principle limiting collection to what is adequate and relevant.

Breach notification — the legal clock after an incident — duty to inform regulators and individuals, typically within 72 hours.

Pseudonymization — identifiers swapped for tokens — reversible with a separately held mapping, still personal data.

Anonymization — genuinely no longer a person — irreversible, and much harder than it looks in practice.

Lawful basis — your legal reason to process — one of the grounds required before processing personal data.

Data protection by design — build it in, not on — the requirement to embed protection into system design by default.

44.17 Security for the individual developer#

PLAIN44.17.1 in simple words#

1. Most of what protects you is a short list of habits, not expensive tools.
2. Keep your machine current. Turn on automatic updates for the operating system and the browser.
3. Encrypt the disk. FileVault, BitLocker or LUKS, with a real passphrase.
4. Use a password manager, and put a hardware key or passkey on the accounts that matter most: email first, then code hosting, then cloud.
5. Email first, because email resets everything else.
6. Never commit a secret. Not a token, not a password, not a private key, not a connection string.
7. Assume that anything committed once is compromised forever, even after you delete it, because history is public and cloned within minutes.
8. Keep your dependencies current and know what they are.
9. Read code with security in mind, which is a specific skill, not general attentiveness.
10. And if you find a flaw in somebody else’s software, report it responsibly rather than publishing it or exploiting it.

PLAIN44.17.2 a picture in your head#

1. Think of a workshop. Locked door, tools accounted for, dangerous materials in a cabinet rather than on the bench.
2. Committing a secret is leaving the spare key taped to the outside of the door, then painting over it and believing it is gone.
3. Automated scanners crawl public repositories continuously. Published measurements repeatedly show credentials being found and used within minutes of being pushed.
4. So the moment of exposure is not when someone reads your code. It is when the commit lands.

Where this comparison breaks: a taped key can be removed. A committed secret is in every clone, every fork, every cache, and every scraper’s archive. The only real remedy is revocation and rotation, not deletion.

PLAIN44.17.3 a worked example#

1. Practical checklist, grouped, in the order worth doing it.

2. Secrets handling in practice. Keep values in environment variables loaded from a file that is listed in .gitignore, or in a real secret manager.
3. Commit a .env.example with the names and no values, so the next person knows what is needed.
4. Install a pre-commit hook that blocks obvious secret patterns, and enable push protection on the hosting side as a second net.
5. If a secret is exposed, the order is fixed and not negotiable.

1. Revoke the credential immediately.
2. Issue a replacement and deploy it.
3. Check logs for use of the old one.
4. Only then clean the history, if worth it.

6. Rewriting history is the last step and the least important. The credential is already public; rotating it is what actually ends the exposure.

PLAIN44.17.4 what is really happening inside#

1. Reading code for security means asking a different set of questions from normal review.
2. Where does untrusted input enter, and where does it end up? Trace it from the boundary to every interpreter it touches.
3. Is authorization checked on every path to this object, including the new endpoint added last week?
4. Are errors handled on every branch, and does the failure path fail closed rather than open?
5. Is anything constructed by string concatenation that should be parameterized: SQL, shell commands, HTML, file paths, URLs?
6. Is any cryptography home-made, and is any random value coming from a non-cryptographic generator?
7. Do log statements or error messages contain secrets or personal data?
8. Two kinds of tool help, and they see different things.
9. Static analysis reads code without running it. It finds patterns and scales to every file, at the cost of false positives.
10. Dynamic analysis runs the system and observes it. It finds real behaviour including configuration problems, but only on the paths it exercises.
11. Fuzzing is dynamic analysis with automatically generated inputs, and it is the most effective way to find memory safety and parsing bugs.
12. None of these replaces a person who understands what the application is supposed to protect.

TECHNICAL44.17.5 the engineer’s version#

1. Secret scanning: gitleaks, trufflehog, GitHub secret scanning with push protection, and detect-secrets as a pre-commit hook.
2. Static analysis: semgrep with community rule packs, CodeQL, bandit for Python, gosec for Go, cargo clippy for Rust lints, brakeman for Rails.
3. Dependency scanning: npm audit, pip-audit, cargo audit, osv-scanner, Dependabot or Renovate for automated update pull requests.
4. Dynamic analysis: OWASP ZAP for web scanning, nuclei for templated checks, trivy for container and infrastructure-as-code scanning.
5. Fuzzing: libFuzzer and AFL++ for native code, go-fuzz and Go’s built-in fuzzing since Go 1.18, Atheris for Python, and OSS-Fuzz for open-source projects that qualify.
6. Coordinated disclosure, the correct process when you find a flaw in software you do not own.
7. Look for a security.txt file at /.well-known/security.txt, standardized as RFC 9116 in April 2022, or a SECURITY.md in the repository, or a bug bounty programme.
8. Report privately with enough detail to reproduce. Propose a disclosure timeline. Ninety days is the widely used norm, following Google Project Zero’s policy since 2014, with a shorter clock if active exploitation is observed.
9. Do not test against systems you do not own or have written authorization for. In many jurisdictions, including under India’s Information Technology Act 2000 and the United States Computer Fraud and Abuse Act, unauthorized access is a criminal offence regardless of intent.
10. Request a CVE identifier through the vendor if they are a CVE Numbering Authority, or through MITRE otherwise. Coordinate publication with the fix.
11. If the vendor does not respond, escalate to a national CERT, such as CERT-In in India or CISA in the United States, rather than publishing.
12. Keep a written record of every contact attempt with dates. If disclosure ever becomes contested, that record is what protects you.

WORDS44.17.6 remember these#

Secret scanning — automated hunting for committed credentials — pre-commit and server-side detection of key patterns.

Rotation — replacing a credential — issuing a new secret and invalidating the old one, the only real remedy for exposure.

Static analysis — reading code without running it — pattern and dataflow analysis over source, SAST.

Dynamic analysis — testing the running system — behavioural testing against a deployed instance, DAST.

Fuzzing — throwing generated inputs at it — automated input generation to find crashes and parsing flaws.

Coordinated disclosure — report privately, publish together — agreed process between finder and vendor with a timeline.

security.txt — where to send a vulnerability report — RFC 9116 file at a well-known path listing security contacts.

44.18 Famous breaches and what each teaches#

PLAIN44.18.1 in simple words#

1. Six incidents, chosen because they are well documented and because each fails in a different way.
2. Read them as a list of things that were possible, not as a list of villains.
3. In every one of them, the technical flaw was known and fixable beforehand.

PLAIN44.18.2 a picture in your head#

1. Think of aviation accident reports. Nobody reads them for blame.
2. They are read because one crew’s bad day becomes every other crew’s checklist item.
3. Security has the same discipline available and uses it far less often.

Where this comparison breaks: aviation has a legal duty to publish investigations. Most breach reports are written by lawyers, and the technically interesting details are usually the ones removed.

PLAIN44.18.3 a worked example#

1. The six, with root cause and lesson.

2. Target, December 2013: credentials belonging to a refrigeration contractor reached the payment network because the network was flat. About 40 million card records and 70 million customer records were exposed.
3. Equifax, 2017: a fix for Apache Struts flaw CVE-2017-5638 was available on 7 March 2017. Intrusion began around 13 May and was discovered on 29 July. About 147 million people were affected; the settlement was up to 700 million dollars.
4. WannaCry, 12 May 2017: ransomware using the EternalBlue SMB exploit, for which Microsoft had shipped a patch on 14 March 2017. It reached about 200,000 machines in 150 countries and disrupted parts of the NHS.
5. SolarWinds, disclosed December 2020: the build system was subverted, so the malicious code carried a valid vendor signature. Roughly 18,000 customers installed the trojanized update.
6. Colonial Pipeline, 7 May 2021: a legacy VPN account with a leaked password and no multi-factor authentication. Fuel supply to the United States east coast was disrupted and a 4.4 million dollar ransom was paid.
7. Change Healthcare, February 2024: a Citrix remote access portal without multi-factor authentication. It became the largest health data breach ever reported in the United States, at 192.7 million individuals, with a reported 22 million dollar ransom payment.

PLAIN44.18.4 what is really happening inside#

1. The lessons, one line each, in the same order.
2. Target: a supplier’s access is your access. Segment the network so a contractor’s account cannot see a payment terminal.
3. Equifax: the gap between a patch existing and a patch being installed is the whole vulnerability. Measure that gap in days.
4. WannaCry: a patch you did not deploy is a patch you did not have. And a flat internal network turns one infection into all of them.
5. SolarWinds: a valid signature proves who built it, not that the build was honest. Protect the build system as tightly as production.
6. Colonial Pipeline: every remote access path needs multi-factor authentication, including the old one nobody uses.
7. Change Healthcare: the same lesson again, three years later, at a much larger scale. This is the single most repeated root cause in the record.
8. The pattern across all six is dull and consistent. Known flaw, known fix, missing basic control, insufficient segmentation.
9. Not one of them required a novel attack technique.

TECHNICAL44.18.5 the engineer’s version#

1. Detection times are the other lesson. Equifax ran for roughly 76 days before discovery. The Codecov modification ran for 60 days. The SolarWinds implant ran for months before Mandiant identified it in December 2020.
2. Notable data-handling failures worth naming separately, because they are about storage rather than intrusion.
3. RockYou, December 2009: 32 million passwords stored in plain text. The resulting list is still the standard wordlist in password auditing tools.
4. LinkedIn, June 2012: 6.5 million password hashes leaked, SHA-1 with no salt. The full set later proved to be about 117 million accounts.
5. Adobe, October 2013: about 153 million records, passwords encrypted with 3DES in ECB mode rather than hashed, with plaintext password hints alongside. Identical passwords produced identical ciphertext.
6. Yahoo, breaches in 2013 and 2014 disclosed in 2016 and 2017: 3 billion accounts, with MD5 hashing on a portion of them.
7. Each of those is a direct illustration of section 44.3. Plain text, fast unsalted hashes, and encryption used where hashing was required.
8. For breach data, the checkable public sources are the Have I Been Pwned service, the annual Verizon Data Breach Investigations Report published each spring since 2008, and the United States Department of Health and Human Services breach portal for health-sector figures.

WORDS44.18.6 remember these#

Root cause — the thing that actually let it happen — the earliest correctable failure, not the final symptom.

Dwell time — how long they stayed unnoticed — interval from compromise to detection, often weeks.

Lateral movement — spreading sideways once inside — using one foothold to reach further systems.

Flat network — everything can reach everything — an unsegmented network where one compromise exposes all.

Patch gap — the window between fix and install — the period during which a known, fixed flaw remains exploitable.

Third-party risk — their weakness becomes yours — exposure arising from suppliers, contractors and integrations.

44.98 Common wrong ideas#

1. Wrong: we are too small to be a target. Right: most attacks are automated and indiscriminate. Scanners find every internet-facing service within hours, and ransomware crews prefer small organizations because they pay faster and have weaker controls.
2. Wrong: the padlock in the browser means the site is safe. Right: it means the connection is encrypted to whoever holds a valid certificate for that name. A phishing site can obtain one for free in minutes. It says nothing about who runs the site or what they do with your data.
3. Wrong: antivirus protects me. Right: signature-based scanning misses new, repacked and fileless malware, and cannot judge whether a legitimate administrative tool is being misused. It is one useful layer among several, not a boundary.
4. Wrong: open source is less secure because anyone can read the code. Right: visibility helps defenders more than attackers, since attackers can analyze closed binaries too. The real open-source risk is different: unpaid, unsupported maintainers of critical components, which is exactly what the xz-utils backdoor exploited in 2024.
5. Wrong: a strong password is enough. Right: length and randomness do not help if the password is phished, reused on a breached site, or stolen by malware. Phishing-resistant multi-factor authentication is the control that changes the outcome.
6. Wrong: encryption solves security. Right: encryption protects confidentiality in transit and at rest. It does nothing about broken access control, injection, social engineering, or an attacker using your own application while it is unlocked and running.
7. Wrong: we passed a penetration test, so we are secure. Right: a test is a sample of one moment by one team within a fixed scope. It shows what was found, not what exists.
8. Wrong: internal systems do not need the same protection. Right: that assumption is exactly what turned the Target and WannaCry incidents into catastrophes. Assume the attacker is already inside and design accordingly.
9. Wrong: hashing a password with SHA-256 is fine because SHA-256 is secure. Right: SHA-256 is secure as a hash and terrible as a password function precisely because it is fast. Use Argon2id, scrypt or bcrypt.
10. Wrong: we have backups, so ransomware cannot hurt us. Right: modern ransomware finds and deletes backups first and steals the data before encrypting, so publication remains a threat. Backups must be tested, versioned and beyond the reach of production credentials.

44.99 Chapter summary in 20 lines#

1. Security is five promises about data: confidentiality, integrity, availability, authenticity and non-repudiation, always in trade-off.
2. It is a property of a whole system in a context, never a product you buy.
3. Threat modelling is three questions: what am I protecting, from whom, and what happens if I fail. Rank the answers by likelihood times impact.
4. A hash is a one-way fingerprint. MD5 fell to collisions in August 2004 and SHA-1 to the SHAttered attack on 23 February 2017. Use SHA-2, SHA-3 or BLAKE3, and never a bare hash for passwords.
5. Store passwords with a deliberately slow, memory-hard function: Argon2id at 19 MiB with two passes, scrypt, or bcrypt at cost 10 or above, always with a unique per-user salt and ideally a separately stored pepper.
6. NIST SP 800-63B revision 4, published 31 July 2025, forbids composition rules and routine expiry. Length beats complexity, and a manager beats both.
7. Symmetric encryption must be authenticated. Use AES-GCM or ChaCha20-Poly1305, never ECB, and never reuse a nonce with the same key.
8. Asymmetric cryptography solves key agreement and gives signatures, which prove origin and integrity in a way encryption alone never does. Every real system is hybrid: asymmetric once, symmetric thereafter.
9. NIST approved ML-KEM, ML-DSA and SLH-DSA as FIPS 203, 204 and 205 on 13 August 2024, and selected HQC as a fifth algorithm on 11 March 2025. Harvest-now-decrypt-later makes key exchange migration urgent today.
10. Authentication factors are not equal. SMS is weak, app codes are relayable, and only FIDO2 and passkeys resist phishing by binding to the origin.
11. Authorization is a separate question from authentication, checked on every request, at the data layer, with least privilege and deny by default.
12. Broken Access Control has been number one in the OWASP Top 10 in both the 2021 and the current 2025 edition, which was presented on 6 November 2025.
13. Injection is fixed by construction with parameterized queries and argument arrays, never by filtering. Cross-site scripting is fixed by contextual output encoding plus a strict Content Security Policy.
14. Memory safety bugs have been roughly seventy percent of the vulnerabilities at major vendors. Canaries, non-executable memory, ASLR and control flow integrity raise cost; memory-safe languages remove the class.
15. Network defence rests on TLS against interception, DNSSEC and encrypted DNS for name lookups, and rate limiting, filtering, anycast and scrubbing against floods that now exceed 30 terabits per second.
16. Most intrusions begin with a person or a stolen credential, not an exploit. Business email compromise alone cost 3.04 billion dollars in 2025.
17. Your dependencies are your attack surface. Use lock files, pin by digest, generate SBOMs, and require signed provenance. Remember that xz-utils in March 2024 was caught by one engineer noticing half a second of CPU time.
18. Defend in depth: segment, patch fast, encrypt disks, sandbox, and give everything the least privilege it can function with.
19. Prepare for the incident you will have. Log the right fields off-host, rehearse once a year, and in the first hour contain without destroying evidence, preserve, revoke and scope before you clean.
20. Every famous breach in section 44.18 had a known flaw and an available fix. The advantage is almost never in exotic defence; it is in doing the dull things quickly and everywhere.