in reply to How to hide a password in a script?

If I really had no other choice than to do this, I wouldn't embed the password in the main script.

I'd tuck it away in a module, probably one of the system module ( and include several that aren't required ), and export the password into the main namespace.

I'd probably tie the variable and only return the correct password after a particular value has been assigned to it.

And I'd only return the correct password once.

Thereafter, I would return the value passed.

In the script it would look like this: 

#! perl
use strict; 
use warnings;
use diagnostics;
use LWP;
use This;
use That;
use The::Other;

our $password = 'mysecret';

....

system( "command -p $password" );

...
## If you print $password here, you get "mysecret";
## But for the first time it was FETCH'd ONLY, 
## it would be different.

[download]

Of course, now I've told you this, I'll have to kill you so that you can't tell anyone else.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

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

    Obviously, none of this will be documented.

    It's a very nice way to play mind games on someone. Particularly on the poor sap who inherits your job when you move on. :-)

    Makeshifts last the longest.

[reply]

      Actually, I'd probably initialise the password (in the source) with a long hex string add a block of code that did some seriously complex bit-twiddling on it before its first use.

      I'd then surround it with a big block comments saying that: 

      ###################################################################
## This block must not be altered or copy&pasted in any way.    ###
## It will no longer work if it is.                             ###
## If this needs to be updated,                                 ###
## a new block must be obtained from the systems security team! ###
###################################################################

      [download]

      In any organisation, there has to be somebody who knows how things work!

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]
Re^2: How to hide a password in a script?
by beable (Friar) on Aug 06, 2004 at 22:40 UTC 
    our $password = 'mysecret';

....

system( "command -p $password" );

...
## If you print $password here, you get "mysecret";
## But for the first time it was FETCH'd ONLY, 
## it would be different.

    [download]

    Right, so I print the password before the system call, and then I get the real password. What are you gonna do? Go and change the password? This won't work at all.

[reply]
[d/l]

      First off. I almost certainly wouldn't do this. I cannot think of a situation where I could not come up with of a better place to put my passwords than in the source tree.

      And I certainly would not do it without adding several more twists to the theme that I described. It is not inconceivable that the correct password would only be returned at a given line of a given script (for example).

      However, there is an (as far as I recall) unaddressed problem here. We've probably all seen several instances of this type of news story. I haven't yet seen a good answer to the problem of where to retain ones DB passwords for use in perl scripts.

      Assuming that any script that requires a DB password is correctly secured against external access. That still leaves the problem of protecting assets against internal misuse. If a script is runnable by duly authorised and logged on employess, then most sources from which the password could be (directly) read whilst the script is being run by that employee, are also readable directly by that employee.

      With sufficient knowledge of the procedures in-place, a suitably authorised and knowledgable employee will always be able to circumvent simplistic security. However, sometimes the provision of a "decoy in plain view", a legitimate password that will successfully make a connection (albeit with a grossly constrained set of rights) that silently triggers an alarm when used, can alert you to those that are attempting such sedition, before they have the opportunity to do any real harm.

      Of course, there are better ways than embedding passwords directly in the source tree. A password server than hands them out at runtime, based upon the calling script runtime identity, time of day etc. But even these can be viewed and monitored and the runtime identity faked. But if the password appears to be embedded to the casual observer, you just might catch them out before they get more sophisticated.

      At the end of the day, my post was more in jest that seriousness and I see killing the OP is now a waste of time because somehow, he is not the only one that read my communique :)

      Maybe I should have added one of those email riders:

      This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information.

      That would have made things safer wouldn't it!

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]

        As far as database access is concerned: use a login with minimal permissions in your script; or preferrably, don't go to the database directly at all. Set up a DBI proxy for the script instead; in there, you can filter or sanitize queries in any way you wish to. Make sure the database is not reachable in any way other than through the proxy.

        If you do this right, it means that an attacker who obtains a login will not be able to do anything else with the database than he could have done with the web- or other interface for it which he started with.

        This is the only true way to achieve security: not granting any more permissions than absolutely and inevitably necessary.

        Makeshifts last the longest.

[reply]

      He's gambling on the fact that people will not expect and therefor notice that $password is evaluating to something different on the first call.

      I think he'd manage to confuse someone for a while with his smoke and mirrors. Which is a problem — because this must not be documented, you can bet there's going to be at least one person will be freaked out, whether or not a cracker ever sees it: the maintenance programmer.

      Makeshifts last the longest.

[reply]

In Section Seekers of Perl Wisdom