The second installment in this series about .NET security covers advanced topics such as secure custom authentication and role-based authorization. Author Enrico Sabbadin goes beyond the built-in authentication and authorization mechanism and shows you how to develop custom authentication and authorization schemes.

The first article in this series covered the basics of .NET identity based
security (a.k.a. role based security). In this follow-up article, we will go
beyond the built-in authentication and authorization mechanism and show you how
to develop custom authentication and authorization schemes.

Custom Authentication

In a custom authentication scheme, the application is responsible for
matching the user-provided credentials (in the form of a username password pair)
against the ones maintained in some kind of store.

The proper maintenance of the store containing such username and password
info is crucial. For better security you shouldn't store passwords in plain
text or in an encrypted form: Passwords' hashes should be persisted
instead.

Are you asking yourself how you can authenticate without knowing the
password? Here is the way it works: In the authentication phase, the
user-provided password is hashed on the client machine, and the result is sent
to the authentication authority. The authentication authority matches the
received hash with the one picked up from the user store. If the two match, the
login is successful. As you can see, this approach has actually two benefits:

The passwords are not stored in clear text or in an encrypted form (so
you don't have to worry about keeping the encryption key secret and
protected).

The password is never transmitted over the wire, in plain text, or
encrypted, so sniffing techniques are much less effective.

Note, however, that this authentication scheme is vulnerable to brute force
and dictionary attacks. If a hacker sniffs a username password hash pair over
the network, he or she can obtain the password in the following way:

Produce the hash of a word generated randomly or from a
dictionary.

Compare the hash with the sniffed hash.

If the generated hash matches the sniffed password hash, the password has
been cracked (otherwise, begin again).

Given enough time and computer power, the hacker will find the correct word.

To alleviate the vulnerability to dictionary and brute force attacks, there
are basically two techniques (that can be applied concurrently). The first
consists of enforcing a password complexity policy; the second (which is
effective only against dictionary attacks) consists of attaching a random
generated value (a salt) to the password before hashing it. In this technique,
the salt must be stored in the user store as well.

The .NET Framework comes with a full set of cryptographic libraries, so you
have different ways to generate the hash from a password. The one I like most is
using the static FormsAuthentication.HashPasswordForStoringInConfigFile method,
which accepts as input the string to be hashed and the hashing algorithm to use
(SHA1 or MD5). This method returns the hashed data in string form, thus avoiding
the annoyance of dealing with the byte arrays that other .NET cryptographic
libraries require. Using this method, the generation of a password hash (using a
salt) is really a snap, as shown in the example below.

I won't go into further details about authentication routines because
the MSDN library provides two articles showing, step by step, how to develop a
custom authentication mechanism against
SQL Server Database
or
Active Directory.