I have a Windows VB Net desktop application using MySQL server on a remote host. What are the security risks of using a encrypted connections strings section in the configuration file? If it is safe, would you trust it enough to keep the MySQL root password?
The connections strings have Persist Security Info=False and its users have only the privileges needed to perform their tasks.
Related
I created a windows library to do data reading from files and some custom filter, append, remove, update data towards my database on SQL Server. And my library requires app config which needs to put in connection string, because this library actually connects with more than 1 database.
If i were to deploy to my database server, i would need to do encryption to my connection string for security purpose. I have read a lot of discussion in stack overflow, but most of them are using RsaProtectedConfigurationProvider which requires my database server to have IIS server to do decryption. But the case is my database server don't add in the IIS on windows component as it will requires opening a new port which means open a new thread towards the server.
So my challenge right now is to do encryption of my app config without using any of ASP.net encryption tools. Is there any other way for me to do the encryption?
We have a web application which consists of an IIS web server which is on the internet, and a database server, which IIS accesses over a VPN link.
The problem we have is that we need to store the connectstring somewhere (which obviously can't be in the database).
I note that it is possible to encrypt web.config connect strings using aspnet_regiis :
https://msdn.microsoft.com/en-us/library/dx0f3cf2%28v=vs.85%29.aspx
Can anyone comment on how robust this is. What we do not want is the database being hacked from the internet.
One thing which concerns me is the aspnet_regiis is used to decrypt and encrypt and is installed on the machine itself. So if the machine was compromised and this exe was on there, discovering the passwords would not be that hard.
So assuming that this method of securing a password is not recommended, what other options do I have.
Note that in case it is relevant, IIS is running in the context of IIS APPPOOL\DefaultAppPool account.
Thanks.
You do not encrypt your configuration files to prevent being hacked from the internet. IIS will never serve *.config files. You encrypt configuration files to hide the information therein from server administrators.
If a remote attacker has access to the server and can run arbitrary executables, all bets are off. There's nothing you can do to secure the server after that.
How to prevent the server from being accessed remotely is too broad to answer, check OWASP for general hints.
If possible, give your app pool identity (in your case IIS APPPOOL\DefaultAppPool) access to the SQL Server.
Then use integrated authentication instead of password and username in your connection string:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
I'm trying to connect and getting an error like:
Login failed. The login cannot be used with Windows Authentication
I'm using mirrored local accounts on SQL Server and web server because I'm simply trying to use a trusted connection between machines not on the same domain. It seems like something that would be fairly common, but after days of trying to find an answer that applied to my situation, I do not recognize that any of the answers were applicable... that or the fact that I'm only a .NET developer and not a sysadmin or DBA means I have it and just don't know it.
Here's what I can say:
CMS web server: ASP.NET 4.0 web app running on Windows Server 2008, IIS7, on corporate DMZ
CMS database server: SQL Server 2008 R2 on a domain server
For various reasons that I won't go in to, encrypting the credentials is not sufficient.
The database port that the application needs to connect on is not the standard port and is set up to listen on a different port.
Setting up DB mirroring isn't an option and doesn't really address the requirements (in my way of thinking)
Also, FYI if this is helpful to know:
Content entry happens on internal web server which publishes content to same DB that is accessed by the DMZ web server.
Content server is set up to have the website run the app pool in integrated mode with a windows domain user that has been set as a service account using the -ga switch and given all the appropriate rights and everything runs perfect.
External web server, without domain access, using mirrored accounts (same username and password set up on the SQL Server machine and web machine).
Local account on the web server set as a service account using -ga switch and running as the app pool identity for my app.
On the SQL Server box, created local user with identical creds and given same permissions that the domain user identity has
Connecting to SQL Server via MGMT studio installed on web server with the SQL Server user creds works fine.
Now, if I put in the username in to the connection strings, everything is perfect. As soon as I put the trusted_connection=yes in the connection string like I did with the domain server connection strings, I get the trust error.
So if my connection string is like this, it works fine:
Server=myServerAddress;Database=myDataBase;Username=MyUser; Password=MyPassword;
If I change my connection string to either of these, it fails:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
or
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
I'm working with one of the client's network admins and he's not necessarily a DBA and doesn't have experience with configuring web apps. So it's possible that we're missing something and any advice or ideas would help. What am I missing?
If using SQL credentials are not an option, then you should use Active Directory and create a one-way trust (have DMZ server domain trust your internal domain), create a service account in your internal domain which your DMZ application can use, and grant that account access to the database. Then it will be able to generate SSPI context.
Our website connects to a database correctly when running the website locally using the built-in web server. But, when we deploy the site to our server running IIS, we get a database connection error. The database server is different from our IIS server. Note that a trusted connection to a different database on the SAME server as IIS works fine.
What do we need to do to connect to a SQL database on a different server with a trusted connection?
When you're running a web site using Cassini, the account used by the web server process is your own account that you use to log on to your Windows machine. That account will be different on IIS.
Consider the security implications of opening the database up to a broader access than you may need with trusted connection. Perhaps you could use Windows authentication with a service account. That is, create an application-specific user in SQL Server with limited permissions. Then, you will get the benefits of connection pooling while avoiding passing credentials.
I'd check the user account that app domain in IIS is using to connect to SQL Server. The account in IIS may not have access to network resources as well which would explain the trouble reaching the other database server.
Sounds like you need to configure the database server to provide access to the database you're trying to connect to.
Assuming SQL Server, log into SQL Server Enterprise Manager and under Security -> Logins, open the properties for the applicable user (probably the Network Service or ASP.NET account of the web server) and go to the Database Access tab and ensure that the Permit checkbox is ticked for the database you are connecting to.
I have an asp.net application that should access data from two SQL Servers. One of the SQL Servers is present on the same machine as IIS (let us call it SQLSERVER1) whereas the other SQL server is present on another machine (SQLSERVER2).
The connection strings are trusted for both the SQL servers. Impersonation has been set to true in my web.config file. I am using Windows authentication in both IIS and web.config.
When I try to access data from SQLSERVER2, I get login failed for user(null) error. The user through which I have logged in through Windows exists as a SQL server account in SQLSERVER2.
What could be the possible reason?
NOTE: This is a newbie question IMHO.
NOTE: The IIS used is 6.0 (Windows 2003). It is not set to IIS 5.0 isolation mode.
EDIT:The user getting impersonated is a domain user
Addition:
I also want to state that I get this error message when I access it as a client of the server where IIS is running. In other words, let me say I am working on machine A, the IIS and SQLSERVER1 are on machine B, and SQLSERVER2 is on machine C.
I do not get this error message when I am working on machine B. This is stumping me more.
This is absolutely a delegation problem. As one person pointed out, you need to make sure Kereberos authentication is being used. The old style NTLM isn't going to cut it. Here's more on Kerberos vs. NTLM.
In a nutshell, if you have a webserver and a database and you want the webserver to impersonate the user when making database requests (so that you can set up permissions on the database directly on a per-user or user-group basis) you're performing a double-hop. Credentials must past first from the user's computer to the webserver and again to the database. As you can imagine, the database has to trust the webserver to "do no evil" or this could be an extremely dangerous security hole. As a result, you have to set up what is called in the Windows Server world "delegation"...
Microsoft has a good article about all this here. Further, you can look over an article like this to get an idea of how to set it all up. We've run into this frequently, and it can be a pain at first, especially since as a developer you're probably not in control of the servers directly (especially production ones) and you'll have to spend a lot of time with the server guys down the hall.
You're probably running into this problem because non-Kerberos based impersonation (NTLM) is only valid on the local machine (the webserver). If you want to be able to use those credentials to access another machine, you're going to need to make sure you're using Kerberos.
Try this: http://support.microsoft.com/kb/810572
Your authentication to the webserver is not passed through to the sql server. The web server is authenticating to the SQL Server using the account that your application pool is running under.
You should check that the machine account for SQLSERVER1 has trusted for delegation enabled. Otherwise SQLSERVER2 won't trust the impersonation running on SQLSERVER1. This is in addition to confirming that Kerberos is used to set up the impersonation in the first place. This also assumes that the servers and the users are all members of the same domain.
BTW, are sure you want to do things this way, you end up creating a lot more connections because they end up being unique to a user?
Have you tried to access the database on server2 using SQL SErver administrator from Server1 and made a successful connection?
If not then this could be because by default SQL Server installs itself with tcp turned off by default.
You will need to make sure that this is turned on for server2 to allow server1 to connect.
server1 has no problems connecting due to the fact it can use the shared memory connection.