Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.
Font size: +
6 minutes reading time (1205 words)

Invalid Logging Attempts

We saw a situation of a brute force login attack the other day and thought we would share it with our readers, although we are flattered that anyone thought our site sufficiently important enough to make the effort, their efforts were in vain as they did not get very far.   This particular attack is classed as one of the most common (and least subtle) attacks that can be conducted against Web applications.  The sole aim of a brute force attack is to gain access to user accounts by repeatedly trying to guess the password of a user or a group of users.   It is often carried out by automated tools -- readily available on the Internet – enabling submission of thousands of password attempts in a matter of seconds (or less), trying to make it easy for an attacker to beat a password-based authentication system.

 

There are a number of ways such attacks can be performed.  If the length of the password is known, every single combination of numbers, letters and symbols can be tried until a match is found. However, this can be quite a slow process, especially as the length of the password increases (which is why long passwords are better than short).  The alternative is to use a list of common words, which is known as a dictionary attack.  A dictionary attack will generally try all English words, with the option of adding numbers or doubling up the word as the potential password.  This has far fewer combinations, but still has a high chance of finding the correct password.  We ourselves in our role of a system/database administrator have used such a technique on our own systems to check that our users have strong passwords, after all it is important that we know before anyone tries it out.   The first tool of this type was a program called crack.  At least one database vendor provides as standard a tool for checking users settings as well.   It was amazing when one looked at the list of results just how many people thought words such as ‘santa and oracle’ were strong passwords.

An alternative to trying a lot of passwords against a specific username is to  try one password against many usernames.  This is often known as a reverse brute force attack.  This technique is note worth as it attacks a situation where a lot of account lockout policies fail.   These reverse brute force attacks are not very common, however, because it’s often difficult for the attacker to compile a sufficiently large volume of usernames for the reverse attack, and we personally have never seen such an attack.

Aside: The recent loss of user details and their passwords from a number of prominent systems where  the system employs a one-way encryption for a password might lull a user into a false sense of security.   If a hacker or other undesirable obtains a list of users and their encrypted passwords, all they need to do is encrypt a list of possible passwords using a variety of different encryption mechanisms (much easier if there is only one mechanism which is known) and then run comparison of the encrypted values against the encrypted passwords. 

Techniques to prevent brute force attacks
There are a number of techniques for preventing brute force attacks.  The first is to implement an account lockout policy.  For example, after three failed login attempts, the account is locked out until an administrator unlocks it.  The disadvantage of this method is that multiple accounts can be locked out by one malicious user, causing a denial of service for the victims and lots of work for the administrator.  [We implement a variation of this on our website effectively blocking the IP address rather than the user account itself, so apologise to any ‘real’ user who gets locked out because they have forgotten their password on multiple password entry attempts.  Regrettable but unfortunately unavoidable nowadays to protect sites.]

An alternative and probably improved but much more complicated technique is progressive delays.  With progressive delays, user accounts are locked out for a set period of time after a few failed login attempts.  The technique is to increase the lock-out time  with each subsequent failed logon attempt.  This helps to prevents automated tools from performing a brute force attack and to all extents effectively makes it impractical to perform such an attack.

Another technique is to use a challenge-response test to prevent automated submissions of the login page.  Tools such as the free reCAPTCHA [implemented in Joomla 2.5 as standard], can be employed to make the user enter a word or solve a simple math problem to ensure the user is an actual person.  This technique can be effective, but has accessibility concerns and unfortunately affects the usability of the site.  The captcha challenge can sometimes be difficult to read, especially for the visually impaired.    One variation on this is to display a picture, whose elements have to be re-arranged, which can be time consuming, or move a slider bar with the browser cursor.

All Web application should without exception enforce the use of strong passwords.  At a very minimum, users should be required to choose passwords of eight letters or more with some degree of complexity (letters and numbers, or requiring one special character), to provide an improved defence against brute force attacks.  Combine them with some of the other techniques and one is on the way to much more secure site.  There is an on going debate as to whether users should change their passwords periodically and how frequent such changes should occur.  It is reported that should short periods be used, (30 days or less) it is actually less safe, since the users are more likely to write down their password on a piece of paper or elsewhere which is one of the things that users should not do.  Preventing password reuse can also actually decrease security.  There is no one recommended technique that is suitable in all situations and the best that can be achieved for a site (or organisation) is best determined based upon what works for that site (or organisation).

One often promoted technique is to have a reporting tool that inspects web logs and notifies an administrator when multiple attempts originate from a specific IP address.   ON the surface this seems like a good technique however as we have reported before it is relatively simple for an attacker to change their IP address using simple tools (see an earlier post on TOR browser).

In todays’ environment all Web application have to employ at one or more of these techniques to defending against brute force attacks.   Users have to have the  confidence and trust that a site will protect their personal data.   That is one reason why our readers should ensure adequate defence's against this (and other) common forms of attack on their sites.

We are pleased to say that the attempt on our site didn’t get very far, and even as this is written the source of the attack is still being blocked.  We do not provide short block time outs!  We are not complacent however and try to be eternally vigilant on our site and those we are associated with.

×
Stay Informed

When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.

Joomla Development hints and tips
Lessons to be learnt from RBS debacle?
 
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries