Sign in to follow this  
Anddos

how to protect mysql strings?

Recommended Posts

how can i protect the strings that connect to the database from being comprimised by memory reading etc


I can read this question two ways:

1) You are trying to connect to the database from the client software, and don't want the user to be able to extract your database credentials.

2) You are connecting to the database from the application server software, but you want to protect the database credentials in the case of some security exploit that allows the attacker to read memory from the application server process.

In the case of 1), antosdaniel is entirely right: You never expose the database directly to clients. You always put an application server in between (call this the "game server.") The role of the game server is to provide authentication, authorization, and game rule enforcement.

In the case of 2), you can store the credentials in initialized mutable variables, and once connected, overwrite these variables with junk. Like so:
 
char mysqlname[] = "example";
char mysqlpasswd[] = "swordfish";
char mysqlhost[] = "db.example.com";

db_connection *db_connect() {
  db_connection *ret = whatever_connect_to_database_call(mysqlhost, mysqlname, mysqlpassword);
  if (ret) {
    memset(mysqlname, 0, sizeof(mysqlname));
    memset(mysqlpasswd, 0, sizeof(mysqlpasswd));
    memset(mysqlhost, 0, sizeof(mysqlhost));
  }
  return ret;
}
This works in C/C++, where the compiler will optimize the string constant into the initialized data section of the global variables.
If however you use std::string in C++, or use Java, C#, or a similar language, the string constants will not be elided and will still be available somewhere in RAM.

Secure credential storage in a production environment is actually a fascinating subject. There are many kinds of key escrow, key server, dedicated-hardware, and other esoteric approaches to mitigate this threat, all dependent on how determined you think the attacker might be and what the cost of failure would be. Edited by hplus0603

Share this post


Link to post
Share on other sites

Don't let the client connect directly to mysql at all, they need to go via a "middle tier" server.

 

If they connect directly, they'll be able to get the credentials (you can't stop them), then do various attacks (at least Denial of service) against your mysql server. You don't want that.

Share this post


Link to post
Share on other sites

Don't let the client connect directly to mysql at all, they need to go via a "middle tier" server. If they connect directly, they'll be able to get the credentials (you can't stop them), then do various attacks (at least Denial of service) against your mysql server. You don't want that.


If you use a real sql server such as Oracle you could possibly write an entire game server as a set of stored procedures, triggers, and restrictive schemas... This doesn't mean it's a good idea, though... (read as: DONT do it) :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this