Is there a risk to having SqlConnection object as a property for a single executable?

Question

I've got the design habit to have a SqlConnection object populated by a child form, showing the child form, establishing the SqlConnection object and having the populated object passed back to the parent form where execution continues. .NET 2.0 and up 0 as follows:

Parent form:

public SqlConnection sqlcon; //should be property but made it public for this example
public MainForm_Load(object sender, EventArgs e)
{
    Login frm = new Login(this);
    frm.ShowDialog();
    if (this.sqlcon == null)
    {   //no login
        this.Close();
    }
    //else, continue execution

}

Login Form:

Mainform parent;
public Login(RandomParade frm)
{
    InitializeComponent();
    parent = frm;
}

private void btnOK_Click(object sender, EventArgs e)
{
    //code to capture login details from textboxes
    //test connection       
    parent.sqlcon = new SqlConnection("connection string with login details here");
    this.Close();

}

As this is compiled into a single executable (dll access modifiers treated separate etc...), is having the sqlConnection object public a security risk? Could someone pick up the information at runtime? What would be a better implementation of passing login information to a 'Main' form?

Answer 1

Since .NET maintains a connection pool internally (unless switched off), you should be passing around a connection string instead, and use this when creating new connections.
This allows you to keep the connection information "thread safe" by creating a new connection for everything you need to do (relative to a batch, for example).

There isn't a risk for the connection to be hijacked at runtime, as this should be all bundled up nicely into an application domain. (There are ways, but that's another discussion).

It might seem very inefficient, but due to the background pooling, passing a connection string around works out great.

So, to answer your question: there's not really a security risk, but there is a risk for thread safety, so pass around a connection string instead of a connection. This will run smoother for you.
Also, remember to dispose of your SqlConnections and SqlCommands when you're done with them ;)