CleanTalk's blog

    Sign up

    Author: Alexander

    • How to protect a Linux system: 10 tips

      How to protect a Linux system: 10 tips

      At the annual LinuxCon conference in 2015 the Creator of the GNU/Linux core Linus Torvalds has shared his opinion about the safety of the system. He stressed the need to mitigate the effect of the presence of certain bugs by competent protection order in violation of one component to the next layer overlaps the problem.

      In this article we will try to uncover this subject from a practical point of view:

      • start with the presets and recommendations for choosing and installing Linux distributions;
      • then talk about simple and effective item of protection — security update;
      • next, consider how to set restrictions for programs and users.
      • how to secure the connection to the server via SSH;
      • we give some examples of configuring firewall and limit unwanted traffic;
      • in the concluding part will explain how to disable unnecessary programs and services, as further to protect the servers from intruders.

      1. To configure the environment preloading before installing Linux

      Take care of the security of the system is necessary before installing Linux. Here is a set of recommendations for the settings of the computer, which should be considered and executed before the installation of the operating system:

      • Booting in UEFI mode (not legacy BIOS –a sub-section of it below)
      • Set a password on the UEFI setup
      • Activate SecureBoot mode
      • Set a password on UEFI level to boot the system

      1. Select the appropriate Linux distribution

      Most likely, you will choose popular distributions — Fedora, Ubuntu, Arch, Debian, or other similar branches. In any case, you need to consider the obligatory presence of these functions:

      • Support of forced (MAC) and role-based access control (RBAC): SELinux/AppArmor/GrSecurity
      • Publication of security bulletins
      • Regular release of security updates
      • Cryptographic verification of packages
      • Support for UEFI and SecureBoot
      • Support of full native disk encryption

      Recommendations for installing distributions

      All distributions are different, but there are moments that are worth to pay attention and perform:

      • Use full disk encryption (LUKS) with reliable key phrase
      • The process of paging needs to be encrypted
      • Set a password for editing the boot-loader
      • Reliable password on root access
      • Use an account without the privileges, belongs to the group of administrators
      • Set for user a strong password different from the password for root

      1. Set up automatic security updates

      One of the main ways to ensure the safety of the operating system – to update the software. Updates often fix found bugs and critical vulnerabilities.

      In the case of server systems, there is the risk of failure during the upgrade, but, in our opinion, problems can be minimized if automatically install only security update.

      Auto-update works only for installed from the repositories, not compiled independently packages:

      • In Debian/Ubuntu for updates use the package unattended upgrades
      • In CentOS to auto-update use yum-cron
      • In Fedora for these purposes there is the dnf-automatic

      To upgrade, use any of the available RPM-managers of packages by commands:

      yum update

      or

      apt-get update && apt-get upgrade

      Linux can be configured to send notifications of new updates by email.

      Also , to maintain the security of the Linux core there are protective extensions, e.g. SELinux. This extension will help keep the system from incorrectly configured or dangerous programs.

      SELinux is a flexible system of forced access control, which can work simultaneously with selective access control system. Running programs are allowed to access files, sockets and other processes, and SELinux sets limits so that harmful applications are unable to break the system.

      1. Limit access to external systems

      Next after the update method of protection is to limit access to external services. For this you need to edit the file /etc/hosts.allow and /etc/hosts.deny.

      Here is an example of how to restrict access to telnet and ftp:

      In file /etc/hosts.allow:

      hosts.allow in.telnetd: 123.12.41., 126.27.18., .mydomain.name, .another.name  
in.ftpd: 123.12.41., 126.27.18., .mydomain.name, .another.name

      Example of the above will allow you to perform telnet and ftp connections to any host in IP-classes 123.12.41.* and 126.27.18.*, and also the host with the domain mydomain.name and another.name.

      Next, in file /etc/hosts.deny’:

      hosts.deny 
