Tag: brute force

  • How to reduce a possibility of brute force attacks on WordPress

    How to reduce a possibility of brute force attacks on WordPress

    Until the moment when CleanTalk launched a security plugin, I didn’t pay much attention to the security of the admin account of WordPress and relied only on the complexity of the password.

    The most dangerous thing is when the bots use brute-force; pick up the password to the administrator account of the site. This can lead to very serious problems, as the attacker gets full access to the administrator account. On your website can be added malicious code, the site can be added to a botnet and participate in other attacks or the spread of viruses. The consequences for the reputation can be very sad.

    When the security plugin was launched I began to receive reports on the work of the plugin in which specify the statistics of failed login attempts to the admin account of WordPress. And for each day of such attempts was from 4 to 25, from different IP addresses. These were attempts of bots password guessing.

    What I noticed:

    1. Bots knew my login and password was selected to it.
    2. I do not use the default username Admin and changed it.
    3. In the blog there are other admin accounts, but attempts to break them for a few days of observation did not happen.

    Wondering how the bots found out my account and why not try to hack other accounts of administrators? Quite simply, under my account I place posts and write comments, and other accounts are made for employees, host and other people that perform actions only in the dashboard of the website.

    Based on this, I realized that the bots find out the login via the parsing of pages. Many publish posts and comments from the admin account.

    For example, you publish a blog post; the link to the author will be like this http://example.com/author/admin***/. Bots browsing the code of your website looking for recordings of this type on all pages of the website and collect links from all accounts.

    The same thing will happen if you write a comment from the admin account, only the link will be a bit of a different kind http://example.com/members/admin***/

    Even if you once published a post or comment from admin account, then the bots will find it and will try to crack it.

    I described one of the possible scenarios of obtaining a list of accounts for hacking, there may be others. But experience has shown that if the WordPress administrator account is not used for publications and comments on the website, its bots do not know.

    What to do in order to minimize the possibility of hacking the account of the administrator of the website.

    1. Not to publish posts and comments from the administrator account.
    2. Create an account for each administrator with another role such as Author or Editor. It all depends on your needs.
    3. Change the current administrator user. Attention! Before that, you need to backup your website and databases. I can’t recommend this and if you do this at your own risk, as this may lead to undesirable consequences.

    You will need to create a new user with administrator rights and a user with another role such as Author. Login to the dashboard with the new account and test the capabilities of the Administrator to manage site, settings and users.

    Go to the “Users” and delete the previous admin account, WordPress will ask you to whom to reassign the articles and comments, here is useful pre-created user Author. Reassign articles on it and in the future use to publish posts and comments.

    These actions can be done for other accounts administrators. But for most WordPress users would rather to install one of the plugins for protection from brute-force attacks, such as plugin Security & Firewall from CleanTalk.

  • CleanTalk launches a project to ensure the safety of websites

    CleanTalk launches a major project to create a cloud service for the safety of websites. The project will include several functions: protect the site against brute force attacks, vulnerability scanner and virus removal.

    Each function will have a number of features which help you easily keep the website safe from hackers.

    (more…)

  • How to strengthen the protection of passwords of “12345” from brute-force attack

    Object: Web login form.
    Given task: to strengthen the protection of the user’s account from the selection of a simple password to his account, using a minimum of resources.

    What is the minimum of resources? It does not use a table-reference to block by IP-address and User-Agent. Do not use unnecessary requests to the system; do not clutter up the system with unnecessary authorization cycles.

    And, to do the magic requirement — even if the bot will enter the required username and password… do not let him enter, but the real user to let.

    Is it possible to do that? In theory, of course not. But in practice, and in private, under certain conditions, it proved to be quite possible.
    Welcome under cut for details.

    So, let’s assume that our user has login “test” and password “12345”. Vile bot has connected dictionary-generated passwords and are ready to work at a speed of 700 passwords per second. It knows that the login user is “test”. Situation breath-taking: the password “12345” will be calculated over very small time. The user, meanwhile, opened the website and started to enter the username and password in a web form login.

    Let’s make changes in the authorization system, while none of them has started its work, and the trouble has not yet happened.

    Magic will be in the third variable to be “glued” to the login-password pair. I called her touch.

    Every time someone gets (attention: gets, not ask!) the login and password, the date “touch” for user “test” is updated to the current date-time:

    login/password/touch: 'test', '12345', '2014-12-13 14:00:00'.

    Suppose that the bot is started the first iteration and was offered the password “1” for login “test” ‘2014-12-13 15:00:00’. Triggered the login_check controller that reads from the database a couple of login and password that no one “touched” as much as 2 seconds! Where do these 2 seconds?! About it further.

    Such a pair of login and password is found. The difference between the last «touch» and the current time – 1 hour. So record successfully returned to our request.

    First login-password pair are matched and login_check concludes that «test / 12345″ is not equal to «test / 1.” The controller returns «auth error». And then the date «touch» for user «test» is updated to the current: “13/12/2014 15:00:00”.

    The bot proceeds to the next iteration: tries the password “2”.

    The speed of a bot is measured by microseconds. It tries to log in immediately: in the ’13/12/2014 15:00:00 “.

    And here comes into play our algorithm – a condition for the parameter «touch» is not already running. 2 seconds have not yet passed. Fail.

    Modified by our logic controller «login_check» cannot get a couple of login and password.

    The record exists, but its date of “touch,” is too “fresh”.

    And it is not part of the sample. And if such pair of login and password is not present, then the controller will respond to the bot “auth error”.

    The bot does not give up, continues to guess, and finally comes to a correct password “12345”.

    The probability that it is current attempt will return success – and is extremely small. 1/700 for each login attempt! That is, if earlier it was 1:1, now 1:700. And the faster bot is, the more likely that it is waiting for fail.

    As a result, only a very small part of the password will be really checked. The rest will get false positives, even if they are correct.

    What about the user?

    Let’s start with the user. The user, in contrast to the bot enters data into a web form by hands across the keyboard and watching the visual organs on the monitor. And the flexibility of its algorithmic abilities much better than the bot. In fact, the user in some way artificial intelligence. So, part of the logic is already in it. And we’re going to use it!

    When the user sees the authorization error, he often rewrites the password again. Even if he just enter the password himself. Even if the password is filled automatically from password manager. I did this even before I applied system of protection of simple passwords.

    Yes, I promised to tell you about two seconds. I am telling:

    Two seconds is the optimum time for which the user carries out operations on data correction and makes the following login attempt. In those two seconds the user completely fits. If the user does not have time – he can always try again and this time the operation touch is probably already canceled.

    In conclusion.

    What happens if the bot will know about a 2-second delay? If we apply our test data, this means that the efficiency of the bot will decrease: only 1 attempt to crack the password instead of 1400.

    P. S. I’d like to hear the criticism because the system is already implemented in one project and have not yet created any ticket with the problem of access to the system.

    Thanks in advance.

    The main disadvantage of this method is the ability to block the bot authorization for the user whose account is trying to crack. In the activity of the bot the user will see the same error log and the author assumes the user is accessing tech support with the question of authorization.

    About the CleanTalk service

    CleanTalk is a cloud service to protect websites from spam bots. CleanTalk uses protection methods that are invisible to the visitors of the website. This allows you to abandon the methods of protection that require the user to prove that he is a human (captcha, question-answer etc.).

    This text is a translation of the article “Как усилить защиту паролей «12345» от brute-force атаки”  published by Дмитрий on habrahabr.ru.