Hiding MySQL Credentials in Application

Question

I need to create an application for a company and they would like to have people login to the application to have different permissions to perform different tasks.

My initial idea was to create a MySQL database, hardcode the credentials into the application and have the application connect to the MySQL database. The MySQL database would then have a table called "users" which would store usernames, passwords and permissions. The application would then query the server and perform the authentication.

The biggest problem with this is having the MySQL credentials hard coded into the application. If the application gets into the wrong hands, they could do lots of damage to the MySQL database if they snoop around to find the credentials and start dropping tables.

So I thought of developing a server that acts as an interface for the MySQL Database. For example, the client application would connect to the Server via TCP, and the server connects to a MySQL database. That way the MySQL credentials are never exposed to end-users. However, this means I have to develop a server application which a) will be harder to maintain and deploy for my customer (as opposed to just setting up a MySQL Server) and b)Has potential to introduce more bugs since I have an additional system I need to make (which relates back to point a for deploying bug fixes, etc)

So I was thinking instead of having a table of users in the database and having the application connect directly to the MySQL server with hardcoded credentials, the end-user would be given actual MySQL user credentials in which they would enter into the application to connect to the MySQL server. This means if someone gets their hands on the application, they can't do any damage to the MySQL database, but there still remains the risk of an end-user giving their credentials to the wrong person.

What are the best ways to have a desktop application connect to a MySQL database? Are there any other solutions other than the 3 I have thought of, or do you have any thoughts on my solutions?

Answer 1

Let's look at two ways of dealing with database:

• Client directly connects database, and manipulate database
• Server connects to database and provide interface for client to use

Considering your use case:

valid valid serial number or to store/read information about certain user

it can be designed in the following way to provide security. (I'm no expert in this)

• Client directly connects database, and manipulate database
  • You don't have to use your admin to visit database, instead you create a user for client only, and limit user's access privilege to only viewing (certain data). And you can enforce security policy at database by changing privilege for this user.
  • you can consult MySQL :: MySQL 5.1 Reference Manual :: 6 Security for more info.
    • 6.2 The MySQL Access Privilege System
    • 6.3 MySQL User Account Management
• Server connects to database and provide interface for client to use
  • You can use HTTP and provide interface to client to use. And only the backend connects to the database.
  • Something like RESTful API, there are many easy to use framework that provides authentication and authorization.

I don't think it's good idea to let client have direct access to database in your case. So if possible, the second option is better.

Also note that password based authentication is not ideal.

Answer 2

Where I work there are two practices I have seen:

1. Each entity (person, thing, or business (depending on level of granularity needed) accessing the database) has their very own credentials. This was used on an MSSQL and on a Rocket Universe database. This is mostly the retail and legacy software.

2. We host the application ourselves and use a separate authentication system for users. The database credentials are stored on our server where the application is hosted. The client knows nothing of the backing database. These are usually web apps and web services.

Something you could do that we have done is that many of our applications actually talk through a RESTful service that emulates the database in a way. The application itself has no access to the database. I would read the wikipedia article on restful services for more information. Our authentication is done using Nonce encoded HMAC requests where each user is given their very own key tied to their credentials.

Wrapping the database in a web service gives you a few possible advantages:

• If you decide to change your database structure while keeping the same information, you might not even need to update the client applications, just the service.
• Credentials never leave the server, your credentials remain safe so long as nobody gains access to your server. Security in general is increased.
• If you do your service cleverly enough, you could even transfer much of the internal logic that would normally be client side onto the server, making updates and bugfixes virtually seamless to the client.

The disadvantages that I see:

• It is one more thing to maintain
• Your application is vulnerable to denial of service attacks, but since it is a database that's a possible problem anyway
• If the server goes down, all the client applications go down, but again, still a problem anyway.

RESTful architecture: http://en.wikipedia.org/wiki/Representational_state_transfer

HMAC: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code

Our HMAC system works like so:

• User logs in using username and password to their local application.
• The local application communicates to our authentication service and gets a "Session Key" and shared secret for that username and password.
• Using the Session Key (which expires in a short period of time), the application creates an API Key (which lasts a long time) and stores it to the computer. The session key could be used instead of an API Key if the user is required to log in each time. We mainly did it this way for convenience for some programs. If the computer is not secure, the Session Key should be used only and no API key is stored on the local machine. Each time the user logs in, they get a new Session Key.
• Each request to the database service is accompanied by a HMAC-signed nonce which the application gets from the authorization service based on the API key. After getting the nonce, the application signs it using the shared secret. These signed requests can only be used once since the web service (which the user could know nothing about) authenticates the request. Once the signed nonce has been authenticated server-side by seeing if hashing the nonce with that particular API/Session Key's shared secret results in the same digest, the nonce is marked expired and the request is granted.

The above is vulnerable to man-in-the-middle attacks if HTTPS is not used, so often people make a message based on the nonce and the URL being requested along with a timestamp and compute the HMAC on that. The server then recreates the message based on the URL, checks to see if the timestamp is within some bounds (+/- 4mins or something), and then authorizes the user based on that information.

To further granulate operations, we also have a role system which checks to see if the user who owns the Session/API Key has been given permission to request the thing that they were requesting. If they have the appropriate role, the request is granted.

Summary: Credentials are done user-by-user, the end user has no knowledge of the database, a web service wraps the database in a RESTful API, and a role based system is used to make permissions granular.

This is just a suggestion and I am not saying this is the best or only way to do this. This just happens to be how we have ended up doing it where I work.

Answer 3

As @Perception noted. Your best bet here is to implement a web service in front of MySQL. You don't want unknown numbers of clients from unknown IP addresses all having access to your database.

It would be really easy to DOS attack you by tying up MySQL connections. Not to mention that you would very severely limit your ability to scale your backend service to meet the demands of an increased client base without having a web service in between.

The web service could also offer you the ability to control user authentication and authorization in any number of ways (user/pass combination, token-based access, OAuth access, etc.).