Is it a bad practice to use Integrated Security=True on a production server in ASP.NET?
views:
82answers:
3
+5
A:
Nope - perfectly safe*
All you are doing is saying that you are going to use the credentials of (usually) the Windows user that the process is running under in order to authenticate with SQL Server (as opposed to supplying a username and password).
In fact in general using integrated security is considered more secure.
(*) Of course it always depends on your exact situation, but in the general case yes its fine.
Kragen
2010-10-18 11:20:47
Hmm, have you considered that this might not necessarily be true for a web server? If it is compromised, the dbase store is wide open as well. Keeping a password secure on a server isn't that hard, there's a lock on the server room door.
Hans Passant
2010-10-18 11:55:27
@Hans unless you are joking, that's a poor argument. If the server is compromised the attacker would also have access to the sql based connection u/p, so it's not better than integrated. In both cases how easily the attacker can get from that position to access the DB and how much they can do will vary on the specific configuration. If you really want to protect against that scenario you wouldn't have the web server hitting the DB directly.
eglasius
2010-10-18 12:31:44
@eglasius - nope, didn't use a smiley. You work from the assumption that the attacker would use an existing connection. That's doing it the *hard* way if integrated security is turned on. He could just create his own connection, no need to provide a difficult to guess username+password.
Hans Passant
2010-10-18 13:03:39
@Hans if I understand you correctly, what you are describing it's not an issue of allowing integrated, it's an issue of setting permissions in the sql server to All users instead of specifically for the identity of the application pool.
eglasius
2010-10-18 14:13:55
@Hans Passant, plz explain why SQL Server is wide open if web server is compromised. Webserver locally has no more access to db store then from internet
vgv8
2010-10-18 23:21:39
@vgv - you could worry a bit about the Internet having *any* access to the dbase store. If the web server locally has no more access then it should have none. Tough to get a job done. Sorry, this conversation is mystifying to me. Listen to @egalsius, he's getting the comment upvotes.
Hans Passant
2010-10-18 23:37:44
In many organizations, the developers have remote access to the server and the database has permissions set to allow anyone who is on the server to see the database, on the assumption that once someone is remoted in to the web server, it is time to just give up on the database being secure. This assumption is somewhat reasonable if the web server and the database are on the same machine, though not completely if one tries to avoid using administrator accounts for remote access to the web server.
Brian
2010-10-19 13:40:02
A:
This can be a good thing or a bad thing depending on the account that IIS is using to run the web application.
In any case, there is a distinct advantage that the SQL user id and password does not appear in the connection string; always a good thing.
However, you need to carefully setup your production environment. I would suggest that you create a distinct user account for IIS to use to run the web application. That user account could be configured to have access to only the SQL resources required by your application. That would protect you from have other applications easily compromised in the event that your web application's security is compromised.
I've heard of programmers doing acrobatics where a SQL connection string with the user id and password is loaded at run-time from an encrypted resource :-)
Rice Flour Cookies
2010-10-18 17:23:53
@Rice: Acrobatics? There is built in support for encrypted SQL connection strings. It is not especially difficult.
Brian
2010-10-18 17:29:09
@Brian - it is far better to lock down the permissions of the SQL account than to just encrypt the connection string alone. I prefer to use stored procedures for 100% of SQL access and only allow execute permission to the user. That way even if an attacker has the password, he can do little more than what the application can do itself. However, using both SQL permissions and an encrypted connection string would be the best option.
NightOwl888
2010-10-19 05:24:03
A:
Answer to the title question:
You should not touch (less use) anything in production environment while you are having such questions or doubts!
Answer to body question:
SQL Server in production should not be enabled for SQL Server authentication at all
Update:
I am surprised to see that all answers use probabilistic "this depends", "in some cases", "more" possibilities.
vgv8
2010-10-18 23:45:04