Limit failed login attempts on Laravel Auth

Did you know that Laravel Auth system allows you to block the user after X bad attempts to log in? Even more, you can change that limit! This trick works with out of the box Laravel Auth system and all you have to do is modify one file.

Open App\Http\Controllers\Auth\AuthController.php and add these lines:

protected $maxLoginAttempts = 10; // Amount of bad attempts user can make
protected $lockoutTime = 300; // Time for which user is going to be blocked in seconds

Now if we enter our bad login information 10 times in a row, we should see:

laravelAuthBlockMessageExampleScreen

By default, if you don’t change anything and just use Laravel out-of-the-box, those parameters are equal to 5 times and 60 seconds respectively.

To change the error message we see, go to resources/lang/en/auth.php.

'failed' => 'These credentials do not match our records.',
'throttle' => 'Too many login attempts. Please try again in :seconds seconds.',

If you’re curious how it works under the hood, it’s simple: information about blocked users and remaining time is stored in session data. Not in database or cookies, in session.

Like our articles?
Check out our Laravel online courses!

RELATED ARTICLESMORE FROM AUTHOR

16 COMMENTS

  1. Doesn’t the storage in session data also mean an attacker only needs to not send the session id on each subsequent request, in order to bypass this mechanism? Or, alternatively, s/he just needs to use botnet to bruteforce login without ever being locked out? Storing the attempts in the database would make these attacks useless.

    • Yes and no at the same time. In many cases, even the database case, you would have to attach a user id to specific user via cookies. This means that if I clear the cookies – I bypass any solution. Unless your app depends on IP address (which is really bad and should not be done), then yea – they would have a bit more problems. So in short you can bypass this system or any other just by clearing cookies. On the other hand if the auth mechanism would work with one exact user – yea, database is a must there to block the single user but then complexity would come and for example if I try to log in into my account and blocked message would pop – I would not understand it.

      • Modestas Vaikevicius, can you explain why using an IP address to do rate limiting is “really bad and should not be done”?

      • I have the same question as @Hyperflux :
        Why is limiting access by IP a bad idea? Actually, I am not sure that is what you meant by, “Unless your app depends on IP address (which is really bad and should not be done)”

        Can you explain further?

        Thanks for your work here.

        • It is a bad idea because many users could be behind the same IP address. A library for example. Or you at home with a mate surfing the web.. same IP to the outside world. So it is a bad idea to identify someone by it’s IP only…

  5. It’s not working in laravel 5.2 I have added the traits. and that’s it.
    Do I need to do anything or add any middleware on the auth/login (post) route?
    Please reply thanks

  6. Thanks a lot Povilas.
    Your tutorial saved me lot of hours.

    Is there a way to show a message like “Please change your password” to user after few months of his or her first login? Password never expire. But just show a message.

    Thanks again.

  9. I have implemented User Activation via email with Laravel 5.2

    il work fine, but I have probmeme when user not clicked on the link of validation inside email verification after some time for exemple 1 or 2 hours.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Or, you can subscribe without commenting.