Category Archives: Web Security

Honeywords: A Follow Up on my Previous Post

After reading my previous blog post that included an overly annoying and slightly ineffective way to detect a password breach, my friend Chris from Casaba Security sent me an paper out of MIT that more effectively treated the topic with a very similar and much better implementation.

Link to MIT paper

Basically they suggest storing multiple passwords and the real password in a separate Authentication “Honeychecker” server. Then all password authentication attempts are routed to the separate server and when a malicious user is detected using a fake password, you can deal with them accordingly.

Their model of generating passwords for the user to select as their true password would most likely be met with harsh criticism in any consumer oriented product, but for a secure environment it would be more normal.  But it is necessary to implement their false password generator, and it improves security against users reusing passwords across different domains.

Having a ‘tough nut’ sounds good in theory, but any attacker sophisticated enough to be cracking passwords can easily modify their script to ignore extremely long passwords.  But it do like their idea of throwing the attackers through a loop with false passwords.  And the automated password cracking process seems like a great place to try to insert some counter-attacking code.  Password = “;DROP DATABASE”

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.