Save passwords in scripts

[beaststwo at yahoo.com]

I had a similar problem a few years ago and decided that if I really
had to store passwords, I could at least make them a bit harder to get
at.

I was using a the ConfigParser module to store other info in a config
file, so I added entries for the UserID and password to the config
file, as well as an "indicator" entry (yes/no).

Then I took all other values in the config file, put their info in a
delimited string (padded on both ends with a random number of
characters) and cleared the entries in the config file.  I used the old
Rotor module to encrypt the string, UUencoded the result and stored the
"Rotor encrypted", UUencoded result in a special config entry.
UUencoding makes the encrypted entry usable converts unpritable
characters, rendering the entry usable in a config file.

The uptake was that if the "indicator" entry was "no", the program read
the config file normally.  If the "indicator" entry was "yes", the
program UUDecoded the special config entry, decrypted using the Rotor
module, parsed the string and used the results for config entries.

I also wrote a separate program to encrypt/decrypt the config file
entries so it could be modified in the clear and then reencrypted
afterward.

The system worked for me.  While the security is arguable, it was
certainly better than storing them in the clear.  I'm sure an astute
individual could figure out what I did and break it by analyzing the
source code, but it was quite effective for hiding info from the casual
observer.

While the Rotor module is been deprecated, I'm sure the same thing
could be done with any encryption module that can use file-like
objects.  I used Rotor because it was in the basic Python distribution,
and I didn't want to relay on external modules.

Hope it helps!

Tim Sharpe


Florian Lindner wrote:
> Peter Hansen wrote:
>
> > Florian Lindner wrote:
> >> I've a scripts that allows limited manipulation of a database to
users.
> >> This script of course needs to save a password for the database
> >> connection. The users, on the other hand need read permission on
the
> >> script in order to execute it but should not be able to read out
the
> >> password. What is the common way to solve this problem?
> >
> > The common way is to do something ill-conceived and insecure.
> >
> > The correct approach is to use a secure technique that
> > does not involve storing the passwords themselves, but
> > instead storing a hash version of them (e.g. MD5 or SHA),
> > or by requiring the users to enter their passwords at
> > the time the information is required.
>
> Hashes could not work, since I need to give the password to a DB
server. My
> script is the client, not the server. It does not check passwords
supplied
> by the users, just use the hard-coded password to connect to the DB
server.
>
> >> My current way is to allow the users to execute the script with
sudo
> >> while not having read permission when acting as a ordinary user.
But I
> >> don't like this solutions and consider it very ugly.
> >
> > Storing passwords in the clear is always ugly and
> > insecure.  Think about the situation where a user
> > (unwisely) picks a password that he also uses for,
> > say, his online banking.  If the password is stored
> > in the clear, then anyone with root access can see
> > it and even if you trust all your administrators,
> > or are the only admin yourself, it's still not a
> > good idea to let an admin see a user's password.
>
> It's not a users password. It's a password of a db user which owns
several
> system tables and the users should be able to manipulate them in a
> constrained manner.
>
> I fully agree with you. That's why I'm looking for a better, more
secure
> solution.
> 
> Florian