It was a matter of time before it leaked. If you're going to put a back door in, at least make sure only you can use it (Nobody But Us). Why didn't they use a keypair?
Hiding that in the could would be much more difficult. And using PKs would make the attack even easier to spot.
And then you have to consider that a "Nobody but Us" backdoor exist only on paper, not in reality. If a key exists and someone knows it, well sooner or later it will be discovered (disgruntled employees, hackers etc). The only safe backdoor is the none backdoor. Now, consider this problem from an attacker that doesn't give a st of your security. He knows that as soon as the backdoor is known (because someone find it in the code, because someone leak the password, because whatever...) the backdoor will be useless most systems. What you do, you design a safe backdoor or you design a backdoor with as little footprint as possible?
Obviously, legally sanctioned backdoor have a different set or constraint and making them safe is a requirement. The fact that it is impossible to prove them safe unless some assumptions (that always prove to be wrong, but...) are made, it's a totally different problem.
I (perhaps incorrectly) assumed that criminals would want to stick in a hash function, given a choice.
I think the explanation, that adding a hash function will attract more attention than a simple strcmp is a good one. As is the desire to stick in something that gets by code review.
All signs point to this 100% not being Juniper engineering officially adding a back door, and it being a party doing it without authorization.
- This one could be the work of an intern, maybe a smart one but definitively it doesn't seems very sophisticated (we should look at the code).
- The second one, we are not sure it actually existed but just that someone changed the parameters for the PRNG. But if it existed, well, it was a very sophisticated attack.
But that's not the point of your question! A string compare with an if is pretty easy to hide in the code. Especially if the string looks like a logging string. I'm pretty sure in a big patch could pass through a quick code review. Calling an HMAC function or hiding it in the auth code that already call the HMAC function is much more complex. Plus it is much more difficult to generate a password, salt couple where both the salt and the HMAC seems legit code. Even for an intelligence agency or an attacker with huge resources, it is difficult to get such result!
Since we haven't seen the source it's difficult to speculate but I would venture to guess that the less function calls around your backdoor the better. It may look weird putting the code in another place where hash comparisons may be needed but in the place they put it where it's plaintext must have been harder to notice.
They might also have expected adversaries to be able to invert any hash function accessible in the code -- which is plausible for a nation-state adversary with some hash functions. (If scrypt isn't already there, you don't get to add it; that would really stick out.)
This looks like debug or logging string builder which no one would give it a second look while glancing over it.
Hashes and binary blobs will look out of place, same thing goes for intentionally obfuscated secure string builder.
When you put in a back door the best one will always be the shortest possible complicating it will only increase the likelihood of it being detected.
The sign of a true high level adversary isn't overly complicated and obfuscated software but one which is remarkably simple and elegant whilst still achieving the desired functionality.
Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality.
I mean - it's not like the unit tests are going to contain check_backdoor_works() (etc).
So the simpler and more straight forward you can get your backdoor snuck in - the longer you can know it will remain, and keep working.
spies, you mean? The NSA, that is
Spies rarely are egotistical and never are flashy, James Bond is pretty much the most anti-spy as one can get :)
One of the common techniques in static code analysis is to cross reference function calls against a desired state and to flag any undocumented links which again increases the likelihood of your backdoor being detected.