Re^3: How to hide a password in a script?

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

Comment on Re^3: How to hide a password in a script?

Replies are listed 'Best First'.
Re^4: How to hide a password in a script? by Aristotle (Chancellor) on Aug 07, 2004 at 06:03 UTC
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]
Re^5: How to hide a password in a script? by BrowserUk (Patriarch) on Aug 07, 2004 at 06:27 UTC
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	[reply]
Re^6: How to hide a password in a script? by Aristotle (Chancellor) on Aug 07, 2004 at 06:43 UTC
See, that's another situation. I don't see why the employee has to be able to run that script himself. He could for instance communicate with a daemon running with sufficient permissions to launch the script on his request, where launching that script is hardcoded in the daemon and cannot be parametrized from its employee-side interface. (In practice, this communication is encapsulated by a tool or interface.) That way, he never gets to actually see the script. All he can do is command the system to do exactly what he is supposed to be able to command it to do and nothing else. Deny by default is the only sane and unflawed approach to security. Never grant any permissions that allow more abilities than essential. A user who is supposed to be able to start one script with a fixed set of parameters has no business having a shell account. Makeshifts last the longest.	[reply]