1

I'm creating a pygtk app that needs a mysql connection from a remote db.

db = MySQLdb.connect("remotehost","username","password","databse", charset='utf8')

App is almost completed and going to be published. But the problem is, if anyone decompile this script they can easily read the above credentials and then there is a security issue. So how do I can protect this code or is there any way I can strongly compile this file?

Nitheesh Chandrika
  • 141
  • 4
  • 13
  • 3
    Make sure that the user in that DB has only the minimal permissions he needs to operate. E.g don't let him drop your database. If the app doesn't need write or delete permissions - don't grant them. – patriciasz Jul 29 '14 at 12:05
  • Thanks for a good method. – Nitheesh Chandrika Jul 29 '14 at 12:21
  • possible duplicate of [Secure credential storage in python](http://stackoverflow.com/questions/14636290/secure-credential-storage-in-python) – loopbackbee Jul 29 '14 at 12:34

5 Answers5

3

Database connections are generally made from trusted computers inside a trusted network, for a variety of reasons:

  • As you've seen, the client needs to store access credentials to the DB.
  • Most of the time, such connections are made with no transport security (unencrypted), so any eavesdropper can observe and mangle requests/responses.
  • Latency in the path to the DB is usually a issue, so you want to minimize it, thus placing the client near to the DB

Violating this common practice means you'll have to deal with these problems.

It's very common to have a intermediary service using some other protocol (for example, HTTP/REST) to exposes an API that indirectly modifies the database. You keep the service on a host in your trusted computing base, and only that one host accesses the DB. In this architecture, you can (and should) perform authentication and mandatory access control in the intermediary service. In turn, having different credentials for each client that accesses that service will help keep things secure.

If you can't rewrite your application at this point, you should follow patriciasz's suggestion on keeping the least priviledge possible. You may also be interested in techniques to make it harder (but not impossible) to obtain the credentials

loopbackbee
  • 21,962
  • 10
  • 62
  • 97
  • I think it's the best answer in general, but in this particular case it would involve rewriting the app I guess. – patriciasz Jul 29 '14 at 12:25
  • @patriciasz yes, most certainly. I've included your suggestion, as well as a link to another similar question, with a very thorough answer – loopbackbee Jul 29 '14 at 12:36
  • I appreciate your answer. But in this scenario, its an a desktop application. Anybody can install it. So I can't guarantee it should be in a trusted network base. So I'm going through patriciasz's suggestion that I can at least make sure no other database operations can be made by that user. – Nitheesh Chandrika Jul 29 '14 at 12:46
  • @Nitheesh I think that goncalopp suggests to run the API on a server which is in trusted network. It would act as a proxy between your users computer and the database. So the app could be installed anywhere, not just in the trusted network. – patriciasz Jul 29 '14 at 14:49
2

There is no way to protect your code (compiled or not) from the owner of the machine it runs on.

In this case he will effectively have the same access restrictions your application's SQL user has.

Vatev
  • 7,493
  • 1
  • 32
  • 39
1

There is no good way to protect your code, but you can use read_default_file options while using connect. The connection arguments will then be read form the file, specified with read_default_file. NOTE: This in no way is securing your username, password since anyone having access to the cnf file can get the information.

Peeyush
  • 686
  • 4
  • 10
0

Build an interface between the database and the application. Only the interface will get true database access.

Give the app credentials to access the interface, and only the interface, then let the interface interact with the data base. This adds a second layer to boost security and helps to protect database integrity.

In the future develop with separate logic from the start. The app does not need to accesses the data base. Instead, it needs data from the database.

Also as a rule of database security avoid putting credentials on the client side. If you have n apps then n apps can access your data base, and controlling access points is a big part of database logic.

jam
  • 3,640
  • 5
  • 34
  • 50
chip
  • 1
0

Separating program logic is the real deal, credentials don't need to reside on clients machine just as chip said

Roisholto
  • 27
  • 6