Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

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

by BrowserUk (Patriarch)
on Aug 07, 2004 at 06:27 UTC ( [id://380866]=note: print w/replies, xml ) Need Help??


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

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
  • Comment on Re^5: How to hide a password in a script?

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://380866]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2024-04-24 23:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found