Ken Thompson's Unix password cracked

Heh. His password was a chess move! :slight_smile:

[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:

From: Nigel Williams [email protected]
Subject: Re: [TUHS] Recovered /etc/passwd files

ken is done:


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.

1 Like

So that is why some versions of unix has a chess program endgame
running on the IDLE loop?

Nice one! I see Ken issues his “congrats” in the mail list thread.

An interesting idea - do you have a reference? (It’s always good to see posts with links.)

There are also lots of HN comments on this:

(Interestingly, the flawed DES3 algorithm performs pretty well, since password crackers aren’t optimized for this anymore.)


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.

1 Like

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. :wink: )

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.