.NET Identity and Principal Objects Part 2: Custom Authentication and Authorization
- Custom Authentication
- Hybrid Authentication Scheme
- Operation Based Security
- Conclusion
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.
private static string CreatePasswordHash(string pwd, string salt) {
string saltAndPwd = String.Concat(pwd, salt);
string hashedPwd =
FormsAuthentication.HashPasswordForStoringInConfigFile(
saltAndPwd, "SHA1");
return hashedPwd;
}
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.