in.telnetd: ALL 
in.ftpd: ALL

      Adding a user with limited rights

      We do not recommend to connect to the server as root user — it has the right to run any commands, even critical to the system. Therefore, it is better to create user with restricted rights and work through it. Administration can be performed through sudo (substitute user and do) – this is a temporary elevation to administrator level.

      How to create a new user:

      In Debian and Ubuntu:

      Create a user, replacing administrator with the desired name and specify the password in response to the request.  Input password characters are not displayed it the command line:

      adduser administrator

      Add the user to the sudo group:

      adduser administrator sudo

      Now you can use the prefix sudo when executing commands that require administrator rights, for example:

      sudo apt-get install htop

      In CentOS and Fedora:

      Create a user, replacing administrator with your desired name, and create a password for his account:

      useradd adminstrator && passwd administrator

      Add the user to the group wheel for the transfer of the rights sudo:

      usermod –aG wheel administrator

      Use only strong passwords — minimum of 8 letters of the different register, digits and other special characters. To search for weak passwords among users of your server, use the utilities as “John the ripper”, change the settings in file pam_cracklib.so to set passwords forcibly.

      Set the expiration period of the password with the command chage:

      chage -M 60 -m 7 -W 7 UserName

      Disable password aging with the command:

      chage -M 99999 UserName

      Find out when a user’s password will expire:

      chage -l UserName

      Also, you can edit the fields in the file /etc/shadow:

      {UserName}:{password}:{lastpasswdchanged}:{Minimum_days}:{Maximum_days}:{Warn}:{Inactive}:{Expire}:

      where

      • Minimum_days: the Minimum number of days before the expiration of the password.
      • Maximum_days: the Maximum number of days before password expiration.
      • Warn: Number of days before expiration when the user will be warned of the approaching day shift.
      • Expire: the exact date of the expiration of the login.

      Also it is necessary to limit reuse of old passwords in module pam_unix.so to set a limit on the number of failed login attempts of the user.

      To see the number of failed login attempts:

      faillog

      Unblock account after failed login:

      faillog -r -u UserName

      To lock and unlock accounts, you can use the command passwd:

      lock account

passwd -l UserName
      unlocak account

passwd -u UserName

      To make sure that all users set passwords with the command:

      awk -F: '($2 == "") {print}' /etc/shadow

      To block users without passwords:

      passwd -l UserName

      Make sure that the UID parameter was set to 0 only for root account. Enter this command to see all users with UID equal to 0.

      awk -F: '($3 == "0") {print}' /etc/passwd

      You should see only:

      root:x:0:0:root:/root:/bin/bash

      If there are other lines, then check whether you have installed for them UID to 0, delete unnecessary lines.

      1. Set access rights for users

      After you install the password is worth to make sure that all users have access appropriate to their rank and responsibility. In Linux you can set access permissions on files and directories. So there is the ability to create and control different levels of access for different users.

      Access categories

      Linux is based on work with multiple users, so each file belongs to one specific user. Even if the server is administered by one person for various programs created multiple accounts.

      To view users in the system with the command:

      cat /etc/passwd

      The file /etc/passwd contains a line for each user of the operating system. Under services and applications can be created separate users who will also be present in this file.

      In addition to the individual accounts there is a category of access for groups. Each file belongs to one group. One user can belong to several groups.

      View the groups to which belongs your account, use the command:

      groups

      Display a list of all groups in the system, where the first field indicates the name of the group:

      cat /etc/group

      There is a category of access “other”, if the user does not have access to the file and does not belong to the group.

      Types of access

      For categories of users there is the ability to set types of access. Usually it’s right to run, read and modify the file. In Linux, access types are marked by two types of notations: alphabetic and octal.

      In alphabetic notation, permissions are indicated by letters:

      r = reading

      w = change

      x = start

      In octal notation the level of access to files is determined by the numbers from 0 to 7, where 0 indicates no access, and 7 means full access to modify, read and execute:

      4 = read

      2 = change

      1 = start

      1. Use the keys to connect via SSH

      To connect to the host via SSH is usually used password authentication. We recommend a more secure way – input  a pair of cryptographic keys. In this case, the private key is used instead of a password, which will seriously complicate the selection by brute-force.

      For example, let’s create a key pair. Actions should be performed on the local computer, not on a remote server. In the process of key generation you can specify a password to access them. If you leave this field blank, you will not be able to use the generated keys to store them in keychain-manager of the computer.

      If you have already created the RSA keys before, then skip command generation. To check the existing keys for a start:

      ls ~/.ssh/id_rsa*

      To generate new keys:

      ssh-keygen –b 4096

      Download of the public key to the server

      Replace administrator with the name of the key owner, and 1.1.1.1 with the ip-address of your server. From the local computer, type:

      ssh-copy-id administrator@1.1.1.1

      To test the connection, disconnect and re-connect to server — login must occur with the created keys.

      Setting up SSH

      You can disable connect via SSH as root-user, and to obtain administrator rights to use sudo at the beginning of the command. On the server in the file /etc/ssh/sshd_config you need to find the parameter PermitRootLogin and set the value to no.

      You can also deny SSH connection by entering the password so that all users use keys. In the file /etc/ssh/sshd_config, set for parameter PasswordAuthentification value no. If this line doesn’t exist or it is commented out, respectively, add or uncomment it.

      In Debian or Ubuntu you can enter:

      nano /etc/ssh/sshd_config

