[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [OT] Security in scripting languages
- From: cvogler@... (Christian Vogler)
- Date: Fri, 15 Feb 2002 13:40:14 -0500
On Fri, Feb 15, 2002 at 04:15:12PM -0200, Diego Fernandes Nehab wrote:
> As Vincent said, the security of an encryption algorithm must not be on
> the algorithm itself, but only on the secret key it uses to create the
> encrypted data from the plain text. Otherwise, once someone decides to
> waste a few hours to unassemble your algorithm, all the data you
> encrypted with it can suddenly be revealed for ever!
as far as I understand Philippe, he wants to do something different:
He does not want to write a protocol for password
authentication. Rather, he wants to automate some tasks with
*existing* servers that require a password before they can
proceed. Using a one-way algorithm to encrypt the password won't help
here, because the servers require either the password in cleartext, or
some hash of the password. Either way, if an attacker gets hold of
that, he can authenticate himself with the severs.
So, the problems is how to prevent other users from getting hold of
the password or the hash in that script. There is no really good
answer to that. You can use filesystem permissions for that in the
following way: make the script world-executable, but read the password
(or the hash) from a configuration file that is only readable by an
authorized user. But this is not a recommended solution if you are not
in charge of the computer on which the script runs, or if you have
reason to believe that it could be compromised.
Another solution is to use a master password that the user needs to
enter at the beginning of running the script, and this master
password can be used as a key to decrypt the other passwords needed
for all the servers. There is some software out there that already
does that; for example, Bruce Schneier at www.counterpane.com wrote a
program for that, and he recently made it free software.
It all depends on whether a minimal amount of user intervention is
acceptable, and how secure the environment is that the script is being
run in. The bottom line is, if you can't trust the system from which
you run the script, there is no secure way to accomplish your goals.