When security was not yet a problem
In the first decade of electronic computing, one program ran at a time on a machine few people could touch. A trusted operator loaded the work, and the output came back on paper. In such a setup, one user could not read another’s data while it was running, because there was only one user at a time. Security consisted of a locked room and a list of authorized staff.
Time-sharing ended that arrangement. Beginning in the early 1960s, systems such as the Compatible Time-Sharing System at MIT let many people use one computer at once from separate terminals. That brought a new set of questions that had little precedent: how to keep the users apart, how to tell who was who, and what to do when one person’s mistake or curiosity affected the others.
The password problem
The first answer to “who is this?” was the password. On a time-sharing system, a user typed a name and a secret word, and the system checked it against a stored record. The idea was simple, and it has stayed with us for decades, but its early versions had weak points.
- Storing the list. If the system kept passwords in a plain file, anyone who could read that file got every account. Stories from the period describe passwords exposed through mistakes in how files were managed or printed, though accounts of specific incidents vary and are hard to verify.
- Guessing. People chose short or obvious words, and attackers could try many guesses.
- Sharing. Because computing time was often limited by account, users had reasons to borrow one another’s logins.
- Eavesdropping. A password typed over a telephone line could be seen by anyone able to tap or observe that line.
A common remedy, adopted in Unix in the 1970s, was to store only a scrambled form of each password, so the file itself did not reveal them. Defenders then had to worry about guessing attacks against the scrambled forms, and the contest between better storage and faster guessing has never stopped.
Keeping programs and data apart
Passwords answered who someone was. A second challenge was what each person was allowed to do. A shared machine needed to stop one program from reading or overwriting the memory and files of another, or from taking over the machine entirely.
Hardware and software worked together on this. Memory protection, built into the processor and the operating system, limited each program to its own area of memory. Privileged modes reserved certain instructions for the operating system itself. Systems such as Multics, a time-sharing project begun in the 1960s by MIT, Bell Labs and General Electric, put protection at the center of the design, with concepts like rings of privilege. Many of its ideas influenced later operating systems, including Unix, whose permission scheme with owner, group and others remains familiar. The broader technical story is in the history of operating systems.
File permissions followed a similar logic: each file has an owner and rules about who can read, write or run it. Choosing sensible defaults was, and remains, a challenge, because strict rules get in the way of collaboration while lax ones expose data.
Studying the problem
By the early 1970s, military and government users who put sensitive information on shared machines wanted to know whether those systems could be trusted. A 1972 study by James P. Anderson for the United States Air Force described the difficulty. It noted that finding and fixing individual flaws, then often called penetration testing, did not prove a system was secure, because new flaws could always turn up.
Researchers responded with formal models that describe what secure behavior means. The Bell-LaPadula model of the early 1970s focused on keeping classified information from flowing to people without clearance. Another influential contribution came from Saltzer and Schroeder in 1975, who summarized design principles such as least privilege, keeping mechanisms simple and assuming that attackers know the design. These principles still appear in security teaching.
Who were the threats?
Early threats were different from those of today’s networks. Many involved insiders: employees or students with legitimate accounts who looked at files they should not. Others were curious users who explored a system’s weaknesses, sometimes as a game, sometimes to avoid charges for machine time. There were also accidents, in which a bug in one program corrupted the work of others. A small number of cases involved fraud, where banks and businesses used computers to track money, but public discussion of these was limited and details are often unclear.
Outside attackers faced obstacles of their own. Few computers were reachable by telephone, and the dial-up systems that were connected were hard to find. That picture changed once computers joined networks in larger numbers, which brought outside intruders into the picture and made earlier measures look incomplete. The broad arc is covered in the overview of computer security.
Lessons carried forward
Several ideas that began in this period continue to shape practice.
- Identify users, then limit what each one can do.
- Keep the part of the system that enforces rules small and well understood.
- Assume mistakes and curiosity as well as malice.
- Do not rely on secrecy of design as the only protection.
Early systems did not solve these challenges. They did, however, define the questions that later work on networks, encryption and privacy still ask.