Computer Security: Thinking Like an Attacker

A note on safety and law: this piece explains how attacks work so that people can defend against them. It gives no recipes. Only ever test systems you own or have written permission to test; breaking into other people's computers is a crime in most places.

In 2017 the credit bureau Equifax lost the names, birth dates and Social Security numbers of about 148 million people. No spy movie was involved. A known flaw in a piece of software had a fix available for months, and the fix had not been installed.

That is the first thing a security graduate learns to see: most disasters are not brilliant. They are a door that someone forgot, a password that was never changed, a trust that was never checked. The second thing is harder. You cannot defend a system by asking what could go wrong. You have to ask what a patient, lazy, clever stranger would do first.

What "secure" means: confidentiality, integrity, availability

Security people check three properties, called the CIA triad. Confidentiality: only the right people can read it. Integrity: it cannot be changed without being noticed. Availability: it works when needed. Each can be attacked on its own. A leaked database breaks confidentiality. A forged bank transfer breaks integrity. A ransomware attack, which locks your files until you pay, breaks availability, and denial-of-service floods do the same by overwhelming a site with traffic.

The triad also reveals trade-offs. A system that nobody can read is perfectly confidential and completely useless. Making something more available (more copies, more access points) can make it less confidential. Good security is not "as locked down as possible". It is choosing which property matters most for each asset, then spending effort there.

Thinking like an attacker: threat modelling

