Skip to main content
Email Password   helpLost your password?

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.

You must Sign In to use this message board.
 
 
Per page   
 FirstPrevNext
GeneralMy vote of 1 Pin
small_programmer		21:27 1 Nov '09  
GeneralDoesn't work Pin
delucia		11:19 25 Sep '06  
GeneralDownload page once, use many times Pin
Vladimir_Davidov		4:41 1 Apr '05  
GeneralGreat Script Pin
infecting		20:08 20 Feb '05  
GeneralStored usernames Pin
Oblacek		1:10 23 Jan '05  
GeneralNothing is gained. Pin
MorgP		11:18 16 Jan '05  
GeneralThis is going to be difficult indeed Pin
_BOFH_		22:08 14 Jan '05  
GeneralWon't work Pin
Anonymous		5:16 14 Jan '05  
GeneralSwitch off/on for stress testing? Pin
Tom Celuszak		7:05 13 Jan '05  
GeneralInteresting approach Pin
Phan Dung		16:18 12 Jan '05  
GeneralEncrypt Pin
Yitzhak Gootvilig		6:37 10 Jan '05  
GeneralBack button Pin
DejaVudew		4:09 10 Jan '05  
Generaljust a get away? Pin
POMARC		1:34 10 Jan '05  
GeneralThe Order is constant Pin
Uwe Keim		21:17 9 Jan '05  
GeneralRe: The Order is constant Pin
Johnny USA		9:35 10 Jan '05  
GeneralRe: The Order is constant Pin
Anonymous		2:40 17 Jan '05  
GeneralRe: The Order is constant Pin
alireza_progman		12:37 23 Sep '08  
Last Visit: 10:50 22 Nov '09     Last Update: 10:50 22 Nov '09 1


Last Updated 9 Jan 2005 | Advertise | Privacy | Terms of Use | Copyright © CodeProject, 1999-2009