Server Handling of Expired Passwords temporary account locking are disabled. (These implicit defaults also apply to accounts created prior to the introduction of failed-login tracking.) When the server reads the grant tables, it initializes state information for each account regarding whether failed-login tracking is enabled, whether the account is currently temporarily locked and when locking began if so, and the number of failures before temporary locking occurs if the account is not locked. An account’s state information can be reset, which means that failed-login counting is reset, and the account is unlocked if currently temporarily locked. Account resets can be global for all accounts or per account: Other  ALTER USER  statements for the account have no effect on its current failed-login count or its locking state. Failed-login tracking is tied to the login account that is used to check credentials. If user proxying is in use, tracking occurs for the proxy user, not the proxied user. That is, tracking is tied to the account indicated by USER() , not the account indicated by  CURRENT_USER() . For information about the distinction between proxy and proxied users, see Section 6.2.18, “Proxy Users” . MySQL provides password-expiration capability, which enables database administrators to require that users reset their password. Passwords can be expired manually, and on the basis of a policy for automatic expiration (see Section 6.2.15, “Password Management” ). •For  ALTER USER , if  FAILED_LOGIN_ATTEMPTS  or  PASSWORD_LOCK_TIME  is not specified, its value remains unchanged for all accounts named by the statement. •For temporary account locking to occur, password failures must be consecutive. Any successful login that occurs prior to reaching the  FAILED_LOGIN_ATTEMPTS  value for failed logins causes failure counting to reset. For example, if  FAILED_LOGIN_ATTEMPTS  is 4 and three consecutive password failures have occurred, one more failure is necessary for locking to begin. But if the next login succeeds, failed-login counting for the account is reset so that four consecutive failures are again required for locking. •Once temporary locking begins, successful login cannot occur even with the correct password until either the lock duration has passed or the account is unlocked by one of the account-reset methods listed in the following discussion. •A global reset of all accounts occurs for any of these conditions: •A server restart. •Execution of  FLUSH PRIVILEGES . (Starting the server with  --skip-grant-tables  causes the grant tables not to be read, which disables failed-login tracking. In this case, the first execution of FLUSH PRIVILEGES  causes the server to read the grant tables and enable failed-login tracking, in addition to resetting all accounts.) •A per-account reset occurs for any of these conditions: •Sucessful login for the account. •The lock duration passes. In this case, failed-login counting resets at the time of the next login attempt. •Execution of an  ALTER USER  statement for the account that sets either  FAILED_LOGIN_ATTEMPTS or  PASSWORD_LOCK_TIME  (or both) to any value (including the current option value), or execution of an  ALTER USER ... UNLOCK  statement for the account. 6.2.16 Server Handling of Expired Passwords 1256