13

I have a Python script that is connecting to the database. To that, obviously, I need the password. I need to hide it somewhere.

My problem is that this code is stored in a folder that everybody who has access to the server can look. So, if I write this password encrypted in a file, in the code will appear the key to discover it and people can figured it out.

So, please, if anyone has an idea..

Frias
  • 10,991
  • 9
  • 33
  • 40

5 Answers5

10

You're using a scripting language and accessing a database directly with a password. No matter what you do, at some level that password is going to be easily accessible. Obscuring it doesn't really buy you much.

You have to rely on the machine's security and permissions, and perhaps the database (restricting access from that particular machine and user).

Brian Roach
  • 76,169
  • 12
  • 136
  • 161
  • Yes, look like it is an impossible thing to do. Manage permissions is not a solution because this script has to run via web. But thanks for your answer. – Frias Mar 15 '11 at 18:30
  • 4
    What do you mean it's not an option because it's running from the web?? If it's running from the web you **really** need to be paying attention to ownership and permissions! – Brian Roach Mar 15 '11 at 19:09
7

Don't store the database connection credentials in the Python file at all. Instead, store them in a secure place, readable only by the user account that the script will run under.

For example, create a user account for running this job, and create a file in that user account's home directory (readable only by that user) called database.ini and put the database connection string and password there. Then use the Python ConfigParser class in the standard library to read the file in.

Then the job can be always run under that user account. You can also run it under your account by putting a database.ini file in your home directory with the correct credentials, but anyone who doesn't have the credentials cannot run it.

Daniel Pryden
  • 59,486
  • 16
  • 97
  • 135
  • And if any one of those users has `o+r` (or `g+r` possibly) set on the .ini file? I can read the script, then do a `find` looking for the one that's accessible. I'd rather lock down the script itself and allow execute to a specific user or group. – Brian Roach Mar 15 '11 at 18:09
  • 1
    @Brian: Hopefully each user exposes a *different* password in their .ini file. So if one is compromised, then that account can be locked out. But you're right: if you can lock down read access to the script itself, that's even better. – Daniel Pryden Mar 15 '11 at 18:17
  • Yeah, I didn't mean to say your answer didn't present a good design - but for security I tend never to trust a user :-D – Brian Roach Mar 15 '11 at 18:19
1

Check out this question. They suggest encoding the password in base64 (outside of the script) then including that string in the script and converting it back before you make the connection

Community
  • 1
  • 1
Jon Egerton
  • 40,401
  • 11
  • 97
  • 129
  • 1
    Sadly, that doesn't do a thing for you. If I can read the script, I can do the *exact same thing*. Copy and paste is not difficult. A random string of letters and characters would do the same thing (nothing), without having to muck around with base64 encoding it. (I believe the other question was more for "shoulder surfing", which again ... all you need is a random string that's hard to remember with a glance). – Brian Roach Mar 15 '11 at 18:05
  • 1
    I know that, but at least its not in plain text, and you couldn't use the text string in the file to log in directly. – Jon Egerton Mar 15 '11 at 18:11
  • Yes, I could. I'd simply base64 decode it first to get the plain password. That's what the script is doing, so I know that's what I have to do. – Brian Roach Mar 15 '11 at 18:15
  • 1
    Any malicious user who knows enough to do Bad Things to your database will know enough to decode base64. It doesn't add any actual security. – Daniel Pryden Mar 15 '11 at 18:18
  • I agree, but if you're going to do data access through a plain text script then passwords are only the start of your problems. A user who would know how to decode the base64 pasword would also know how to change the data access SQL (or whatever) even if the password could be properly secured. That's why I +1'd Brian's answer! – Jon Egerton Mar 15 '11 at 18:26
0

Just to reinforce what Brian said, if a program runs automatically (i.e., without the opportunity to prompt the user for a password), any program that runs under the same user authority has the same access to any password. It's not clear what else you could do. Perhaps if the (trusted) operating system on the client machine could certify to the host that it was being accessed by a program run from a particular path, the host could be told "Only open the database to /var/lib/tomcat/bin/tomcat on appserver.example.com". If you accomplish all that, an attacker would have to compromise the tomcat executable to get to the database.

Michael Lorton
  • 43,060
  • 26
  • 103
  • 144
-1

A more advanced idea is to do the mysql authentication manually. That is, learn the mysql protocol (it's a standard handshake with a challenege and a response) and do the procedure yourself. This way, you never send the password directly.

Spyros
  • 46,820
  • 25
  • 86
  • 129
  • 1
    I don't think the wire protocol is the issue -- one way or another, some kind of credential will need to be provided to the database by the script, and so that credential is what needs to be protected. Also, I don't see anywhere in the question where MySQL is mentioned, so why do you assume that's what's being used? – Daniel Pryden Mar 15 '11 at 18:21
  • well, yeah it could not be mysql i guess, though i suppose other dbms use similar approaches. Though the internal secret value is provided at some point, it can be made quite sophisticated and pretty difficult to unravel. One can even use a man in the middle approach where the MITM is written in C. This way, the password cannot be recovered. – Spyros Mar 15 '11 at 18:25