You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Line 2311, we see the function signature for throttle()
public function throttle(array $criteria, $supply, $interval, $burstiness = null, $simulated = null, $cost = null, $force = null) {
So we have a supply of 500, interval of 1 day, no burstiness, and simulated is true
Simulated looks like it simulates instead of running the full leaky bucket algorithm. All good here.
So then this thing should prevent me from password guessing, right?
Well, no. Typical account lockout thresholds for enterprise environments are 10. For consumer facing, 25. Timeout period is typically one hour.
But at least if I modify line 299 of Auth.php to
$this->throttle([ 'attemptToLogin', 'email', $email ], 5, (60 * 24), null, true);
It should give the TooManyRequestsException right?
Again, no. I send 55 login requests (login with email) using Burp Suite Pro's Intruder tool. The first 54 use invalid passwords, followed by a valid attempt. The final attempt is successful, returns a new cookie, and logs me in.
Please elaborate on how this throttle feature may be used to protect users from password guessing attacks. As it is, there is no protection.
It is my opinion that the "TooManyRequestsException" throttling should be separate from a lockout scheme, as they have separate intentions and separate needs. If the TooManyRequestsException is to be used for account password guessing protection, it should be tested using typical lockout thresholds and a configuration option should be available with secure defaults set.
The text was updated successfully, but these errors were encountered:
On line 299 of Auth.php, the user is logging in, and the library passes the simulated parameter as true
$this->throttle([ 'attemptToLogin', 'email', $email ], 500, (60 * 60 * 24), null, true);
Line 2311, we see the function signature for throttle()
public function throttle(array $criteria, $supply, $interval, $burstiness = null, $simulated = null, $cost = null, $force = null) {
So we have a supply of 500, interval of 1 day, no burstiness, and simulated is true
Simulated looks like it simulates instead of running the full leaky bucket algorithm. All good here.
So then this thing should prevent me from password guessing, right?
Well, no. Typical account lockout thresholds for enterprise environments are 10. For consumer facing, 25. Timeout period is typically one hour.
But at least if I modify line 299 of Auth.php to
$this->throttle([ 'attemptToLogin', 'email', $email ], 5, (60 * 24), null, true);
It should give the TooManyRequestsException right?
Again, no. I send 55 login requests (login with email) using Burp Suite Pro's Intruder tool. The first 54 use invalid passwords, followed by a valid attempt. The final attempt is successful, returns a new cookie, and logs me in.
Please elaborate on how this throttle feature may be used to protect users from password guessing attacks. As it is, there is no protection.
Documentation:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf (Page 66)
https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#account-lockout
It is my opinion that the "TooManyRequestsException" throttling should be separate from a lockout scheme, as they have separate intentions and separate needs. If the TooManyRequestsException is to be used for account password guessing protection, it should be tested using typical lockout thresholds and a configuration option should be available with secure defaults set.
The text was updated successfully, but these errors were encountered: