I have encrypted production connectionstring in webconfig on my development machine, and pushed it to production server. When running production application, getting Bad Data error while asp.net decrypting at server when connecting to database.
What wrong am I doing here?
Are you using RSA or DPAPI to encrypt? DPAPI is not built for encrypting on one machine and moving to another.
For RSA, you must be sure that the target production servers have a non-default and duplicated RSA encryption key on all target servers.
See this link for more information.
Related
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.
I have a .net application compiled and I am moving it from one server to the other server. The connection string is compiled. And this application connects and works fine from server A.
When I move the compiled application into server B which has the same database backend the application is not connecting.
I see that the encrypted connection string is not working. Is there a way to fix this? The backend server connectivity is perfectly fine and ports are open. still the connection string is not working. Any clue on how this can be fixed?
Looks like your connection string is encrypted with a certificate thumbprint installed on machine A, which is why it works fine there. However, When you moved your application to machine B, you might have missed installing the certificate.
Ensure that, if the encryption of the connection string is based on a certificate thumbprint, the certificate is also installed on the target machine.
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 am trying to connect to our sql server with the following connection string
<add name="siteDB" connectionString="Data Source=xxxxx\sql_2005;Initial Catalog=Intranet;User ID=username;Password=password" providerName="System.Data.SqlClient"/>
but I am getting this error
A connection was successfully established with the server, but then an error occurred during the pre-login handshake
this is only a problem when the Web app is compiled as .net 4, .net 2 seems to work fine
I have tried the following with no success
TrustServerCertificate=True
in the connection string.. no joy
also tried
TCP/IP protocols enabled
named pipes enabled
using a newly set up account with the correct permissions
any ideas?
thanks
nat
You can try this or
this (worked for me once):
1) Remove all SSL certificates and encryption options from IIS – both at the website level (for example from the “Default Web Site”) and at virtual directory level. Basically if you enabled encryption put all the settings back to their original non-encrypted settings.
2) Remove all SSL self-signed certificates from the server. These are the certificates that SelfSSL generated for you. Your server may have genuine certificates – don’t touch these as they may be used by other software and anyway should be harmless.
These certificates need to be removed from all certificates stores. To do this start MMC and (one at a time) add the Certificate Manager snap-in to “My user account”, “Service account” and “Computer account”. Locate every single copy of the self-signed certificates wherever they may be (Personal, Trusted Root Certificates Authorities, etc) and delete them.
3) Now, although you have deleted the actual certificates, SQL Server still continues to use encryption. This is because it has created a copy of the certificate in the registry. You need to locate these and delete them.
These are located in:
HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Microsoft\Microsoft SQL
Server\MSSQL.x\MSSQLServer\SuperSocketNetLib
AND/OR
HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Microsoft\Microsoft SQL
Server\MSSQL.x\Client\SuperSocketNetLib
4) Restart the server and this should have fixed the initial error and you will find that SQL agent is running and things are back to normal.
As found here.