Threat modelling is the habit of asking four questions before building: what are we protecting, who might want it, how could they reach it, and what will we do about it? Microsoft engineers Loren Kohnfelder and Praerit Garg described a well-known checklist in 1999, called STRIDE: spoofing (pretending to be someone), tampering, repudiation (denying you did something), information disclosure, denial of service, and elevation of privilege (gaining powers you shouldn't have).

The most useful single idea comes from drawing the possible paths to the goal and noticing that an attacker is lazy. They do not attack your strongest lock. They take the cheapest path. Your system is as strong as its easiest door.

Raise the cost of guessing the password to 10 and nothing changes: the attacker was never going to guess. The money is better spent on the cheapest door, and here it is the human one. This is why security engineers talk about people as a part of the system, not as the problem.

Passwords: hashing, salt and why length wins

A well-built site does not store your password. It stores a hash: the output of a one-way function, a scrambled fingerprint from which the password can't be run backwards. When you log in, it hashes what you typed and compares. If the database leaks, the attacker gets fingerprints, not passwords, and has to guess: hash a candidate, see if it matches.

Two details make or break that. First, the hash must be slow on purpose. General-purpose hashes such as SHA-256 or MD5 are designed to be fast, which helps attackers test billions of guesses a second on graphics cards. OWASP's guidance names purpose-built password hashes (Argon2id first, then scrypt, bcrypt and PBKDF2) that are slow and use lots of memory. Second, each password needs a salt: a random value, unique to each user, mixed in before hashing. Without it, identical passwords give identical hashes, and an attacker can precompute a table of common passwords and look up every user at once.

The second thing that matters is length. The number of possible secrets is the size of the alphabet raised to the length, so adding characters multiplies the work. But this only holds when the secret is random. People are not random, which is why attackers try breached passwords and dictionaries before brute force. It is also why NIST's revised guidance (SP 800-63B, revision 4) calls for checking new passwords against lists of common and breached ones, for at least 15 characters when a password is the only factor, and against forced composition rules and routine expiry.

With these settings, 8 random keyboard characters fall to a stolen fast-hash file in about 8.5 hours on average, but 12 take around 75,000 years. Six random common words, a passphrase you can actually remember, are about as strong as 12 random symbols. Against a slow hash, even the 8 characters last about 9,700 years. Length and slow hashing together are doing the work.

The last piece is multi-factor authentication: proving you are you with two of three things: something you know (a password), something you have (a phone or hardware key), something you are (a fingerprint). Then a stolen password alone is no longer enough. Not all second factors are equal. Codes sent by text or typed from an app can be relayed by a fake site in real time. Methods based on FIDO2/WebAuthn, such as passkeys and hardware keys, tie the login to the real site's address, so a lookalike can't use them.

Encryption: in transit, at rest, and who holds the key

Encryption turns data into something unreadable without a key. Symmetric encryption (AES is the standard) uses one shared key for both locking and unlocking, and is very fast. Public-key encryption (see Cryptography, 12/09) uses a public key to lock and a private one to unlock, which solves the problem of sharing a key with a stranger, but is much slower. Real systems use both: public-key maths to agree on a secret, symmetric encryption to carry the data. That is exactly what happens when your browser shows a padlock.

TLS, the protocol behind that padlock, is defined for its current version 1.3 in RFC 8446 (2018). Step through what happens in the first fraction of a second.

Encryption in transit protects data while it moves, from the cafe wifi owner or anyone on the path. Encryption at rest protects stored data, such as a laptop disk or a database file. They defend against different attackers, and neither defends against everything:

Attacker	In transit (TLS)	At rest (disk)
Reads traffic on public wifi	Stopped	No effect
Steals a powered-off laptop	No effect	Stopped
Has taken over the server while it runs	No effect	Usually no effect: the system holds the key to use the data
Tricks you into logging in on a fake site	No effect: the connection to the fake is encrypted	No effect

The pattern: encryption is only as good as the place the key lives. A locked safe with the key taped to it is not a safe. Much of practical security is key management.

The common ways in

Attackers have a short list of favourite moves, which security courses teach by class, not by tool.

Social engineering and phishing attack the person, not the machine: a message that looks like it comes from your bank, your boss or IT, urging you to hand over a password or click. It works because it uses urgency and trust, not technical flaws.

Injection happens when a program builds a command by gluing in text from a user, and the system cannot tell where the programmer's instructions end and the user's data begins. The cure is to keep them apart. See it with a harmless name.

Buffer overflow and its relatives are memory errors. In languages like C, a program that copies more data into a fixed-size space than fits spills into neighbouring memory, which can corrupt the program or even change what it does. The defences are checking lengths, using memory-safe languages, and operating-system protections (the subject of Operating Systems, 34/26). Misconfiguration is the plainest class: a default password left on, a storage bucket left public, a test account never removed. Coverage of OWASP's 2025 Top 10 list reports that security misconfiguration rose to second place.

Least privilege and defence in depth

Two principles, both old, do much of the work. Saltzer and Schroeder's 1975 paper "The Protection of Information in Computer Systems" set out design principles still taught today, including that access should be denied unless explicitly granted (fail-safe defaults), that every access should be checked (complete mediation), that designs should be simple (economy of mechanism), and that security should not depend on keeping the design secret (open design). Least privilege, the idea that every program and person should have only the access they need, belongs with them. If a clerk's account is stolen, the thief gets a clerk's powers, not the whole company's.

Defence in depth means stacking independent protections so that one failure is not fatal. If each layer stops 70% of attacks, three layers let through 0.3 × 0.3 × 0.3 = 2.7%. But the arithmetic hides a trap, and it is the same one as in Systems Engineering (34/22), where two redundant units running identical software failed together. If some attacks go around every layer at once (a stolen administrator password, an insider), the layers are not independent.

With three layers at 70% each and a 5% common weakness, about 7.6% get through, nearly three times the independent figure. Adding a fourth layer barely helps; closing the shared weakness does. That is why security teams hunt for the single point that all layers depend on.

How real breaches happened

Each case below is well documented, and each is less exotic than it sounds.

Case	What happened	The lesson
Morris worm, 1988	On 2 November 1988 a Cornell graduate student released a self-copying program. It used a memory overflow in the finger service, a debugging hole in the mail program, trusted logins and weak passwords. A flaw in how often it re-infected machines made them unusable.	Several small flaws combined; a bug in the attacker's own code did the damage. It led to the creation of CERT/CC at Carnegie Mellon.
Heartbleed, 2014	OpenSSL's heartbeat feature did not check the length of a request, so a caller could read up to 64 KiB of the server's memory per request, which could include keys and passwords. The flawed code had shipped for about two years (CVE-2014-0160).	A missing bounds check in a trusted library. Even the encryption layer is software.
Equifax, 2017	Attackers used a known flaw in Apache Struts for which a patch had been released on 7 March 2017. About 147.9 million Americans were affected, and the breach went unnoticed for 76 days, until an expired certificate on a monitoring tool was renewed.	Patching and monitoring are security controls. In 2019 Equifax agreed to pay at least $575 million in settlements.
Colonial Pipeline, 2021	Reporting says attackers used a compromised password for an old VPN account with no multi-factor authentication. The company shut down pipeline operations as a precaution; the ransomware hit business systems.	One account without a second factor was the door. The harm was to availability.

Notice what the lessons have in common: patching, passwords, a missing check, an unmonitored door. The security course teaches the cryptography and the attacks, but what graduates remember is that organisations fail at the basics, and that attackers are happy to wait for them to.

What a graduate just sees

• Security is three properties (confidentiality, integrity, availability), and they pull against each other.
• The attacker takes the cheapest door, so the weakest link is the only one that counts.
• A password is never stored; a slow, salted hash of it is, and long beats clever.
• Encryption is only as good as the place its key lives.
• If a program mixes user data into its commands, someone will eventually use it as a command.
• Give every person and program the least access that works.
• Layers are only independent if they don't share a weakness.
• Most breaches are boring: unpatched software, reused passwords, no second factor.
• Assume breach, and make sure you can detect it.

Where it shows up next

• Operating Systems (34/26) and Computer Networks (34/27) are the ground security stands on: permissions, memory protection, protocols. The padlock above is a networking story.
• Software Engineering (34/31): code review, testing and postmortems are the main defences against the flaws above.
• Systems Engineering (34/22): the same thinking applied to hardware: interfaces, single points of failure, redundancy that isn't independent.
• Cryptography (12/09) for the maths of the keys; Databases (34/28) for where injection and access control meet.
• In the real world: security engineer, penetration tester, incident responder, and every developer who writes a login form.

If you want to go deeper

• 📘 Computer Security: Principles and Practice, William Stallings and Lawrie Brown (Pearson, 4th ed., 2018): a standard university textbook.
• 📘 Security Engineering, Ross Anderson (Wiley, 3rd ed., 2020): the broad, readable bible of the field, available from the author's site.
• 📘 The Cuckoo's Egg, Cliff Stoll (Doubleday, 1989): a gentle true story of tracking an intruder through a university network.
• 🌐 MIT OpenCourseWare 6.858, Computer Systems Security (Fall 2014, Nickolai Zeldovich): free lectures, notes and labs; graduate level, so it is demanding.
• 🌐 Harvard's CS50 Introduction to Cybersecurity: a free, beginner-friendly online course.