... PasswordAuthentication no

      The connection can also additionally secure with two-factor authentication.

      1. Install firewalls

      Recently was discovered a new vulnerability, allowing to carry out DDoS attacks on servers running Linux. A bug in the core system came with version 3.6 at the end of 2012. The vulnerability allows the hackers to embed viruses into boot files, web page and open up the Tor-connection, with no need for hacking a lot of effort to make — work the IP-spoofing method.

      Maximum damage for encrypted HTTPS connection or SSH – termination of the connection, but in the unsecured traffic, the attacker can put new content, including malware. To protect against such attacks is suitable firewall.

      Block access using Firewall

      Firewall is one of the most important tools for blocking unwanted incoming traffic. We recommend you to skip only really need the traffic and fully deny all the rest.

      To filter packages in most Linux distributions there is iptables controller. Usually it is used by advanced users, and to simplify configuration, you can use utilities UFW on Debian/Ubuntu or FirewallD in Fedora.

      1. Disable unnecessary services

      Experts from the University of Virginia recommend to disable all services that you don’t use. Some background processes installed on the startup and operate to shutdown the system. To configure these programs, you need to check the initialization scripts. Starting services can be done using inetd or xinetd.

      If your system is configured with inetd, in the file /etc/inetd.conf you can edit the list of background programs “demons”, to disable startup of service enough to put in the beginning of the line the sign “#”, turning it from the executable to comment.

      If the system uses xinetd, its configuration will be in the directory /etc/xinetd.d. Every file in the directory defines a service, which can be disabled by specifying the item disable = yes, as in this example:

      service finger

{

socket_type = stream

wait = no

user = nobody

server = /usr/sbin/in.fingerd

disable = yes }

      Also worth checking out an  ongoing processes that are not managed by inetd or xinetd. To configure the startup scripts in the directories /etc/init.d or /etc/inittab. After done the changes, run the command under root account.

      /etc/rc.d/init.d/inet restart

      9.Protect the server physically

      It is impossible to completely defend against malicious attacks with physical access to the server. It is therefore necessary to protect the premises where your system is located. The data centers seriously monitor the safety, restrict access to servers, install security cameras and assign permanent guards.

      To enter the data center all visitors must pass certain stages of authentication. Also, it is strongly recommended to use motion sensors in all areas of the centre.

      1. To protect the server from unauthorized access

      System of unauthorized access or IDS collects data about system configuration and files, and further compares these data with the new changes to determine whether they are harmful for the system.

      For example, tools Tripwire and Aide collected a database of system files and protect them with a set of keys. Psad is used to track suspicious activity by using reports firewall.

      Bro is created for network monitoring, tracking suspicious schemes of actions, collection of statistics, perform system commands, and generating alerts. RKHunter can be used to protect from viruses, most rootkits. This utility checks your system by database of known vulnerabilities and can identify unsafe settings it applications.

      Conclusion

      The above tools and settings will help you to partially protect the system, but safety depends on your behavior and understanding of the situation. Without care, caution and constant self learning all the safety measures might not work.

      This text is a translation of the article “Как обезопасить Linux-систему: 10 советов”  published by @1cloud on habrahabr.ru.

      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.).

    • 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.

    • A brief history of passwords from the P to the S: birth, death and the zombie apocalypse

      A brief history of passwords from the P to the S: birth, death and the zombie apocalypse

      The attack on the World Trade Center towers on 11 September 2001 claimed the lives of 658 employees of the financial company Cantor Fitzgerald. Its Director Howard Lutnick lost that day his brother, faced with an unprecedented problem. And it wasn’t even that the company’s servers, including backup, was also buried under the rubble. Information was partly available, but it was closed behind hundreds of accounts of perished colleagues. For assistance was attracted experts from the company Microsoft, they have used powerful servers for fast brute-force — from data access depended on the existence of the company, and it was necessary to time for the first opening of trading after the attacks. To accelerate the breaking could personal data of the victims. Lutnick had to call relatives, and, at the most inopportune moment, ask them a series of questions: the wedding day, the name of the college or university, the dog’s name.

      (more…)

    • API Method to Getting Country Code by IP Address.

      We are pleased to announce the launch of a new API method.

      Now you can get a country code to identify the country by IP address by one API call.

      The API method returns a 2 letters country code (US, UK, CN and etc) or full country name (Germany, Canada) for an IP address. Limit to the number of data is 1000.

      The instruction of how to use this method you can find here.
      https://cleantalk.org/help/api-ip-info-country-code

    • 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…)

    • Visualization of attacks, anomalies and security breaches with OpenGraphiti

      Those who visit our headquarters in San Jose (Cisco Systems) always amazes large video wall that displays a picture of attacks in real time with the ability to drill after touching certain areas of the screen.

      However, like any map attacks, and I have collection of already 34, any such visualization is ineffective in real life. Show to superiors, show to journalists, to include in any movie… It’s all useful, but not very applicable in practice. Usually you have your own data sets that are generated by your protection. And you wonder what is happening in your network or directed at your network, but certainly not the beautiful card with the “ballistic missile attacks”, which are drawn by the absolute majority of companies offering visualization services attacks.

      (more…)

    • Phishing on a new level: Cloudflare + Protonmail + Unvalidated Redirects – set of young Fisher

      “… you come to me, and you ask something, but you don’t ask with respect …”

      Vito Corleone

      Phishing is still the most popular and most successful type of hacker attacks. It’s simple, attacked is not the software, not servers, not networks, and the most vulnerable components of information systems – users. I often meet with phishing, as a single, to personal addresses, and mass attacks. In most cases, it is awkwardly composed letters and clumsily made phishing pages. Until recently most of these attacks frustrated at the user level: letters or just ignored (as the signs of phishing was very obvious) or in the worst case, the letters are forwarded to customer support with the question “is it safe to enter your password on this page?”. Of course, some part of users still underway, but in percentage terms, it was really low. But just last week I was faced with a phishing attack, which surprised me. I did some analysis and found out how it was organized and what tools were used.

      (more…)

    • Best practices to protect e-commerce sites

      Best practices to protect e-commerce sites

      Online shopping has always attracted intruders: it is a source of credit card data (now almost irrelevant); user data; data about orders and market trends (consumer demand); a traffic source; manipulation with the discount coupons, etc. An e-commerce site may be attacked as intruders in “free hunting” (non-targeted attack) and by the request of unfair competition. Recently are popular different kinds of DoS/DDoS attacks, as to disable a competitor and as a tool for blackmail.

      In this topic, I will describe best practices for the protection of e-commerce sites.

      (more…)

    • Protect SSH from brute-force on any port

      Today I was interested in the survey whether it is necessary to move SSH to a nonstandard port. The survey is not as interesting as the way the author @zivot_je_cudo to protect SSH from brute-force password: after wrong connection attempts to block new attempts within 20 seconds. The delay apparently chosen empirically on the basis of two opposite requests: to not lock yourself in case of misspelling a long time, and at the same time, make life difficult for the picker. I want to share my way to resist brute-force, which is used for several years. It has two advantages:

      • it gives me more attempts to set the correct password
      • but at the same time blocks the brute force “forever”.

      How can I achieve these two opposite goals?

      I use module iptables called hashlimit, which is able to count the number of packets in a certain period of time and after a while to reset the counter.
      Everything is done by three rules:

      iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m hashlimit –hashlimit 1/hour –hashlimit-burst 2 –hashlimit-mode srcip –hashlimit-name SSH –hashlimit-htable-expire 60000 -j ACCEPT

      iptables -A INPUT -p tcp -m tcp –dport 22 –tcp-flags SYN,RST,ACK SYN -j DROP

      iptables -A RH-Firewall-1-INPUT -p tcp -m state –state NEW -m tcp –dport 22 -j ACCEPT

      What makes the second and the third rule is clear. The most interesting in the first: it allows two connection attempts for an hour. Once you exceed 2 attempts for a specified time, rule with -j ACCEPT stops working, the user instead of this goes into the following rule with -j DROP (exactly the same way you can put TARPIT).

      After that, you will not be able to connect, and starts the countdown 60,000 milliseconds, after which information about your attempt to “become rotten” (parameter –hashlimit-htable-expire). That is you really are not come to wait 1 hour, and just only 1 minute. The whole ruse is that if you cannot wait this time and try again to connect, the packet will be killed, and the counter is again reset back to is  initial state –  1 minute! Thus, if you are impatient and stupid bruteforcer and will hammer away the port after blocking, you’ll prolong your ban with each attempt! That is, you will ban yourself forever!

      Good user on the contrary has multiple connection attempts without waiting between them, before he get into the “bath”.

      hashlimit module saves its state in the / proc – initially it’s empty:

      # cat /proc/net/ipt_hashlimit/SSH

      after the first connection attempt information gets there:

      # cat /proc/net/ipt_hashlimit/SSH
      55 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 11533000 230400000 115000000

      the first number is the number of seconds remaining, you can see how it evenly ticking:

      # cat /proc/net/ipt_hashlimit/SSH
      20 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 117429000 230400000 115000000

      After I did it, I really wanted to check it out. And wow! The ball comes to the player! I immediately began to brute-force by some Chinese. The first four attempts passed, and further he stupidly knocked the closed door within the hour (!). During this entire hour he managed to check only four passwords! Then, apparently, he tired.

      Thus solved two problems:

      — if the user suddenly sealed, he didn’t have to wait long for new attempts

      — bruteforcer themselves driven into an “eternal” ban.

      What if you suddenly with a few attempts were not able to enter your password? Do not fuss – wait a minute, and calmly try a few more times.

      And if you again failed – it is better to go to sleep, in this state it is better not to go into the console :))

      Good luck.

      P.S. And yes, I almost forgot — I have SSH on non-standard port 🙂

      UPD: A little about setting hashlimit.

      UPD2: How to achieve the same with a more recent common module: one, two.

      UPD3: Of course the method is suitable not only for protection from password guessing on SSH, but can be used for various other services, where too often the connection indicates something is wrong.

      UPD4: The connections limit using the SSHD.

      This text is a translation of the article “Защищаем SSH от брутфорса на любом порту”  published by Евгений Лисицкий on habrahabr.ru.

      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.).

    • 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.