3.2.2 Rate Limiting (Throttling)
All changes in this version
Title changed
Before · SP 800-63B
After · SP 800-63B-4
Rate Limiting (Throttling)
Control changed
Before · SP 800-63B
After · SP 800-63B-4
When required by the authenticator type descriptions in Sec. 3.1 , the verifier SHALL implement controls to protect against online guessing attacks . Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator. If more than one authenticator is involved with an excessive number of authentication attempts (e.g., single-factor cryptographic authenticator and centrally verified password), both authenticators SHALL be disabled. Authenticators that have been disabled SHALL be required to rebind to the subscriber account, as described in Sec. 4.1 , to be usable in the future.
The limit of 100 attempts is an upper bound, and agencies MAY impose lower limits. The limit of 100 was chosen to balance the likelihood of a correct guess (e.g., 100 attempts against a six-digit decimal OTP authenticator output) versus the potential need for account recovery when the limit is exceeded.
Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out due to rate limiting. These include:
• Requiring the claimant to complete a bot detection and mitigation challenge before attempting authentication 1 Invalidation can take several forms, including the revocation of a public-key infrastructure (PKI) -based authenticator and removal from the subscriber account.
• Requiring the claimant to wait after a failed attempt for a period of time that increases as the subscriber account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour)
• Leveraging other risk-based or adaptive authentication techniques to identify claimant behaviors that fall within or outside of typical norms (e.g., the use of the claimant’s IP address, geolocation, timing of request patterns, or browser metadata)
When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for the authenticators used in the successful authentication.
Following successful authentication at a given AAL, the verifier SHOULD reset the retry count of the authenticators that were used. If this is provided, the maximum AAL of the authenticator being reset SHALL not exceed the AAL of the session from which it is being reset. If the subscriber cannot authenticate at the required AAL, the account recovery procedures in Sec. 4.2 SHALL be used.