Save passwords in scripts

[Florian Lindner]

Hello,
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?

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.

Thanks,
Florian

 

[Peter Hansen]

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.

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.

-Peter

 

[Florian Lindner]

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.

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

 

[Esben Pedersen]

Hello,
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?

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.

Thanks,
Florian

Which DB? afaik postgre has user-level authentication which means you
don't even need a password.

/Esben

 

[Paul Rubin]

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?

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.

There's not a one-size-fits-all answer. A bunch of possibilities:

- Just have execute permission on the script, not read permission

- If the database server and client are running on the same machine,
use a unix-domain socket instead of a tcp socket, and modify the
server to check that only a specific uid is running the client (you
can do this check with an ancillary message on the socket). Then use
sudo to get the client to run as that user. You can then leave read
permission enabled on the script.

- sort of similar: have a separate process running that knows the
password (administrator enters it at startup time). That process
listens on a unix socket and checks the ID of the client. It reveals
the password to authorized clients, i.e. your readable script running
under sudo. This keeps the password from ever being stored on disk.

- Modify the script itself to run as a long-running service instead of
as something that gets started and restarted all the time. Have an
admin start it and type the password into it at startup time. Users
then connect to it (maybe with a web browser) and send it commands.

- Move the user operations from the script to server side database
procedures that do their own validity checking. Then you don't need a
password.

- Run the script on a machine where users can't run arbitrary programs
other than the script. Set up the db server to not accept any
connections other than from that machine.

Etc. etc., you get the idea.

 

[Florian Lindner]

Which DB? afaik postgre has user-level authentication which means you
don't even need a password.

But all users are manipulating rows in one table and I need to check to make
sanity checks on the input.

Florian

 

[Florian Lindner]

There's not a one-size-fits-all answer. A bunch of possibilities:

- Just have execute permission on the script, not read permission

This does not work. In ordner to execute the interpreter have to read the
script.

florian@horus ~/python $ ./account.py
/usr/bin/python: can't open file './account.py'

Or you know a way it works?

- If the database server and client are running on the same machine,
use a unix-domain socket instead of a tcp socket, and modify the
server to check that only a specific uid is running the client (you
can do this check with an ancillary message on the socket). Then use
sudo to get the client to run as that user. You can then leave read
permission enabled on the script.

This a bit overkill for my needs.

- sort of similar: have a separate process running that knows the
password (administrator enters it at startup time). That process
listens on a unix socket and checks the ID of the client. It reveals
the password to authorized clients, i.e. your readable script running
under sudo. This keeps the password from ever being stored on disk.

- Modify the script itself to run as a long-running service instead of
as something that gets started and restarted all the time. Have an
admin start it and type the password into it at startup time. Users
then connect to it (maybe with a web browser) and send it commands.

- Move the user operations from the script to server side database
procedures that do their own validity checking. Then you don't need a
password.

I'll evaluate the 3 ideas above further.

- Run the script on a machine where users can't run arbitrary programs
other than the script. Set up the db server to not accept any
connections other than from that machine.

Not possible here.

Thanks for your suggestions,

Florian

 

[Serge Orlov]

I'll evaluate the 3 ideas above further.

I'm surprised there are no building blocks for a sudo replacement
in the UNIX world, at least I googled and couldn't find them.
Basically you need to split you script into two parts: priveledged
server and user client. They can talk xml-rpc over unix socket.
If you need performance you can also open another socket
for sending huge binary objects.

With regards to clear text password and admin, you can only
obfuscate or make it hard to obtain the password. It's just to
keep honest admins honest. Same story on windows, btw.

Serge.

 

[beaststwo]

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

 

[Paul Rubin]

Can I find out the identity of the client (PID/UID) when using unix socket?

Unix sockets have a feature called ancillary messages that lets you do
that, but the Python socket module currently doesn't support the
feature. There's an open sourceforge bug about it and I'd like to get
around to submitting a patch for it one of these days, but of course
it would be great if you did it first.

 

[Florian Lindner]

I'm surprised there are no building blocks for a sudo replacement
in the UNIX world, at least I googled and couldn't find them.
Basically you need to split you script into two parts: priveledged
server and user client. They can talk xml-rpc over unix socket.

Can I find out the identity of the client (PID/UID) when using unix socket?

If you need performance you can also open another socket
for sending huge binary objects.

With regards to clear text password and admin, you can only
obfuscate or make it hard to obtain the password. It's just to
keep honest admins honest. Same story on windows, btw.

Serge.

Florian

 

[Serge Orlov]

Can I find out the identity of the client (PID/UID) when using unix
socket?

Paul Rubin has answered this question. And as far as I know, not all
unix OSes support that. But you can do the following: create a security
group, add people to that group and create the socket that is owned
by the server process and accessible only by the people in that special
group.

Serge.