Monthly Archives: May 2013

A Random Way to Identify Malicious Visitors

password-crackingWhat I am about to describe is not perfect, only offers a constant and not exponential amount of more work to crack, and causes extra hassle for the user.  I am aware of that, but it was still an interesting thought experiment.

Main Idea:

A randomized password authenticator to help identify if/when the system has been compromised, and which visitors are malicious.  It does this by generating random similar passwords and storing the the true password along side them.  Then if a generated password is used on the site you know someone has been in your user authentication database.

More Words About It:

The typical user authentication cycle involves a user picking a username and password at account creation, and then every time they need to authenticate, they type in that username and password.  There are a number of issues with this method. The basic one being any password less than 6 characters long is trivial to crack with modern computing (Reference Article).  And while the simple answer is to force users to create longer passwords, this still doesn’t provide a great defense because users reuse their password across multiple sites.  At which point your authentication scheme is only as secure as the weakest website your users are replicating their passwords on.

Currently, if your website is hacked and the user information is leaked, all your users are potential open doors to hackers.  Their are a some good ways to ensure your encrypted passwords are hard to crack (Proper salting, bcrypt, SHA512), but as computing power increases or your information is sufficiently attractive, those barriers will eventually fall as well.  This is where some basic obfuscation can come in handy.

My proposal is fairly simple.  Create and store false passwords alongside the True password, then randomly select which password (out of both the false passwords and true password) is valid for authentication at the moment of authentication.  In this situation, even a users correct username and password combination would be rejected some portion of the time.  The level of rejection would vary depending on your need and acceptable user frustration levels.  In my scheme, the user selected credentials (I’ll call them the True Credentials or TC for short) would be correct 25% of the time.  So an user on average would take 4 or fewer tries to log-in with their TC.

Here is a sample of how this could be implemented broken down by steps:

Step 1: Credential Creation

Bob creates a new account.  With username=’Bobbers’ and password = ‘password1’

the user account name is stored as normal, and the password is stored in the password array of size 10 at a semi random location, here we’ll use a simple hash of adding the ascii value of each letter in the username and modding by 7.  So Bobbers = 66 + 111+ 98 + 98 + 101 + 114 + 115 = 703 %7 = 3.  So the TC ‘password1’ is stored in passwords[3].  The remaining slots in the array, 0-2 and 4-9 are filled with slight variations of that password such as  ‘1password’ ‘password12’ ‘9password9’ etc.

So now we have a password array filled mostly with junk.  We’re ready to try to authenticate.

Step 2: Credential Checking

The user comes to the site, enters their credentials and hits log-in. The server randomly generates a floating point number from zero to 1. A few cases can occur now:

Case A: If the random number is less than our selected randomized success rate of 1/4 or 25% or .25, then we calculate the position of the true password in the passwords array and check their submitted credentials against the True Credentials.  If they match the user is authenticated.

Case B: The random number is greater than .25%.  We now generate a random integer from 0-9 and calculate the true password position.  We’ll choose 5 for this example, which for us is going to be passwords[5] = ‘passwords123’.  The server compares the user submitted credentials against the username and ‘passwords123’.  If the user entered the True Credentials, their authentication request will fail and they try again.  But if the user happens to actually be a hacker who had access our user authentication data, they would be stuck guessing which password in the array is the correct one.  So they may end up submitting the false credential ‘passwords123’ thinking it is the true credential, or any of the other generated false passwords. In this situation, a hacker would have a hard time guessing the correct credential and my cycle through a number of generated false passwords trying to get into the system.

Case C:  In this case, it doesn’t matter exactly what our server is doing because it’s a thought experiment on detecting harmful visitors or a total breach of our user authentication information.  With this server setup, we could track what passwords are being submitted for each user.  If we notice a user keeps attempting a password we know was a false password generated by our server, then we can flag that account and restrict it’s access.  If we catch a system wide spike in authentication attempts that involve our generated false passwords, then we may be looking at a situation where our authentication data has been leaked.

At this point we’ve identified the potential threats in a few ways, and how to deal with them is up to you.

Adventures in Mobile Development

With my computer science degree almost completed, I’m starting a journey into Mobile development.  I’ve dabbled in Mobile Development a bit in the past but found documentation and tutorials not up to snuff for someone who was lacking technical skills.

So with my revamped skill set and a much deeper understanding of how computers work, I’m going to start simple and make a To-Do List application.  I’ll be chronicling my work here.

I’ll start with Android development, move into iOS and eventually Winows Phone.