[Leah Neukirchen] Somewhere around 2014 I found an /etc/passwd file in some dumps of the BSD 3 source tree, containing passwords of all the old timers such as Dennis Ritchie, Ken Thompson, Brian W. Kernighan, Steve Bourne and Bill Joy.
[…]
However, kens password eluded my cracking endeavor. Even an exhaustive search over all lower-case letters and digits took several days (back in 2014) and yielded no result. Since the algorithm was developed by Ken Thompson and Robert Morris, I wondered what’s up there. I also realized, that, compared to other password hashing schemes (such as NTLM), crypt(3) turns out to be quite a bit slower to crack (and perhaps was also less optimized).
[…]
Finally, today this secret was resolved by Nigel Williams:
took 4+ days on an AMD Radeon Vega64 running hashcat at about 930MH/s
during that time (those familiar know the hash-rate fluctuates and
slows down towards the end).
This is a chess move in descriptive notation, and the beginning of many common openings. It fits very well to Ken Thompson’s background in computer chess.
To answer my own request for a citation, I see something in the 1973 paper “The Unix Time-Sharing System” by Ritchie and Thompson. Oddly, in this version published in 1974 in Communications of the ACM there’s this text:
There is a “background” process that runs at the lowest possible priority; it is used to soak up any idle CPU time. It has been used to produce a million-digit approximation to the constant e – 2, and is now generating composite pseudoprimes (base 2).
but in this version (PostScript) we see this text:
There is a ‘‘background’’ process that runs at the lowest possible priority; it is used to soak up any idle CPU time. It has been used to produce a million-digit approximation to the constant e−2, and is now solving all rook-and-pawn vs. rook chess endgames.
I saw an amusing comment to the effect that Ken doesn’t need a password - see his 1984 paper “Reflections on Trusting Trust”
Ken Thompson’s “cc hack” - Presented in the journal, Communication of the ACM, Vol. 27, No. 8, August 1984, in a paper entitled “Reflections on Trusting Trust”, Ken Thompson, co-author of UNIX, recounted a story of how he created a version of the C compiler that, when presented with the source code for the “login” program, would automatically compile in a backdoor to allow him entry to the system. This is only half the story, though. In order to hide this trojan horse, Ken also added to this version of “cc” the ability to recognize if it was recompiling itself to make sure that the newly compiled C compiler contained both the “login” backdoor, and the code to insert both trojans into a newly compiled C compiler. In this way, the source code for the C compiler would never show that these trojans existed.
But wasn’t Ken Thompson’s login hack on a MULTICS system (Air Force)? I remember reading some to this extent.
(It may be only appropriate for a MULTICS system to approve of multiple users via a single login, while Unix is strictly restricted to single user login procedures. )
From the Reflections paper linked above, it seems you are both right and wrong:
The actual bug I planted in the compiler would match code in the UNIX “login” command.
…
I first read of the possibility of such a Trojan horse in an Air Force critique (4) of the security of an early implementation of Multics.
)