A common hacking technique is to try to guess user passwords or email addresses by automated submission of login and password reset forms. To do this effectively hackers must submit many thousands of requests.

Hackers will typically vary which user is targeted frequently to avoid detection

To protect against this type of attack we want to track rates per source address (ie the addresses the attack is coming from) and the user targeted by the attack, and then if the rate trips a specified limit then to take protective action such as blocking the source IP or locking the targeted user acount for a period of time.

The example below shows configuring IDP to track failed logins over 600seconds, and the rule will be tripped if this value exceeds 20, so if there were more then 20 failed logins within 10 minutes. If tripped this will lock the profile for 60 minutes

Example IDP to protect against brute force login attacks

<policy>
  <rules>
    <rule>
      <expression class="compare" comparator="GT">
        <lhs class="metric" metricName="failed.logins.10mins"/>
        <rhs class="const">
          <value class="int">20</value>
        </rhs>
      </expression>
      <action class="multiAction">
        <accessBlock blockForMins="60"/>
      </action>
    </rule>
  </rules>
  <metrics>
    <entry>
      <string>failed.logins.10mins</string>
      <logins intervalSecs="600" type="FAILED"/>
    </entry>      
  </metrics>
</policy>

Protecting the password reset page

Hackers will often attempt to gain access in stages, and the first stage is to find email addresses of users.

To do this they might repeatedly submit guessedemail addresses to the password reset page to find addresses which are valid.

The attacker will try to mask this by using a variety of source IP's and user agents. Because they are trying many different email addresses the rule above wont help.

But attackers will have a limited set of source IPs, so a rule which matches on a form submit to password reset page, and which tracks by source IP, will effectively detect these attacks. We recommend that this is used in conjunction with CSRF tokens, and also to use Captcha if possible.

Example IDP to protect against brute force email guessing attacks

This example creates a metric which will track POST requests to the /profile-reset-password page over 10 minutes. If the limit is exceeded it will just abort the current request.

Note that this should not lock the profile because hackers may be targeting many different accounts. You might want to block the IP though, as in the example above.

<policy>
  <rules>
    <rule>
      <expression class="and">
        <expression class="method" method="POST"/>
        <expression class="path">
          <pathPrefixes class="java.util.Arrays$ArrayList">
            <a class="string-array">
              <string>/profile-reset-password</string>
            </a>
          </pathPrefixes>
        </expression>
        <expression class="compare" comparator="GT">
          <lhs class="metric" metricName="pwd.resets.by.ip.10mins"/>
          <rhs class="const">
            <value class="int">10</value>
          </rhs>
        </expression>
      </expression>
      <action class="abort"/>
    </rule>
  </rules>
  <metrics>
    <entry>
      <string>pwd.resets.by.ip.10mins</string>
      <requestMatch method="POST">
        <wrapped class="statusCode" intervalSecs="600" metricType="IP">
          <statusCodes>
            <status>SC_OK</status>
          </statusCodes>
        </wrapped>
        <pathPrefixes class="java.util.Arrays$ArrayList">
          <a class="string-array">
            <string>/profile-reset-password</string>
          </a>
        </pathPrefixes>
      </requestMatch>
    </entry>
  </metrics>
  <knownIps/>
  <content-access-rules/>
  <properties/>
</policy>