|
|
|
 |
Placing Password and Account Names in Server Hi:
Ram Dass
In general, no it's not considered secure. Most security breaches are inside jobs after all.
Chris Tavares
It seems to be common practice to do this with web apps (i.e. for the SQL server connection). Of course, this 'feels' wrong to me as well. If I had a copy of that book I'd be very interested in the 'right' way to do it :)
Mike Swieton
In Windows the right way to do it is to set up IIS to log on with an account that has all the permission you need, and set up SQL Server with integrated security.
Joel Spolsky
Although if IIS is installed on your machine some might say your security is already compromised...
Phibian
We use a j2ee app server, websphere, and use its built in connection configuration. The passwords are stored within websphere and are encrypted, but our apps just as for the 'customerDatabase'.
Koz
There's no "secure" way to do this, in the sense of not granting the privilege to an attacker. I don't care if you're using WebSphere, IIS, Apache, whatever. If the attacker finds an exploit that lets him run code, you're toast, plain and simple. The best you can do in that case is slow him down by having the data in an obscure place and format. Ironically, an "integrated" solution like the IIS approach Joel mentions may actually be *less* secure, because if I understand it correctly, the attacker won't need to find a login and password, because he'll just get access to the database without them.
Phillip J. Eby
Ideally, the database server will allow you to apply controls on a per-account basis. In this case, you should restrict the rights of the account you are using. Then it doesn't matter if an attacker knows the username/password - they won't be allowed to do anything beyond the functionality exposed by your app.
Brian
I prefer the method Joel described but another common technique is to use the Windows CryptoAPI. This allows you to encrypt data with a key that’s tied to a Windows account. You’d encrypt the connection string under the context of the IIS or ASP.NET account and store it under a registry key with restricted access. This doesn’t eliminate every imaginable threat but it does greatly limit the attack surface in that just being able to read files on that machine won’t give up too much information. A user is essentially required to be the IIS account or ASP.NET account or an admin just to get to the encrypted string and then is required to be the IIS account or ASP.NET account to decrypt it. If someone gains that level of access to your server, the connection string is probably the least of your worries.
SomeBody
clear test != Secure.
T.J.
Use the Data Protection API for storing the connection string.
Just me (Sir to you)
|
