See below... > We're talking about two different things. Windows authentication from > the web server process to the database, not from the end user to the > web server through to the database.
>> Kind of blows that whole protect your network from the web server thing, no? >> ;-) How so? That account can be very limited. Something needs to be granted the ability to do something to the database server in this instance, the issue is what is granted that access and how to protect it's credentials. >> There is an assumption in security best practices that web servers can be more easily compromised than internal systems, and thus anything the web server can do with it's permissions should be as limited as possible. << Completely agree. But that is the same issue whether it is the account running the web server or a database account found on the web server. Clients of my former company would mitigate this by not allowing direct access to the database from the web server period, they would require a middle tier running business objects. Bottom line is there really is no way to secure passwords with software, but a "role your own" solution that is unverified is not preferable IMO. >> Allowing full acess to a a database would probably fit under the list of things not allowed. << I'm not sure where the full access assumption came from. Seems like a logical fallacy in the argument. Simply give the account the access to the database objects needed to run the app and no more. How is that different from a database account? In a system like the ones I've worked, where you've got potentially millions of users, NT authentication of the end users didn't seem feasible. Has anyone attempted this? If it could be managed I'd agree with that approach... >> You could just as easily argue that if the web server is compromised, you are screwed anyway because the attack would probably have access to whatever technique you use to get database credentials. << I'm not sure I follow this line of questioning. If the web server is compromised neither option under discussions will secure the database from the attacker. I would be able to use the database through the windows account or discover the username and password. The account accessing the database needs to be limited. No one suggested it required full access, in fact that was outside of the original question. >> One other complication is that the machine account can't (and shouldn't) be used to access a database on another server, so you have to run that web server appdomain as a network user. This requires putting a password in a config file.... and you are right back where you started. << You _can_ use a machine account. Shouldn't is arguable. The password in the config file is encrypted by the system vs. software running under the web server user. =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with C# November 29 - December 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
