Chapter 6 · 1988–1996

The tunnel and the ticket

The network multiplied the doors. Two answers appeared: carry a ticket so your password never travels, or tunnel your laptop 'inside' the walls.

The moment computers talked to each other, the password had a new problem: it had to travel. On a single machine, the secret never left the room. On a network, proving yourself to a distant server meant sending something across wires other people could tap — and early protocols cheerfully sent passwords in the clear, readable by anyone with the patience to listen. The doors multiplied, and now the keys were being shouted down hallways.

Two answers appeared in the late 1980s and 1990s, and they seed the two halves of the “managing the access” branch.

The first came out of MIT again, from Project Athena, and it’s quietly one of the most important protocols you’ve never heard of: Kerberos. Its insight is that your password should never cross the network at all. Instead, you prove yourself once to a trusted authority — a central server that knows your secret — and it hands you a time-limited ticket. From then on you present tickets, not passwords, to everything else; the tickets expire on their own; the services never see your secret. This is single sign-on’s grandfather, and it is not a museum piece: Kerberos is the authentication engine inside every Windows corporate domain since 2000. When a hundred million office workers log in each morning, they’re using a 1988 MIT research project.

The second answer was blunter and became the defining metaphor of an era. If the danger is the network between you and the trusted inside, then encrypt a tunnel and make the remote laptop be inside. The VPN — PPTP in the mid-90s, then IPsec — put a cryptographic sleeve around the connection so a working-from-home engineer sat, as far as the servers were concerned, in the building. This is the castle-and-moat model, and it ran enterprise security for two decades: build a hard perimeter, let the VPN be the drawbridge, and trust everything inside the walls.

Play the model below and watch where it breaks. Castle-and-moat makes one enormous assumption: that inside equals safe. Everything within the perimeter is trusted, so security concentrates entirely on the wall. It works right up until an attacker gets in — a phished laptop, a contractor’s weak password, a compromised VPN credential — and then the assumption inverts catastrophically. Once inside, they’re trusted like everyone else, free to move sideways from the mailroom laptop to the domain controller with nothing else in the way. The moat that kept them out now hides them in.

That flaw is the seed of chapter 10, where a freshly-breached Google concludes the moat itself is the problem and deletes it. But that’s a decade off. First the “managing the access” branch has to build the machinery that makes trust portable — a single corporate identity for each person (chapter 9’s directory), and then a way to carry that identity across company lines (federation). Because the tunnel solved distance. It did nothing about scale — the coming reality where you don’t log into one server but into fifty different companies’ web apps before lunch, and no VPN reaches any of them.

Meanwhile the other branch has its own answer to the network’s danger, and it’s more personal: stop relying on the secret alone. Add a factor the attacker can’t phish down a wire — something you physically hold. That’s the plastic keyfob of chapter 7, and it’s where “proving the person” begins.