Computer Security

Computer security is what has to be added once the distributed systems from the previous topic turn a collection of trusting, communicating machines into something an attacker can also reach, and every layer of this series so far — hardware, networks, databases — is also exactly what has to be defended. Threat modeling comes first, before a single line of defensive code gets written: it is the requirements-gathering discipline from the software-engineering topic turned adversarial, systematically asking not just "what should this system do" but "what could go wrong, and who would benefit from making it go wrong" for every piece of the system being built. Secure programming is what threat modeling feeds into: writing code that doesn't hand an attacker capabilities it never intended to, like always using the parameterized, placeholder-based queries this series' own database-deploy scripts rely on instead of pasting raw text directly into a SQL query, which closes off SQL injection, one of the most common real-world vulnerabilities, at the source. Authentication is how a system verifies who is actually making a request — a password, a cryptographic key, a fingerprint — and it answers a narrower question than it might seem: not "is this person trustworthy" but simply "is this really who they claim to be," the same identity-check spirit behind the SSH key pairs this series' own deploy process authenticates with on every single connection to a production server. Authorization is the separate question of what an already-authenticated identity is actually allowed to do, and the two are easy to conflate but matter differently: this series' own database access uses a narrowly scoped application account that can only read, insert, and update specific tables and is deliberately denied permission to delete or drop anything at all, so that even if that one account's credentials were ever misused, the damage it could do is capped by design — a principle called least privilege. Cryptography protects data itself rather than deciding who can touch it: encryption scrambles data so that anyone intercepting it over the network from the computer-networks topic — including the HTTPS connection carrying this very article to a reader's browser right now — sees only unreadable noise without the correct key, and a well-designed system never stores a password directly either, only a one-way hashed version, so that even a stolen database reveals nothing usable. None of these five pieces substitutes for any other — strong cryptography protecting data sent by code riddled with injection bugs is a false sense of safety, and airtight authentication is worthless if authorization hands every logged-in user permission to delete the entire database — and the next topic, mathematics for advanced computing, is what actually makes modern cryptography possible in the first place, the number theory and modular arithmetic underneath algorithms like RSA.

Threat modeling
before building anything: what could go wrong, and who benefits
Secure programming
build defensively — e.g. parameterized queries, not string-pasted SQL
Authentication
at request time: verify this identity is who it claims to be
Authorization
decide what that verified identity is actually allowed to do
Cryptography protects the data throughout
in transit over the network, and at rest in storage
Authentication vs. Authorization Two different questions, easy to conflate Authentication "is this really who they claim to be?" a password, a cryptographic key, a fingerprint — proof of identity Authorization "what is this verified identity allowed to do?" read-only, read-write, or full administrative access Least privilege, in practice a well-designed application account can be authenticated correctly, yet still be authorized for only read/insert/update — never granted permission to delete or drop anything at all
Cryptography and Secure Programming, Together Protecting data, and refusing to hand over control Encryption in transit HTTPS scrambles this very article on its way to you an eavesdropper on the network sees only unreadable noise Passwords, hashed not stored only a one-way hashed version is ever kept a stolen database still reveals no usable passwords Secure programming: SQL injection, closed off unsafe: pasting user input directly into a SQL string safe: a parameterized query with a placeholder for the value this series' own database inserts use parameterized queries throughout, specifically to avoid this exact vulnerability

Take computer security further

Ask the copilot about this term, or have our engineers assess it against your process.