Microsoft Access 2010 and ODBC Connection string security

I am using Microsoft Access 2010 with unbound forms. No linked tables allowed, otherwise the connections string is stored in the table definitions. So it follows that we will use a query definition with no name to access SQL SERVER. This is recommended by Microsoft. We need to get the connection string from somewhere though. So it is recommended to return it from a method with a obfuscated name. It is recommended not to embed the connection string in plain text in the application source. So we use encryption.

A good way of doing this is to require the applications administrator to define the connection string at the first run of the application and according to this msdn article

...encrypt its value via DPAPI with a user-specific key of the account under which the application runs, and save the encrypted value in the Windows registry.

The accde launches from the logged on windows开发者_Python百科 user account, after which the apps admin can login and setup the connection to the database, following the recommendations above.

The weakest link i now seem to have is the windows user account. It seems that anyone logged in to that account could decrypt the connectionstring if they knew the implementation of the security scheme. Which means that the system still is not secure enough.

I could create a new windows user, but that would mean that the password for that user must be kept safe, which means we are back at square 1, securing the password that is used to access some secret information.

There must be an easier way, any ideas?

Is there a reason you need to persist the connection string from session to session? Could you instead build a log-in form in your application where you accept the user's credentials, server instance and database name that they will be connecting to and keep this information in memory while the application is running?

This might provide more flexibility in that the administrator could decide to move the database to a new server and wouldn't have to worry about decrypting the connection string to change it and re-encrypt it. It would also allow for multiple databases to be defined - I'm thinking of a situation where you would have a QA server defined for testing changes before rolling out to the production server.