Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Databases – Infrastructure – Security

Brian Kelley is an author, columnist, and Microsoft SQL Server MVP focusing primarily on SQL Server security. He is a contributing author for How to Cheat at Securing SQL Server 2005 (Syngress), Professional SQL Server 2008 Administration (Wrox), and Introduction to SQL Server (Texas Publishing). Brian currently serves as an infrastructure and security architect. He has also served as a senior Microsoft SQL Server DBA, database architect, developer, and incident response team lead.

Encrypt usernames and passwords stored in files

I was looking at a product recently and came across a rather unpleasant surprise: the install instructions specified that I put the database connection in plaintext in web.config. I’ll explore this particular case and why it’s particularly egregious, but from a security perspective, this shouldn’t happen anymore, regardless of application. We have the tools and the processing power where encrypting data of this sort should be a no-brainer.

The Specific Case

When I say web.config, that should reveal that the application is an ASP.NET web application. It is. And modern ASP.NET apps (anything ASP.NET 2.0+) have the ability to store encrypted keys. The keys are stored encrypted in the registry and the way to get the keys are stored in the web.config file. Therefore, there is no need for anything sensitive to be in plaintext.

The way to do this is with the tool aspnet_regiis.exe. Here are the instructions on MSDN for how to use it in Microsoft.NET Framework 4.0. You can hit the drop down for other versions which will take you back all the way to SQL Server 2005 and 2.0. This feature has been around for about 10 years, as this old document indicates. Since it’s been around that long, there’s no good reason not to do this as a standard course of action for a web application.

But What If the Attacker Gets Admin Rights?

This isn’t to say that you have to use this method. It’s free. It works. However, the point is that credentials should not be left in plaintext. Yes, an attacker who gets administrative access to a server will likely have the resources to be able to decrypt and eventually get the information. However, this is a relatively easy step that makes things harder. It’s a low cost defense. Therefore, it should be implemented.

It Also Means the Username / Password Doesn’t Show Up via Searches

The other thing that encrypting the username and password or even the whole connection string is it means searches of files for this kind of information fail. It’s a trivial thing to run a search and see if you can get some additional nuggets like a username/password combination. Therefore, most smart attackers do these kinds of things. When I pen test a system, I certainly do. Encrypt and the search won’t pick up the information. That’s a good enough reason in and of itself.


Comments

Leave a comment on the original post [truthsolutions.wordpress.com, opens in a new window]

Loading comments...