WL#8885: Introduce a delay in authentication process based on successive failed login attempts

MySQL server should provide a way to introduce delay in authentication process based on consecutive unsuccessful login attempts. This would slow down brute force attack on user password.

It should be possible to configure: 1> Number of consecutive unsuccessful attempts before which delay is introduced 2> Maximum amount of delay introduced

User Documentation

• http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-35.html
• http://dev.mysql.com/doc/refman/5.6/en/connection-control-plugin.html
• http://dev.mysql.com/doc/refman/5.6/en/connection-control-failed-login-attempts-table.html

• FR1 : A new plugin - connection_control, of type audit plugin should be introduced. Using this plugin, it should be possible to introduce a random delay in server's reply during authentication phase if successive failed login attempts for given account have crossed a global threshold.
  • FR1.1 : New plugin connection_control, should be a community plugin.

• FR2 : Once delay is triggered, each successive failed attempt for given user account should see an increasing amount of delay.
  • FR2.1 : Once delay is triggered, first successful attempt should also see appropriate delay.

• FR3 : Plugin connection_control should introduce a new system variable - connection_control_failed_connections_threshold to configure global threshold to trigger delay in server response for failed login attempts. It should be possible to configure the new option dynamically.

• FR4 : Plugin connection_control should introduce a new system variable - connection_control_max_connection_delay to configure upper limit on delay introduced by connection_control. It should be possible to configure the new option dynamically.

• FR5 : Plugin connection_control should introduce a new system variable - connection_control_min_delay to configure lower limit on delay introduced by connection_control. It should be possible to configure the new option dynamically.

• FR6 : It should be possible for an administrator to get information about current status of failed connections for different user accounts.

• I1 : Plugin connection_control will subscribe to MYSQL_AUDIT_CONNECTION_CLASSMASK class of events. Plugin will process MYSQL_AUDIT_CONNECTION_CONNECT and MYSQL_AUDIT_CONNECTION_CHANGE_USER sub-events to check if a delay is to be introduced before server sends reply to the client.

• I2 : New plugin connection_control will use LF hash to store information about failed login attempts for different user accounts. Key to the hash will be "'<user>'@'<host>'" string which will be derived in following manner:
  • If proxy user information is set in security context, it will be used.
  • else if priv_user or priv_host information is set in security context, same will be used.
  • else connected user and host information from security context will be used.

Note that : This means that if fully anonymous user account is used (@), plugin will use connected user/host information.

• I3 : connection_control_failed_connections_threshold
  • Valid values: 0 to INT_MAX32(2147483647). 0 implies disabling the feature.
  • Default value: 3

Note: When this variable is set, hash mentioned in I2 will be cleared.

• I4 :
  • connection_control_max_connection_delay
    • Valid values: 1 to INT_MAX32(2147483647)
    • Default value: INT_MAX32(2147483647)
    • Note : connection_control_max_connection_delay MUST be greater than or equal to connection_control_min_connection_delay
    • Unit : Millisecond
  • connection_control_min_connection_delay
    • Valid values: 1000 to INT_MAX32(2147483647)
    • Default value: 1000
    • Note : connection_control_min_connection_delay MUST be less than or equal to connection_control_max_connection_delay
    • Unit : Millisecond
• I5 : Updates to hash will be done in following manner:
  • For each failed login attempt value corresponding to given "'user'@'host'" entry will be incremented by 1.
  • For each successful login attempt value corresponding to given "'user'@'host'" entry will be removed after processing delay if any.

• I6 : According FR2.1, once a delay is triggered for any given user account, first successful login attempt afterwards will also face the delay. If this is not done, an attacker may get rid of client thread as soon as (s)he sees delay in server response. This will reduce attacker's overhead because (s)he needs to maintain less number of active connections while server will continue to hold the connection active. A delay in first successful login attempt after delay is introduced would force attacker to maintain connections till the time (s)he gets response from server.

• I7 : Once successive failed attempts crosses threshold, an ever increasing delay will be introduced. A warning will be logged in server log in such events.
  • Delay will be calculated based on following formula:

MIN ( MAX((failed_attempts - threshold), MIN_DELAY), MAX_DELAY)

• I8 : An information schema plugin - CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS will be introduced. This table will give information about successive failed connections for various user accounts.

• I9 : Plugin connection_control will introduce following status variable:
  • connection_control_delay_generated - This is a simple counter to provide information about delays generated by connection_control plugin. Whenever a delay is triggered, this counter is updated. This is a quick way to look at how frequently delays are inserted.
    • Note that connection_control_delay_generated will reset to 0 whenever connection_control_failed_connections_threshold is successfully set.