.NET news » Security

When creating ASP.NET 2.0 applications, developers commonly store sensitive configuration information in the Web.config file. The cannonical example is database connection strings, but other sensitive information included in the Web.config file can include SMTP server connection information and user credentials, among others. While ASP.NET is configured, by default, to reject all HTTP requests to resources with the .config extension, the sensitive information in Web.config can be compromised if a hacker obtains access to your web server's file system. For example, perhaps you forgot to disallow anonymous FTP access to your website, thereby allowing a hacker to simply FTP in and download your Web.config file. Eep.

Fortunately ASP.NET 2.0 helps mitigate this problem by allowing selective portions of the Web.config file to be encrypted, such as the section, or some custom config section used by your application. Configuration sections can be easily encrypted using code or aspnet_regiis.exe, a command-line program. Once encrypted, the Web.config settings are safe from prying eyes. Furthermore, when retrieving encrypted congifuration settings programmatically in your ASP.NET pages, ASP.NET will automatically decrypt the encrypted sections its reading. In short, once the configuration information in encrypted, you don't need to write any further code or take any further action to use that encrypted data in your application.

In this article we'll see how to programmatically encrypt and decrypt portions of the configuration settings and look at using the aspnet_regiis.exe command-line program. We'll then evaluate the encryption options ASP.NET 2.0 offers. There's also a short discussion on how to encrypt configuration information in ASP.NET version 1.x.

Custom MembershipProvider and RoleProvider Implementations that use Web Services in order to separate the application and database servers.

A simple utility for encrypting files using 256 bit Rijndael (AES). Also, adds menu items to Windows Explorer's file context menu for easy access.

The.NET Framework 2.0 got quite a few security enhancements. This month Keith takes you on a whirlwind tour of the goodies you'll find there.

This article describes the WSE policy framework, which allows you to describe constraints and requirements a Web service must enforce. Discussions include security scenarios in WSE 3.0 and extending the framework with custom constraints and requirements.

Provides architectural, design, and implementation guidance for Web service security by using Web Services Enhancements (WSE) 3.0. Includes scenarios, patterns, decision matrices, and QuickStarts to help you make the most appropriate security decisions.

Security Briefs: Encrypting Without Secrets

Online Article: Manage Custom Security Credentials the Smart (Client) Way

Both Internet and intranet applications often require a custom store for user accounts and roles. ASP.NET 2.0 provides an out-of-the-box provider model as well as a SQL Sever database just for that propose. Unfortunately, the only way to administer the credentials databases is via Visual Studio 2005, and only for local Web applications. This article presents a full-blown custom security management application that administrators can use. The application wraps the ASP.NET 2.0 providers with a Web service and even adds missing features. This article presents the design approaches, challenges, and techniques involved in developing such an application. The article also walks you through some powerful yet useful techniques such as interface-based Web services, reflection-based Web service compatibility, advanced C# 2.0, Web services security, and Web services transactions.

Code access security (CAS) is based on the identity of the code that is running. In this article, Mike Downen discusses the role of CAS in .NET, and outlines some key new features and changes in CAS for the .NET Framework 2.0.

Security Briefs: Security Features in WSE 3.0