I am creating a windows form application in c#. I am storing datasource and initial catalog in Settings. But in connection string there is username and password also.
Why i am storing in Settings is because at deployment i can easily setup through my software. I want to deployment easy and i want dynamic connection string.
So anyone can guide me to how to store this all thing because setting is normal text file user can easily change it.
I have multi user system.So SQL Server in one PC and all user are in different pc. So i dont think creating a all user in database.
Instead of using SQL authentication, it is strongly recommended to access the database using the Windows accounts of the users. If your app runs inside an AD domain, you do not need to grant every single user access to the database, but can use an AD group for that purpose. See this link on how to enable windows authentication in the connection string.
There are options to encrypt the connection string in the file. However, it will require some effort, as it will add another preparation or deployment step to perform the encryption per machine/user.
In addition, there are no out-of-the-box tools available to encrypt a configuration file for a SmartClient app. So you'd also have to implement the encryption. See this link for details.
Please note that even if you use encryption, at least the current user account needs to be able to decrypt the settings in order to run the program. This also implies that a technically savvy user could create a small application that reverts the encryption and can get access to the credentials this way. So using Windows Authentication is really the better option.
Related
hopefully this is a simple one and I'm just failing to find the answer!
I want to write a C# application to run as a service that periodically connects to a SQL Server DB to run a few queries. The connection details for the SQL Server must be stored somewhere that the server can get them, but I don't want them stored in a plain text file. I could store them in an encrypted file, but then password would need to be stored somewhere that the service could access it, somewhat defeating the point.
So is there some kind of application/service-level encryption or secure storage API that exists, that allows configuration/data to be stored securely that doesn't need me to just store a password in a file somewhere?
Cheers!
It is entirely possible to encrypt the app.config (see this blog for some more details). However, an administrative user (or a user who can attach a debugger to your program, or a user who can set up a proxy between your program and the server if the password isn't sent through encrypted) will be able to see the decrypted password.
If you're concerned about that, you should consider a different security model. For instance, you could go with a Trusted Subsystem Model, in which users authenticate against a intermediary service that is trusted to connect to your database. This service could be set up to use claims, role, or user based authentication to authenticate users and determine whether they should have access to the database - and would ensure that you never distribute the password stored in your connection string.
Alternatively, if possible, you could consider utilizing logins and users/groups in SQL Server - which would allow you to use trusted authentication and not require a password in the connection string (although it would still require you to distribute the connection string with your application, and again even if it's encrypted a user of your application who has administrative access to the machine could potentially view it decrypted).
Just note that both of these methods do come with some additional overhead - you'll have to maintain roles/claims/users on some level to make sure that only the users you want are able to connect (not as simple as just always accepting the connection from whoever has access to the application).
This might be two questions, but I'm not sure. More experienced Membership users than me should be able to advise me on whether I should split it into two.
I have a website that connects to an SQL Server database to provide security via the .Net Membership classes, and what I want to do is have a Winforms application to administrate user accounts.
In addition, I don't want to store unencrypted connection strings into App.config, which is what I presume I will need to do, but what I'm hoping is that there's a standard way to encrypt them.
What I have done up until now is to manually encrypt and decrypt them using System.Security.Cryptography classes.
What I need to know is:
How do I set up a Winforms application to use my website's Membership security?
How do I encrypt the connection strings within App.config?
The following suppose that you have the control in the deployment of the database, the website.
For a Winforms application and depending your database, but let assume that it is SQL SERVER, you should use integrated security and let Windows do this dirty job.
If you can't use integrated security (client are not on the same domain than the database), you should ask the user to insert their credential on first use, store theses data in a secure place and build the connection string by hand. Have a look to the ProtectedData Class and the Data Protection API (DPAPI) for storing these kind of data.
https://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata(v=vs.110).aspx
For a website application, you could use database integrated security too with the credential of the IIS User or with the client windows authentication if they have one. As the config file of the website should not be visible to the client it is not the biggest security issue if it contains some credential.
As I'm not a guru of ASP.Net, you should not rely only on my experience.
Ok, I'm asking a rather generic question to a specific problem. I have searched this in more ways than I can count, and nothing seems to work. Let me explain my need and then I'll mention a few of the best solutions I've found and why they don't work in my case.
I have an application that a user launches and uses to set up various configuration values that are saved into an app.config file. This is a WPF application. Specifically, some of this data are HIGHLY sensitive.
This data needs to encrypted and subsequently decrypted by a Windows Service that will be launched by the application once the configuration step is finished. The general solution given for this scenario is to use DPAPI, which has two modes for encryption: User and Local Machine.
If you use User-level encryption, your application will encrypt and decrypt data as much as it desires, as long as the current user that initially encrypts the data is doing the decryption. My problem is that when the service is started, it also restarts on reboots and will specifically be running under a different user account.
The next approach, using DPAPI, is to encrypt the data as the Local Machine. This means that when ANYONE logs into the machine can decrypt the sensitive data. This is a BIG no-no!
What I need is to have a way for a user to specify the data he wants to encrypt and then specify an account (in this case, what will be the service account) and use it for data encryption.
I can't find how to do this. This MSDN article alludes that can be done. (See section 'Web Farm Scenarios'.) The TL;DR on that article is that for ASP.Net applications, you can use the RsaProtectedConfigurationProvider to encrypt your data, and export the keys to be used with a specific web account. This is close to what I want, but in my case I need to create the data in a WPF application and store it to be used in a Windows Server Service.
How can this be done?
You can accomplish something similar to this using something as mundane as EFS, but unlike raw DPAPI, a recovery key might bypass the protection. In either case, a local admin could replace your program with his own and it would have full access to the decrypted data.
As for setting this up, the easiest way to do that would be to interactively log on with the service account and either create the protected data using System.Security.Cryptography.ProtectedData or create a file in a directory marked with the "encrypt" attribute.
Use the account name as the salt for your encryption, decyption should use the logged in account name as the salt to decrypt.
i have a suggestion , you can create User group add required users into that group. And encrypt and decrypt data only if user is part of that group using second method.
I am sure there're lots of discussions already, but how to store a password in an application? (I meant not a user password to be stored in a table in a database, but the password to build connection string)
I've seen suggestions like store it encrypted in a flat file such as xml file, then read it +decrypt it at run time. If this application runs on a server, this is a very good choice, but what if the application will be deployed to end-users' pc? i.e. the flat file will be copied to the user's pc. Is this still a good practice? (my instinct is 'NO')
I know the existence of SecurityString, but then I also read in one post that SecurityString can be easily broken into, too.
Is it a good idea to use Password Vault that comes with Windows 7? Is there any good example of utilizing it programmatically? I've seen an example in msdn, but firstly it is labeled with 'windows 8', secondly when I downloaded the files and opened the solution in visual studio 2012 EXPRESS, it failed to open.
Any suggestion is welcome...many thanks.
--update--
Let's say, the application will be running on a handful of PCs within a windows domain. (1) At start-up, the application will do a LDAP authentication (active directory). Only upon successful authentication, the application will carry on, and (2) behind the scene the app can connect to the database, take user input to query the db, and this is where the db passwd comes into the play to build the connection string (no this is not SQL SERVER database so I don't think the option of using windows authentication is viable, unless a commercial plug-in is used).
The db resides in the same domain, and has been set up to allow certain range of IP addresses, and is SSL enabled. In short, it is quite secure in this sense. The only bit that is not yet secure is how to store the db passwd for the application.
What caught my eye was the Mysql Workbench. It will save db connections, including the password - which is stored in a password vault. That is mysql's own implementation of a password vault, and I am very curious as to how it is done.
There is no way to give a password to your users and expect it to remain safe. Even if it is hidden in your compiled application and hashed with a one way hash, the determined will recover it.
Instead you should consider your security architecture.
If you are providing services which your application connects to then you should look at providing some sort of more robust authentication as part of your public API.
If the connection string is for connecting to another part of the distributed software, then you should make the password configurable by the end user and store it in a keyring or other encrypted storage.
-- Update --
It looks like this might be what you are looking for;
http://www.microsoft.com/indonesia/msdn/credmgmt.aspx
If the application is going to be deployed where you have no or little control over the system security, ie, external user pc, then it may be worth creating a user login. Authenticate the user against this login, and then from a relatively secure server use whatever credentials you need to provide data.
This does not guarantee security, but it will be easier to maintain if you need to change the password at some point in the future, or if an individual user is compromised.
I have a situation that users access remote MySQL server in C# application.
Basically,
A user using C# application on his/her desktop ->>>> connects to remote ->>>>>>>> [ REMOTE ]
How do I securely hide database connection detail?
I have few ideas, but I don't think they are safe.
Encrypt database connection data into a file and store it within application directory.
prompt login page and let a human enter username/password, then transfer database connection data to user's computer.
No matter what you do if the credentials end up in the application in cleartext you are vulnerable.
Either implement a service layer in front of the database or if direct connections are essential try and come up with a scheme that allows a unique databse account for each user and then authorise them appropriately on the database.
Generally, it's better to ask the user for the credentials so that each account can be enabled or disabled by the administrator. Barring that, there are APIs for encrypting all or part of the configuration file. Here's a sample article:
http://www.codeproject.com/KB/dotnet/EncryptingTheAppConfig.aspx
I would suggest some form of session management based on user credentials. This can be accomplished in many ways.
For instance, you may accomplish this by simply wrapping your database access with a back-end system. Your desktop clients are oblivious to the database and interact solely with the back-end system. Unfortunately, implementing this level of indirection is not trivial if you have to do it from scratch but it will certainly make your application more robust and flexible. WCF services can help accomplish this.