CG.Security began life as a CodeProject article back in 2004. The purpose of my original article was to demonstrate how to build a custom security database that could be easily integrated with standard .NET security classes. I tried to keep the scope of the library small so that I wouldn't have to explain too many things in the article. (There are definite limits to my abilities as a technical writer. ) The article's small scope meant that I had to leave out many of the cooler features that I would have liked to include at the time. All things considered, I think the trade off was a good one.

Fast forward to today and we see that the CG.Security library contains the same basic code for creating a custom security database but the architecture has been upgraded and restructured to work in a .NET 2.0/3.0 environment. CG.Security is broken up into multiple assemblies now, and includes references to other CODEGATOR assemblies. My point is that despite my best efforts the complexity level has risen on my little security library.

Since I'm no longer in the business of writing technical articles (I stink as a tech writer), I now have the freedom to add features to my code without the need to explain everything in detail. So would you like to know what unexplained feature I added this week?

Well...

This week I added a mechanism for locking a user and/or machine account after a configurable number of failed login attempts. This feature is intended to deal with the bozo who sits at the login prompt and tries every combination of user name & password in order to break into a system. The locks can be controlled via the App.config file. To turn of the locking just use a value of zero for a threshold. There are now attributes on the SecurityManager node to control the threshold and duration for both user locks and machine locks. The difference between a user lock and a machine lock is that a user locks only affects a particular user account while a machine lock affects everything on a specific machine (all users).

I integrated the locking code into the SecurityManager's Login method. The Authentication method does not lock accounts or consider locks when determining if a set of credentials is authentic or not. If you use the Authenticate method in your code instead of the Login method then you should keep that difference in mind. 

Have fun!