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

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.

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

Replies are listed 'Best First'.
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

      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.