The password to the key must be in the binary - either in clear or encoded form and at some point it needs to be in memory in decoded form. Otherwise the binary could not decode the key itself. You could drop the passphrase immediately after decoding the key to make it harder for the attacker, but fundamentally all info to decode the key must be somewhere on the machine itself.
Trying all strings from the binary if any of them matches is a cheap and easy operation, so try it first, if it doesn't work use a more elaborate approach.
He didn't find the password in the clear, he found the private key in the clear. He brute-forced the password.
I assume his reasoning for looking for the private key was similar to: this program creates a new certificate authority and installs it on this computer. In order to do this, it must have all necessary tools for doing so, including the private key it uses to create those certificates, in memory somewhere. Even if that private key is stored encrypted somewhere, it has to exist unencrypted in memory at some point to be used.
Read it again, he found the password in cleartext in the memory dump. From the blogpost:
> I tried the small dictionary john.dict that comes with John-the-Ripper, and it didn't find anything. But of course, I don't need a real dictionary. The password is probably also in the clear in the memory dump. I could just use the file super.txt as my dictionary! I tried this, but it was taking a long time, with 150k unique lines of text. It'd take many hours to complete. To speed things up, I filtered the list for just lower-case words
So, just a hunch that it would be a company name or something else that might be in the dump? There's no technical reason for the actual password itself to somehow end up there? A serious security flaw or something?