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 -- http://mail.python.org/mailman/listinfo/python-list
