Our long-time friend, GRG, is back again, this time with tales of anti security.

..
A very long time ago, he worked at a University Computer Center. At the time, th
e school was the proud owner of two huge, hulking mainframes. (The faster of the
two was big, gray, probably designed by a guy named Seymour, and was the fastes
t computer in the world for several years!) Unfortunately, the operating system
was rather bare-bones. Thus, although you couldn't do much, you could do it with
out fear of the OS getting in your way. For example, you could store files (one
directory per user), compile FORTRAN or COBOL or Pascal programs, or run SPSS, a
nd that was about it. Unless you were willing to creatively think outside the bo
x...
Also, another side effect of the bare-bones nature of the system, the security w
as a bit...weak. All the usernames, passwords, and permissions were kept in one
unencrypted binary file. If you could get hold of that file, you had all the key
s to the kingdom.
The system helpfully provided an ordinarily very useful feature where by if a pr
ogram aborted, the system would keep the program's current files attached to the
job. An interactive session was one long "job", so if you interrupted, say, the
password change program, you would find the password file still attached to you
r job and you could read it at your leisure. Even more helpful, the dump program
printed out 8 words per line which was the exact binary record length of each v
alidation record. Thus, you could get a nice printout of the validation file wit
h almost no effort at all.
After a while, the admins patched up this hole, sort of, by having the password
program turn off terminal interrupts. That worked for about three days, until so
meone figured out that they hadn't turned off the "CPU time limit exceeded" abor
t. If you set your CPU time limit to 1 second, then ran a program that used up s
omething like 0.990 seconds, and then chained to the password change program, th
e time limit would expire inside the password changer and you'd have the passwor
d file again. This state of affairs lasted about a month, but sadly, it too got
patched.
Then somebody noticed that the operating system tried to be efficient, and if yo
u had some FORTRAN "blank common" area, neither the OS nor the loader would init
ialize that area, so you'd see all kinds of garbage in your blank common. Someti
mes you'd see data from other programs, editor buffers, and such. Hmmm, so you c
ould peek at abandoned memory... Sure enough, if you ran the password changer an
d then dumped blank common, you could see the the I/O buffer that the password p
rogram used. It was conveniently 1024 words long so you'd have a peek at the 128
usernames and passwords around your username at a time. Handy.
Not to be outdone, someone else thought Hmmm, I wonder how they keep the passwor
d files synchronized between the two mainframes? This was before Ethernet, but b
oth mainframes had access to a big box of extended memory... perhaps they passed
the password file back and forth through that? It turns out the system came wit
h a useful utility program named "DUMPECS" (Extended Core Storage). All you had
to do was change your password and quickly type "DUMPECS" and you'd see the whol
e validation file printed out. They didn't clear ECS after each use. And conveni
ently the password file transfer happened at the same address in ECS that you'd
get from DUMPECS. *Joy*
That went on for a few more months before ECS started returning all zeros on the
first read. Darn. Then someone noticed that the regular usernames did not work
during "system time", after midnight. Hmmm, how did they do that? The system was
n't very flexible, so they probably had to copy the real validation file to some

where else and copy in a special validation file with just staff usernames. If y
ou were lucky and they were a little bit tired at 6AM, they might copy the full
file back but forget to delete it. Or they might forget to make it a private fil
e. Or they might forget to password protect it. Anything can happen at 6AM. Sure
enough, one morning there was a file called VALIJUN in the system directory, bu
t it was password protected. Very clever. However the first password someone tri
ed ("NUJILAV") worked!
There were other ways too. If the system got slow it was often due to disk backu
ps to tape being run, and that left open the opportunity to watch for the tape o
peration finishing. With a little luck you could request the backup tape and the
operator might be too lazy to check whether it was actually the backup applicat
ion re-requesting the tape. Of course, the disk backups were unencrypted, and th
e first stuff on the tape was the system directories.
They never went to encrypted passwords. They couldn't because the account valida
tion code ran in some small peripheral processors with 4K of memory. Not a lot o
f room for encryption code there.
Not a problem, though, because only trusted personnel could access the system.