Some have pointed out that the code in the tools is crappy,
and they make obvious crypto errors (such as using the same
initialization vectors). This is nonsense. It's largely
pentesters, not software developers, creating these tools.
And they have limited threat models -- encryption is to
avoid easy detection that they are exfiltrating data, not
to prevent somebody from looking at the data.

Many years ago an engineer asked me for advice. He was being forced to store login credentials in the firmware so the device could access FTP, SMB, and other accounts when the only available mechanism was user/password. The device had no HSM device, and was completely standalone and unattended--using an administrator-supplied password for decrypting and loading a key on-demand wasn't an option. Also, most of the management code was implemented in a regular scripting language, including the code that kicked off the remote account logins, so even binary obfuscation strategies weren't practical. (You could bury it through a chain of binary commands, but it only takes one individual to trace things for it to be useless.)

We both knew there were no good solutions. So I sarcastically told him to just ROT13 the credentials. The less sarcastic part of my answer was that the best he could do was to make it more difficult to grep the filesystem or database with obvious patterns for uncovering credentials. Encrypting the credentials using a strong cipher was an exercise in futility. Anybody diligent enough to inspect the source code could immediately locate and decrypt the credentials regardless of how advanced the cipher or how convoluted the scheme for hiding the key.

Fast forward nearly a decade later and somebody shows me a YouTube video of a "security expert" showing his exploits of the firmware. One of the slides he showed was the ROT13 code, along with a comment the engineer inserted claiming it was my idea. (This wasn't a junior programmer misunderstanding me. He was just being a d*ck by literally using ROT13 and preemptively blaming it on me if anybody criticized the code.)

What really peeved me was that the security researcher and audience acted all smug about the ROT13, as if simply using AES would have been better. While I might not have literally used ROT13, there really was no good answer, and I think it's arguably defensible. Most embedded devices still lack an HSM, and in the age of VMs and containers that's even less viable than before.

It bugs me that people laughed at the situation, rather than appreciated the honesty of the programmer, such as it was. That they laughed tells me all I need to know about their skill, expertise, and experience actually implementing security systems, and actually dealing with the impossible solutions that product managers and customers demand.

It also tells me that because they couldn't be bothered to actually think through the problem and realize that there was no substantially better solution, they'd make horrible software developers. You can't write solid software, especially solid security software, if you don't have a habit of instinctively thinking through all the permutations and possibilities to judge whether your solution is sound or doomed. And you probably can't be a very good exploit writer, either, if you're not skillful at that.

It's worth pointing out that in some cases it does make sense to use a strong cipher, store the credentials in one spot, and store the key in another. For example, if you're storing the credentials in a network accessible database where it might be possible for it to accidentally be opened to the world, or where otherwise the credential store is more susceptible to unintentional leakage than the key store. That wasn't the type of situation in this case. Splitting things that way would have just resulted in two files in the same directory tree rather than one, and there was no reason whatsoever to think that if one file leaked the other wouldn't also leak simultaneously.