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
