in reply to Re: How to hide a password in a script?
in thread How to hide a password in a script?

Using your own quote against you... ;) This is a makeshift solution to a lack of feature-set that a vendor has failed to provide. (does that make sense???) Anyhow, this is only meant to be a band-aid. I agree that davido's advice is good, and well founded. I'm not trying to deny that. But what I'm saying is that an ecrypted solution simply won't work in this situation. If it would, then my team wouldn't have spent the last couple months developing the script(s) they have to accomplish the task in the manner they have.

So, to hopefully set you're security minds at ease, no one has ever gotten in through our boundary, so the biggest threat is internal. The biggest of the internal threats is our "Red Team". And this particular "storage medium" is an unlikely target for that team. The intended obfuscation simpy removes it that much farther. Trust me, if the situation were different, I would be the one preaching the same things you are.

However, I believe that there is a time and place for everything, and this particular situation calls for obfuscation, NOT encryption. I don't mean to knock the suggestions of Aristotle and davido. But, they simply don't apply here. I've seen the things that you (they) do in the "Obfuscated Perl" section, and I'm merely asking for guidance on how to reproduce and apply it to my particular application.
  • Comment on Re^2: How to hide a password in a script?

Replies are listed 'Best First'.
Re^3: How to hide a password in a script?
by Aristotle (Chancellor) on Aug 06, 2004 at 19:02 UTC

    The point I was making in my post is exactly what beable says in Re^3: How to hide a password in a script?. By definition, the obfuscated code will have to generate an unobfuscated password; anyone who can read and therefor run the code, can thus recover the password. And they don't need to deobfuscate your code.

    Do you understand now? Whether you obfuscate the code or not is irrelevant. It does not hold up an attacker for even a moment.

    You did not understand the point of my signature either. It is a monition to remember that solutions are often used beyond the scope they were originally built in; and that you should therefor never forgo a certain measure of robustness. It actually underscores my point with regard to your situation: do you know how long your false security measure will be in use, or in what context it will exist five years from now?

    Do not do this. Put the plaintext password in a permissions-protected file. Not only will this prevent anyone from getting the wrong impression about the security of the password, it will actually be effective.

    Makeshifts last the longest.