Re: Embed passwords (Acme::Clutter idea)

There are things I don't like about this approach but I've been rolling similar ideas over in my head for a while now. It's the same basic issue: You need to code passwords in to allow for full automation, but you want to do that seamlessly and in a way that obscures the actual value as much as possible (realizing that nothing will hide them 100%).

My thought was to force the passwords specified in the code to be encrypted, surrounding that encrypted value with some identifiable, unique pattern, then to write a source filter that decrypts them as the source is compiled. The encrypter would be a command line tool that would only encrypt. The decrypting source filter would follow the perlfilter guidelines for obscuring things as much as possible (such as writing the decrypter in C and linking it statically to Perl, etc.).

Comment on Re: Embed passwords (Acme::Clutter idea)

Replies are listed 'Best First'.
Re: Embed passwords (Acme::Clutter idea) by Abigail-II (Bishop) on Feb 21, 2003 at 12:31 UTC
You can obscure your decrypter as much as you want, but what would you gain? To decrypt the password, one doesn't need the source of the decryptor. All you need is a copy of the script, with the encrypted password. Somewhere in that script, the password will need to be decrypted before sending it to whatever application. Just put in a `print $password` near that place, and run the program. Or maybe you don't even need to modify the code. Running and tracing it may be more than enough. Abigail	[reply] [d/l]
Re: Re: Embed passwords (Acme::Clutter idea) by steves (Curate) on Feb 21, 2003 at 13:09 UTC
I agree. It's not so much for bullet-proof encryption as it is for obscuring it from the 98% of the people who can't think that far. The irony is that it's only that other 2% that will be able to do anything with the data anyway. The source never leaves our building and this is only for internal use. Part of the reasoning is that it just makes some people feel better to not have it right there in plain text. As an example, one of my POD tools allows you to see the docs from our intranet and offers a link to see the actual source. That exposes the plain text to a lot of people who just don't need to see that data, but who could benefit from the general ability to see the source. This is mostly why I've only thought about it and never implemented it. I don't really see much added value. But I suspect I will have to do something like this at some point for "other" reasons. We have some other very weak encryption methods that are used internally but the mere existence of them keeps some people happy. Boy that sounds pathetic ... too late to post anonymously. 8-)	[reply]