This post originated from an RSS feed registered with .NET Buzz by Eric Wise. Original Post: A quick security post Feed Title: Eric Wise Feed URL: /error.htm?aspxerrorpath=/blogs/eric.wise/rss.aspx Feed Description: Business & .NET Latest .NET Buzz Posts Latest .NET Buzz Posts by Eric Wise Latest Posts From Eric Wise

I keep seeing a lot of examples in ASP .NET where sql server priviliges are given to the ASP.NET worker process.  A few thoughts about this:

1. By doing this you are expanding the damage that could be done if the ASPNET worker process was compromised.  This is particularily so for those of you who give dbo rights to the worker process in your database.  (You know who you are, and I have found that about half the home grown projects I've looked at are guilty of this).
2. If you have multiple applications with different databases that all run under the ASPNET process now suddenly all your databases are up for grabs.  I recommend creating a sql server (mixed mode) or domain account (windows auth only) that your application will run under.

Q: Why not use windows authentication with integrated security turned on?  Isn't a single account more insecure than per user security?

A: Because the way connection pooling works.  If you use a single login connection pooling will be enabled.  If everyone uses their own account connection pooling goes bye-bye.

Q: What about my connection string?

A: Me personally?  I use the enterprise library.  The configuration tool has a very nice encrypt-my-connection-string function.  I heard in 2.0 the web.config can be encrypted just by flipping a switch in your properties.  I wouldn't know for sure because it's my policy to ignore beta versions until they get a go-live license.  Keeps me from getting pissed off like some of my compatriots.  =)