Is using integrated security (SSPI) for accessing SQL Server better for web applications?
Solution 1:
I'd say there are only two valid reasons to use SQL auth:
- You are connecting from outside the domain, so integrated auth.
- You're running a TPC-C benchmark and every cycle counts. SQL auth is a tiny bit faster.
For the scenario you're proposing (the the web server host is completely compromised) nothing can protect you. The hacker can do on the DB server at a minimum everything the web server can do. And I'd say that defense in depth can teach you to minimize the loss in such case: reduce the DB rights of the account used by ur web server to the absolutely bare minimum required and nothing more. Second make sure if the web server host is compromised it cannot be used to elevate privileges higher than the web server account (ie. there is no other service on the WWW host that uses credentials with higher privileges on the DB than the WWW account). These are basic security principles and have nothing to do with the authentication scheme used.
While the sql auth vs. windows auth gives neither a clear advantage in your scenario, there are other issues to consider:
- Centralized policies enforcement: you have one place to set up your password policies, including password lifetime and expiration, account termination etc.
- Control over impersonation and delegation of trust. Once sql auth is used in a trust delegation chain, all bets are off as that is not real 'delegation' and thus is no longer under the restrictions your policies impose
- Auditing: sql auth is not even seen by your LSA so your entire auditing infrastructure is simply bypassed. You need to explictly add the records SQL produce about sql auth events, but is mixing apples and oranges as those events have different source, provider and schema in the event log
One last note: the TDS protocol exposes the sql auth password in clear text over the traffic, but that is usually mitigated by requesting SSL encryption of the traffic.
So why do you see still sql auth WWW hosts that store password in clear in web.config? Those are the bad developers/admins, don't be one of them.
msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx
technet.microsoft.com/en-us/library/ms189067.aspx
Solution 2:
If you don't use SSPI, you're hardcoding the username and password into the source files.
If you're hardcoding the username and password into the source files, all your employees have access to it.
This is relatively insecure. A disgruntled ex-employee could use the information maliciously. A visitor might see the code up on a screen somewhere. Or the source code might accidentally get out in the wild.
The advantage of SSPI is that the password is never stored anywhere in the clear.
Solution 3:
The other answers so far have been good, but I'll throw in another one: management.
Sooner or later, you're probably going to end up with multiple SQL Servers. Managing the SQL authentication between your app and multiple SQL Servers gets to be a little painful, especially when you run into security problems. If you change a Windows authentication password once, it changes right away across all your servers. If you need to rotate your SQL authentication passwords, it's more painful - to the point where you probably won't do it at all. That's a security risk.
Solution 4:
I'm not 100% sure here, but I think the main point is that SQL auth is insecure, so it's better to use Windows auth. Depending on how your app is setup, you can also store the proper credentials in an encrypted form on the machine using Windows auth. I don't think that's really possible with SQL auth. You can obfuscate it, but ultimately it must be in the clear.
Also, just because a hacker can get into a server doesn't mean it's game over. A hacker might gain control of an unprivileged process but not do anything else on the server. That's why it's important not to run everything as administrator or system, but instead to use minimum privilege service accounts.