.NET news » Security

A CAPTCHA control that is simple, secure and easy to use.

Security Briefs: A First Look at InfoCard

Hasher is a tool to help programmers implement standard hashing and checksum algorithms into their own software. Written entirely in C# and designed for use in the .NET Framework, Hasher providers a uniform interface to easily use any of the algorithms contained within this library in other programs. Hasher is planned to encapsulate a wide variety of cryptographic hashing and checksum algorithms. Focusing on compatibility, speed, and ease-of-use, Classless.Hasher currently supports over 25 different algorithms including the "basics" such as CRC, MD5, and SHA, as well as others like HAVAL, Tiger, Snefru, and Whirlpool.

Xenocode Postbuild 2006 breakthrough technology allows .NET applications to run on any Windows PC, with or without the Framework, counteracts decompilation and reverse engineering, optimizes application size and performance, and dramatically reduces test and support costs by eliminating "DLL/versioning hell".

One of the major benefits of writing .NET code to run in the Common Language Runtime (CLR) hosted in any environment is code access security (CAS).CAS provides a code-based-rather than user-based-authorization scheme to prevent various kinds of luring and other code attacks. But how does that security scheme coexist with SQL Server 2005's own, newly enhanced security features? By default your .NET code is reasonably secure, but it's all too easy for the two security schemes to butt heads and cause you grief. In this article I'll look briefly at the concept behind CAS and a few new security features in SQL Server 2005, then explore how to make the two systems work for you instead of against you as you take advantage of these advanced programming features in SQL Server.

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.