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!

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.

My understanding of what the OP was describing was not securing against external attack, but internal, (semi-)authorised snoopers.

Using ids granted only as much authority as is required to do the jobs is a given. Often ignored I grant you.

Employees have to be given the authority to run the scripts which in turn have to have passwords that have the authority to do the required work.

In this situation, you frequently need the script to do things, and access information that you would prefer the employee operating the scripts to not be able to do (manually), or see.

I agree that proxies that act on behalf of the script's requests is the best appproach. But if the employee can see what the script sends the proxy, then they can work out what to send to have the proxy do their bidding.

It's an extra level of complexity that forces the sedious to an extra level of sophistication. Perhaps the only merit in my joke was that it might allow you to detect the unsophisticated before they become sophisticated.

---

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

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.