0

In my application I'm currently saving the connection string to the following area:

Properties.Settings.Default.ConnectionString();

However I realized that this is bad practice since the connection string can be viewed by the user. I searched around the internet and most answers recommended to save the connection string in my app.config file, however the user can still see the connection string so it's still not safe. I thought about setting my connection string to a string and declaring it every time I startup my program but that seems inefficient.

What is the safest way to save my connection string in order to hide it from the user ? Thank you.

Edit: this is the connection string:

Server=server.com;PORT=3306;Database=db_user;Uid=admin;Pwd=test;
marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Harry
  • 301
  • 1
  • 4
  • 9
  • What database vendor? How is the app connect to the database? directly? through an application server? does it use a user logon and password that must be in connection string? or does it use integrated security (aka windows security)? – Charles Bretana Dec 31 '16 at 15:25
  • Sorry for not specifying. This is my connectionstring: Server=server.com;PORT=3306;Database=db_user;Uid=admin;Pwd=test; – Harry Dec 31 '16 at 15:27
  • 3
    Well if you're using MS SQL Server, then using _integrated security_ rather than specifying the password in the config file is a good start –  Dec 31 '16 at 15:29
  • What database ? If your app is running on windows platform, most database vendors allow use of *integrated security* where userId and password are not required in connection string. – Charles Bretana Dec 31 '16 at 15:30
  • I'm connecting to a remote Mysql Database. – Harry Dec 31 '16 at 15:30
  • then, if remote MySQL DB is on same AD domain,(or linked AD domain), switch to use Integrated security: https://dev.mysql.com/doc/connector-net/en/connector-net-programming-authentication-windows-native.html – Charles Bretana Dec 31 '16 at 15:32
  • @CharlesBretana, wouldn't that give all authenticated users access to all data on the remote SQL DB? Why not use a Web API to introduce an extra layer of security, and shield the db entirely from direct access? – CoolBots Dec 31 '16 at 15:51
  • 1
    No, it doesn't. Integrated security does not mean everyone uses the same login, it means that the app authenticates with credentials of currently logged on user at the workstation. So DB is still being accessed with specific user credentials. But Yes, it is always better to use something like a *service account* to ultimately access the database, (this eliminates need to manage user accounts in Database), but then you need to implement individual user database permissions in some other way. – Charles Bretana Dec 31 '16 at 16:07
  • @CharlesBretana let's say I am dev and have restricted use in the said app ("user" vs "admin"). What prevents me from writing my own app or connecting from an existing tool with my *authenticated account* and gaining "admin" level data in the remote db? If your app can connect, then my app can connect. – CoolBots Dec 31 '16 at 16:20
  • @CoolBots I highly recommend you read up on MS SQL integrated security; user mapping; SQL security; Windows [NT] Authentication; authication and authorisation because all of your comments on this page make no sense –  Dec 31 '16 at 16:23
  • @MickyD can you point me specifically to what I'd need to read to address the scenario in my above comment? Specifically, how do I restrict a user from accessing admin-level data that happens to be stored in the same table and retrieved with the same stored proc based on user access level within the app? You talk about integrated security like it's magical - if an app can run and connect in my user's context, I can make another app run and connect in the same context (it's already approved for a connection based on integrated security). – CoolBots Dec 31 '16 at 16:33
  • @CoolBots, you said it yourself. "*I am dev and have restricted use in the said app ("user" vs "admin").*" If your credentials have restricted access, then that's all any connection using those credentials can do, those restricted functions. the admin level data in the table would not be accessible to a connection which uses (or sends) the restricted user login. Not because of the connection, but either 1) because of the code in the application server, which connects to the database using a *service account* that no one was network Nazis has credentials for), – Charles Bretana Dec 31 '16 at 16:38
  • or 2) because every request to the DB passes the logon of the original user and the DB Code restricts access based on that logon. – Charles Bretana Dec 31 '16 at 16:39
  • @CoolBots Sure. [Here's a good starter](http://www.techrepublic.com/article/understanding-roles-in-sql-server-security/) –  Dec 31 '16 at 16:44
  • @CharlesBretana, MickyD, Thanks, I'll review integrated security model. Every company where I've worked (including some very large companies with very large MS SQL deployments) we used SQL authentication with underprivileged accounts and a web service / api (SQL shielded from direct access), including intranet apps. General consensus was "stay away from Integrated Security and introduce a layer of indirection in terms of SQL access, such as web service/api; manage security via that layer". Hence my views. Again, thanks for detailed explanations and resource links. Happy New Year! – CoolBots Dec 31 '16 at 16:48

2 Answers2

3

What you can do is: Encrypt the connection string in the config file and decrypt it before establishing the DB connection. There is a nice answer of how to do this here: Encrypting & Decrypting a String in C#

Community
  • 1
  • 1
Thomas Voß
  • 1,145
  • 8
  • 20
0

how about if you store the connection elements like (server name, db name , user and pass) in the settings of the projects properties.

Dara omer
  • 1
  • 1
  • 3