Friday, 7 February 2014

Tricking hackers when they are trying to brute force passwords.

Just finished listening to the Security Now Episode number 441 podcast with Steve Gibson & Leo Laporte which was about passwords their minimum lengths and complexity of a list of top one hundred retail stores online. The basic premise of the podcast was about the security or lack of it that the top 100 commercial online companies were using. I was glad to hear that Apple did really well. Annoyed that it turns out that Amazon did so badly. Amazon along with a whole pile of others would allow hackers as many attempts at cracking your password as they want while Apple, Microsoft and a few others would restrict your attempts to ten attempts. Honestly you need to listen to the podcast - Security Now.

The first part of this post is about the podcast led me to the conclusion that I'm not sure if you are actually doing the right thing when you let a hacker know you are NOT ALLOWING them to brute force a password. Here is my reasoning if you let a hacker know that you have blocked the account you are technically passing useful information back to the hacker. This is because we check each password that is passed to the server in order. And that is the flaw in the process for example you don't tell a hacker that the username was not found. You say generic statements like "Sorry that username/password was not recognized" so the hacker doesn't know if its the password or the username they are using.

One of the latest functions in PHP "password_hash" allows for checking passwords and to tell the function how expensive the CPU cost will be for each checked password.

So what if we not only used this type of expensive password checker but we changed the system to record the last request from a specific IP address for a specific account and made the time between checking be say one second. This will then allow the server to ignore any extra requests and just return a fail message as a hacker would not know that load of the requests were ignored so they might go straight past the correct password. Because the one second time limit on the server had not expired while for the human user they might miss the time limit a couple of times but would eventually pause in typing their passwords. Now we could add in a lock mechanism after 10 failed attempts that the server actually tested (emailing the clients email address to tell them its blocked) but not updating the screne to say the account is locked. Hackers would think that they can test maybe 1000's of passwords.

The second part of this post is when Steve & Leo were talking about the strength of passwords you know those little coloured bars that appear beside the password field to tell you how strong or weak a password. the problem with most of these is that they basically work on the principle that the developer that created it builtin so for example a strong password 4 years ago could be considered weak now. When Leo and Steve were suggesting that every site should use these I was screaming no!!!! If the site implements a javascript widget that will show you this how often is it updated? once a year twice? How often will the sites that implemented it think about updating it.

Thats why I came up with one that would self update. I announced it in a previous post "Password Security how long will a hacker take to crack your passwords" a javascript plugin that would tell you how long it should take a hacker to crack your password.  It works out how complex it should make the calculation based on the current year.  It attempts to calculate the number of hashes per second that a computer could compute and then works out the complex nature of the password you just added then does the math and tells you much time it will take to hack.