Preventing Automated / Dictionary Login Attacks without the use of CAPTCHA

• Download demo project with source - 15.1 Kb

Introduction

Automated and Dictionary attacks to login is a security threat that every IT is quite aware of. There are many techniques that help address this problem, one of which is the CAPTCHA - an image that contains characters and/or numbers that presumably only humans can read; its value is then entered by the user manually. This helps filter out automated logins. However, this technique can be quite difficult to implement and also costly because you would have to generate image on the fly. Further, some software are designed to figure out the value on the image using technologies similar to OCR scanning. Although CAPTCHA may work most of the time, like I said, it is difficult, expensive, and does not work all the time, plus, requires your user to enter yet another value from an already difficult to read text.

Background

I began thinking about this problem and wanted to come up with a solution that...

1. Is easy to implement
2. Cost effective (needs no image generation on the fly)
3. Does not require user to read and input another text box
4. Works! (Of course, there is no such thing as 100% secure or unbreakable)

Suddenly, it dawned upon me when I started thinking like a hacker that if I wanted to automatically try to login using brute force, I would have to continuously generate different user ID and password combinations until I find the one that will get me through, but what is common in this? The keys! Let me explain... for example, if the login page contains two text boxes, one named "userid" and the other "password", all I have to do is submit values to these fields, something like http://address/loginpagename.aspx?userid=John&password=cool, and keep on changing the values "John" and "cool" until I find the right combination and I will get in. The keys that are common in this scenario are "userid" and "password". What if these keep changing every time you make a submit attempt? You would never know which key to provide the value to, hence cripple the key-value combination attack altogether!

Using the code

The basic idea in accomplishing this is to assign a different name to the userID text box and password text box every time the page is loaded, either by first loading or a postback is triggered. To make sure that the keys (the names assigned to the userID textbox and password textbox) are unpredictable, I elected to use GUID. There are four parts to this technique.

Part 1: UserIDKey and PwdKey private properties. (I use ViewState to store the assigned key instead of Session so that if the user spawns another instance of login page, each page would have its own keys.)

private string UserIDKey
{
    get
    {
        if(ViewState["UserIDKey"] == null)
            ViewState["UserIDKey"] = Guid.NewGuid().ToString();
        return (string) ViewState["UserIDKey"];
    }
    set
    {
        ViewState["UserIDKey"] = value;
    }
}

private string PwdKey
{
    get
    {
        if(ViewState["PwdKey"] == null)
            ViewState["PwdKey"] = Guid.NewGuid().ToString();
        return (string) ViewState["PwdKey"];
    }
    set
    {
        ViewState["PwdKey"] = value;
    }
}

Part 2: Assign new names to the text boxes when the page is first loaded.

private void Page_Load(object sender, System.EventArgs e)
{
    if(!IsPostBack)
    {
        MakeFieldNamesSecret();
    }
}

private void MakeFieldNamesSecret()
{
    txtPwd.ID = PwdKey;
    txtUserID.ID = UserIDKey;
}

Part 3: Validation. When the Submit button is clicked, retrieve the values of the two text boxes to validate.

private void btnLogin_Click(object sender, System.EventArgs e)
{
    string userID = Request.Form[UserIDKey];
    string pwd    = Request.Form[PwdKey];

    //You must provide your own validation 

    if(userID == "John" && pwd == "cool")
        Server.Transfer("PostLoginPage.aspx");
    else
        lblErr.Text = "Invalid UserID or Password";

}

Part 4: Change the names of the text boxes on postback. This is what really prevents the key-value attack!

private void LoginPage_PreRender(object sender, System.EventArgs e)
{
    if(IsPostBack)
    {
        UserIDKey = null;
        PwdKey    = null;
        MakeFieldNamesSecret();
    }
}

Points of Interest

What I found to be very interesting is the magic of thinking outside the box. What most people are doing trying to solve this problem is how to make the input values more difficult to automate, but few, perhaps thought about changing the variable that takes the value. With this very simple technique, I think I have solved a real problem. What do you think?

History

First revision: January 5, 2005.

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here