MySQL SecureString as connection string

问题

I've a general question about a SecureString as connection string for MySql-Connector. If i understood it right, SecureStrings are a "safe" way to store strings within my program. Now i've two problems with that:

1. I've to read in the password at installation (TextBox which is string and therefore unsafe)
2. I've to build a connection string for the MySQL-Connector which is string (unsafe again)

example:

MySqlConnection con = new MySqlConnection();
MySqlConnectionStringBuilder builder = new MySqlConnectionStringBuilder();
builder.Add("SERVER", "loaclhost");
builder.Add("PORT", "3306");
builder.Add("DATABASE", "test_db");
builder.Add("UID", "root");
builder.Add("PASSWORD", "11235813"); //not the real password ;)
con.ConnectionString = builder.ConnectionString;
con.Open();

Which brings me to my next problem: The MySQL-Connector API is "unsafe" because all values are stored as plaintext string.

Final question: Is there any sense of using SecureString ?

In my opinion i could use string everywhere in my program. If it comes to MySQL all kind of encryption (within my programm) will be useless.

Am i right with that opinion ? Are there any other ways ?

best regards Alex

回答1:

There are other ways to do it. It depends on who you think is comming after your connection string and what type of access and skill levels they are going to have. The connection string is in there, somewhere, no matter how you try to hide it.

Knowing that the connection string could be hacked, I always assume that it will be hacked and take precautions on the other end.

We do several things on the DB server end to make sure that even if the connection string is comprimized the data is still secure.

• The user that is accociated with the connection string has virtually zero permissions on the server. The only permissions they have are EXECUTE and CONTROL on the SCHEMA that contains the Stored Procedures.
• The only access that the front end has is through stored procedures. We never allow the front end to send up SQL Strings.
• The data is kept in a seperate schema than the execuatables, in the DATA schema the user asssociated with the connection string has ZERO permissions, they cant look at it, smell it or touch it.
• The stored procedures delegate permissions to no-login user that has enough permissions to execute the proc. (WITH EXECUTE AS 'no-login User')

This is about all we can do. We have not found a way to prevent the connection string from being exposed in some manner somewhere.

In reply to the question that Alex asked below. (too long for a comment)

Note. The following is for MS SQL Server, it may apply to other DBMS systems but I cant vouch for any others.

A Database contains Schema, the Schema contain Database Objects such as tables, views, stored procedures. The schmea allows you to fence off data base objects, for instance, if you had a group of tables that anyone was allowed to see, then they could to into a COMMON schema, if you had payroll inforamtion that you needed to secure you could put that into a PAYROLL schema. You can then put different security measures on the SCHEMA based on the type of objects that are inside of them. Graphicaly they look like folders on a hard drive and under them are all of the database object that they contain. When you fire up your server, there are several schema that are automaticaly created. The one that you are most familiar with would be the DBO schmea. You might not be aware of it if your admin has set that up as your default schema.

What we do is to place all of the data into a DATA schmea, this means that only tables are allowed. So if we had a payroll database then the data tables would go into a schema called dataPayroll.

A Stored Procedure is a block, or blocks of SQL code that the Database server can run when called on. It can return a Table of data, or a single value. Think of it as a method in C#.

Stored procedures have input, and return parameters that are used in the SQL code. Paramatarized Stored Procedures are a strong defense against SQL Injection attacks.

Our protocal says that the Stored Procedures and Views are all stored in a schema preceded by ‘prog’. So in the case of the payroll database all of the objects that aren’t data are inside the progPayroll schema.

The user that is defined by the Connection string then only has Control and Execute permissions on the ‘prog’ Schema. This allows them to call the Stored Procedure. The user that is defined by the Connection string is denied all other permissions. This user is also denied ALL permissions everywhere else. In the Stored procedure, the permission to access the data is delegated to a NO LOGIN user that has permission to retrieve the data from the ‘data’ schema using the EXECUTE AS command.

There is NO sql in the front end. All the front end programmers know is what the name of the stored procedures are, the parameters and the return types and values.

This way, even if the attacker manages to tease out the connection string from your program, they still have a lot of work to do to be able to do anything to your database since the user that they have can only execute a Stored Procedure.

If you have no idea what any of this stuff is then you really need to get a DB programmer to set your system up for you.

来源：https://stackoverflow.com/questions/17936392/mysql-securestring-as-connection-string