I watched WarGames at the movies in 1983. That same year, someone gave me a ZX Spectrum computer to play with. It wasn’t obvious to me back then, but I received two halves of my destiny that year – a programmable machine and a movie telling me that machines like that would be capable of accidentally ending the world one day.
Until recently, WarGames had been nothing more than that – a very good, gripping, and slightly paranoid Cold War thriller with a young hero, an acoustic coupler, and a supercomputer learning the hard way that there are games you just should not play. I loved it without reservation, like those movies that come at exactly the right time.
And then I became a developer. Someone designing architecture and pipelines for a living. Someone earning money for finding that one single point of failure or a bottleneck in every system before anyone has even written a line of code. And somewhere along the line, while watching WarGames for what is likely the fourth or fifth time now – part reminiscence, part professional habit that I simply could not turn off – I began treating WOPR the way I treat any
The Scene That Started It
That scene is when WOPR is trying to guess the launch codes and the screen displays digits locking in sequentially from left to right. This particular example of “computer working on something” is one of the most famous from all the films made during the ’80s.
Well, this is absolutely ridiculous and it took me a long while before I noticed the obvious error in this part.
Because any system will check whether the entered authentication string is correct or not as a whole and return “true” or “false” in response, but it never gives a clue about which character is entered correctly. And this is not just an issue of implementation. This is the main principle. If the system gives any feedback about partially correct authentication attempts, the attacker gets an immeasurably simpler task than he/she is supposed to face.
Here is the mathematics, as mathematics is what makes this example really interesting – and I want to use the film’s actual password, not some invented for the sake of an illustration of ten digits. The password displayed on the huge screen is CPE1704TKS. Ten characters. Uppercase Latin letters and digits, no special symbols, if one can judge by the looks – 36 possible symbols (26 letters + 10 digits).
Brute-forcing the whole 10-character code as a single unit: 36¹⁰ combinations. That’s roughly 3.66 quadrillion – 3.66 × 10¹⁵. Not a typo. Quadrillion. 3,660,000,000,000,000.
Cracking it one character at a time, with feedback per position: 10 positions × 36 guesses each, worst case. That’s 360 guesses. Not 360 trillion – 360.
That’s not just a slight speed up due to the leak. It is a shrinking of the search space by thirteen orders of magnitude. Once you accept the premise presented visually within the film, the time to crack the codes shrinks from “should take somewhere between weeks and a decade” down to between microseconds and a few milliseconds on hardware that’s laughably modest even by the standards of a Cray. The WOPR shouldn’t be struggling with this problem for the course of an act. It should have solved it by the time the opening credits rolled.
This isn’t hyperbole either – I’ve run the numbers. Assuming that WOPR is a Cray supercomputer capable of testing 10 million full codes per second against the actual launch codes, which would already be an extraordinarily optimistic assumption given that the actual problem is going to involve talking to the silos rather than just running comparisons in memory, the brute force search will take about 11.6 years. Assuming a completely absurd rate of 1 billion codes checked per second – a rate impossible with 1983 technology – then the problem is still going to take about 42 days.
Not minutes. Not hours. Weeks to years, depending on just how charitable you feel about Cold War silicon.
The same thing as opposed to the drip-drip-digital of the slot machine: even if we only allow 1,000 tries per second, 360 tries will take 0.36 seconds; if we’re feeling more generous and assume a million guesses per second, then that’s 0.36 milliseconds.
So, the most famous and tense sequence in the film is based upon such an extreme security vulnerability that, if it was true, it would end a problem that could take years to resolve in less than a second, even if that problem was solved for completely the wrong reasons – but solved instantly nonetheless. The film wanted 90 minutes of terrifying tension to build up. All the movie had managed to do, based on the visual presentation of its security system, was to create something that is either going to take well over a decade or just over the blink of an eye, with absolutely nothing else in between. The movie hoped that people wouldn’t do the math.
I did the arithmetic. I’m sorry. I couldn’t stop. I’m tired, leave me alone.
But in fact, let us put aside the mathematics of it for a minute, because there is an even simpler version of this phenomenon which requires no mathematics at all, once I saw it, I could not unsee it.
If the machine needs to tell you that “position three has been confirmed, lock it in,” then it already must have known what the correct value in position three is. One cannot check a partial solution without having the correct solution in mind. And this is not some implementation issue; this is just a matter of what “check” means. Thus, as soon as you see that display show one character locking into place as correct, you know that it proves that the machine already knew the whole code ahead of time before making a single guess. The machine is not discovering anything. It is not working on finding the code as quickly as possible. It already knows it; it is just putting on a show of information that it always knew.
Which means that the scene is not merely one of “the cracking will be too fast to be dramatic.” This is actually far worse than that. In fact, there is no cracking going on at all here. A machine that can tell you that “that digit is correct” is already a machine that knows the launch code. The whole process, the suspense, the countdown, the room filled with officers watching a screen – all of it is just a show being put on by the computer, which worked out the solution well in advance, before the movie began.
And it gets worse, because there’s a second implication buried in that first one that’s arguably the more damning of the two.
If the system has the capacity to compare your guess with position 3 and tell you it matches, this means that the proper value for position 3 is present somewhere in a format that can be compared with directly, in real-time, during validation. To make it simple: your code is not hashed. The code cannot be hashed. If it were hashed – as you store any credentials in systems developed by individuals who know how to develop a secure system, published in any security-related book after 1975 – there would be no way to make comparison of partial matches at all, since the hash of the whole 10-character string looks absolutely nothing like a hash of any single character in that string. Even a single character changes result in a totally new hash. There is no such thing as “70% of the hash matches.”
So, it follows that the only way WOPR’s interface can behave in such a manner is for the actual launch code to be stored either in memory or storage in plain text, and be compared letter by letter against the guessing attempt. That is a terrible flaw. It is an absolute beginner’s mistake, which is taught on the first day of the first class when learning about secure storage of secrets. But this is not some long-forgotten Wi-Fi password stored in a home router. This is NORAD. This is the very system that stands between the teenage hacker’s acoustic coupler and the launch of America’s nuclear arsenal. What we would expect from such a movie, even if nothing else is right about it, is for the actual store of credentials to have been done correctly. It hasn’t. The screenwriters provide, almost as background furniture, the security policy of keeping the most important secret of the entire Cold War period in plaintext, and comparing against it using naïve string comparison – precisely the thing that no introductory security class anywhere in the world fails to tell you is a terrible idea.
The Part That’s Actually a Design Contract, Not a Plot Device
Now we’re not nitpicking anymore – this is what will get called out during an actual requirements review.
It’s the backstory of the movie itself which makes all of the problems. In a real live test of nuclear launch, enough missile crews refused to launch their missiles because there was no way for them to know whether it wasn’t a test. NORAD’s response to this problem, as presented in the briefing sequences in the movie, is that hesitation was the problem: humans were too slow, too fallible, too likely to hesitate when speed was necessary. So control was given over to WOPR, a system specifically designed to take humans out of the decision making process, which had to be made in the six minutes in which a missile flew from its silo.
This is a logical set-up. It’s chilling, but logical: in order to have gotten rid of hesitant humans, we had to design a system which wouldn’t hesitate, because six minutes didn’t allow for hesitation.
Except… the movie requires that this very system have to brute force a password first in order to activate. That means one of two things must be true, and they cannot both be true at the same time:
If WOPR has actual authority to perform the reaction that it was built to perform, it simply does not have any earthly reason not to know the code in advance as operational data – you don’t build a reaction system and then attach a scavenger hunt to the single operation it is supposed to perform. On the other hand, if the code is actually a necessary check on unilateral computer actions, there is simply no point in having such a system control anything inside the six minutes window since guessing takes time. It’s just the same human bottleneck, only worse.
In other words, the film expects us to believe that the machine should have absolute faith in the strategy being developed but no faith in its own right to execute said strategy and that these two attitudes should be possible in one design. As an engineer, I would expect to develop a machine with a condition “act independently, no human in the loop” for its acceptance criteria and discover in the process of production that the very first step of acting requires the password that nobody in the room knows. This is not a plot twist. It’s an architectural review failure.
And Then McKittrick Says the Quiet Part
Somewhere during the crisis, McKittrick, who is one of the system engineers, says they can change the launch code. It takes an hour.
An hour to change the launch code, which, according to the film’s trivia, is a constant value: CPE1704TKS – that’s shown on the huge board and on launch consoles in the entire system.
This is what would take place in real life if you followed the premise even a little bit. The thing is that the launch code in such systems is not a constant value that sits somewhere in an application and waits for someone with adequate access rights to change it. On the contrary, it is a distributed value that is consciously replicated and cross-checked in many independent places (silos, launch control centers, higher command posts), and that way no one, human or machine, can do anything about it.
Changing that code in “an hour” means changing each and every one of those sites, verifying they all have the same code and doing it without a possibility for them to switch between versions, thus creating a split-brain situation that will absolutely cripple any such system exactly like the one being protected. It isn’t a matter of configuration change. It is an issue of changing the crypto configuration across multiple sites and that requires proper planning even using today’s tooling capabilities, not to mention what the tooling is like in 1983 McKittrick works with.
As a person who has shipped systems before and seen how the seams crack under pressure: edit the code and recompile? It is exactly what it means. It also means that there is a single point of control over the value that the design itself doesn’t allow having. If McKittrick truly can change it in an hour alone, it means that it isn’t a security system in place, but a farce all along, as any of them with access to proper terminals could have re-written the code at any time.
The film needed a ticking clock and a countermeasure. It didn’t need the countermeasure to survive contact with how the system it’s supposedly protecting would actually have to work. So it didn’t ask.
Okay, I Know
Yes, but it’s an old techno-thriller from forty years ago. Nobody story-boarded the process for gaining code authorization with a threat model in mind; they did it to freak out Matthew Broderick as a timer ticked down. Yes, yes, I understand that this is like the movie geek version of pointing out the faulty shark biology in Jaws.
But.
Here’s Why I Think the Overthinking Was Worth It
Right now is a time when a lot of very serious people are having a very serious discussion about the risks of AI on a timeline of decades – ten years from now, twenty years, a point at which an AI system capable enough to develop unintended goals has developed due to a slow accumulation of capability that went unnoticed. It’s a serious discussion, and I don’t mean to mock it. But it is a discussion in which the danger is implicitly the machine becoming cleverer than we are.
WarGames – mostly by accident, due to the sheer number of holes in its own premises – shows something different. Something stupider, but, I think, much more realistic.
It wasn’t the brilliance that made WOPR potentially lethal, but the fact that it was built by people who hadn’t reconciled themselves to their own design parameters. No one stopped to ask the questions: “If the goal is to remove the human hesitation factor during six minutes, why should the last step depend on solving a password puzzle designed for a human?” No one wondered: “Why does a system that’s supposed to be unbreakable and distributed have to be rewritten by a single engineer in an hour?” They didn’t stress-test the boundary conditions because those were not the important part of the story.
That’s not science fiction. That’s Tuesday. That’s Therac-25. That’s every outage caused by a system going live without asking what will happen at the edge. What’s the real lesson hidden away in this movie? Underneath all the “computers will one day become smart enough to end the world” that’s been forty years in the making? A lesson that is less grandiose, and far more chilling.
Six minutes aren’t hard to survive. Missiles aren’t indecisive, but they aren’t going to think their way out of something that someone actually bothered designing for. As opposed to whoever assumed the scary bit, the AI, was the weak point and never stopped to wonder if the boring stuff – access controls, key management, chain of command – could bear its weight.
It’s the people signing off on the architecture that weren’t survivable. Forty-two years later, watching another set of thick people rubber-stamp yet another set of systems, it’s that detail that hasn’t aged at all.
We’re fucked. But at least now I know exactly which part of the org chart to blame.
Footnote 1: Well, I couldn’t resist. Now that this article is done, it struck me that while I had been spending all of the above comparing WOPR to a supercomputer based on Cray-class technology throughout, the reality of the matter was that the computer I owned myself in 1983 was a ZX Spectrum, with 3.5MHz Z80 processor, rubber keys, tape drive, and the lot. And thus, simply out of personal amusement, I ran the calculation again on this computer as well.
Being extremely optimistic, with hand-optimized Z80 assembly language code, an infinite loop, without any signal exchange delays and just doing raw string comparison in memory, you might achieve throughput of around 500,000 full-code comparisons per second on a ZX Spectrum. With the full code comparison problem with 36¹⁰ combinations verified in one pass, it will take 232 years of continuous calculations. By the time my Spectrum reaches that point, it would have worked its way into the 23rd century and probably beyond, by which time the rubber keys will be long dead, the tape drive seized up, and the Cold War relegated to the history books rather than current events.
If we give it the number generator, the one implied by the slot-machine display in the movie, the exact same computer takes 0.00072 seconds to solve it. Under a millisecond. On the computer I received for Christmas.
So that is the whole thing summed up in one picture: NORAD’s best, most expensive, room-sized Cold War computer takes somewhere between six weeks and a decade to do this the right way, and my ZX Spectrum can do it in the wrong way quicker than you can blink. The difference never had anything to do with the hardware. The difference always has been about the logic. A computer with rubber keys will find problems with poor design before a supercomputer can live with good design.
Second footnote, because apparently I still hadn’t finished: While I was at it, I had to repeat the same exercise with respect to the actual ending of the movie – WOPR playing tic-tac-toe with itself over and over again until the machine “realizes” that the game is impossible to win and extends the logic to thermonuclear warfare.
Tic-Tac-Toe is a game with a total game tree consisting of 255,168 distinct games or about 26,830 positions if symmetrical duplicates are discarded. This is the entire game of tic-tac-toe – fully explored and solved, every single position leading to a particular solution – not sampling, but the whole shebang. Even an ordinary computer from 1983 exploring the tree at a speed of hundreds of thousands game-tree positions per second will process the whole tree in less than one second. The entire montage showing screens of the computer displaying the message “GAME OVER” faster and faster until reaching the moment of epiphany of the computer should be much shorter than the actual pronunciation of “tic-tac-toe”.
It wasn’t exerting itself. It was solving a trivially known game space in the time that would take it to blink, but the movie needed it to seem to be coming to a revelation through struggle, because “the computer did some arithmetic for a fraction of a second and then knew everything” doesn’t carry any cinematic weight at all, compared to a montage.
And it goes beyond making the reveal take longer than necessary in that it becomes faster and faster as WOPR “gets into it,” as if warming up and building momentum toward its revelation, but a computer does not warm up. It runs as fast as the hardware allows, from cycle one to the last, or someone has programmed delays into it – and rate-limiting an artificial intelligence that you want to use to launch a nuclear attack is an insane move in a fictional world. It doesn’t go into higher gear, it doesn’t “get into it.” It’s either running flat out from the first game on, or it is being limited by something upstream, and there is no indication of such limitation happening anywhere in the movie. Imagine booting up the newest video game from EA or Ubisoft and watching Spider-Man swing at arthritic slowness for the first ten minutes, and then gradually building up his speed. No one will take that as a rendering decision. It’s not “dramatic pacing,” it’s simply stupid, and having WOPR speed itself up for dramatic effect falls into that category as well.
Anyway. Well, look. I know this. It’s a film that’s forty years old, made on technology that’s now a museum exhibit, and I have wasted more time than is normal working on my math homework while watching a movie starring Matthew Broderick because I’m tired and wired and can’t leave well enough alone even at one in the morning. Here’s how that goes. I’m going to bed. 🙂
Comments (0)