[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [OT] Security in scripting languages
- From: Philippe Lhoste <PhiLho@...>
- Date: Mon, 18 Feb 2002 10:34:55 +0100 (MET)
First, thank you to everybody which answered this thread.
> 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.
Yes, you hare right. I know that Unix passwd uses a one-way encryption
scheme, and just checks that the encrypted data typed by the user is the same as
the encrypted password stored in /etc/passwd. But that's not what I asked.
> 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.
Or, as far as I know, it just don't work in the Windows world, at least the
> 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.
I was fearing that. Indeed, my goal was to allow unattended runs of the
> Sure, I agree with that. I thought he was just looking for a crypto
> library for Lua. Anyways, the md5 library I mentioned does perform
> reversible encryption too, not just hashes.
I should have been more clear, but I didn't wanted to bloat my message with
all the cases I imagined and discarded, like putting an encryption key
somewhere in the code or the resources of the program. With the code, it is so easy
to locate it... I didn't though of the protected file, but again, that's
because I live mostly in the Windows world.
If MD5 provides reversible encryption, how easy it is to write a program
with an MD5 library to decypher a password found in a script?
Oh well, I suppose the solution is to use a simple two-way algorithm and
just count on the laziness or ignorance of most users to protect it. In this
case, the algorithm doesn't need to be powerful...
It will not fend off a motivated and knowledgeable user, but then again, a
good cracker can do a lot anyway. It is just a little easier when the source
Thank you again for the answers.
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
GMX - Die Kommunikationsplattform im Internet.